In the section under "Inheritance", it says:
When project resources are changed in the original project, these changes will get passed down to the inherited projects.
But, I've added a custom Session property to my global project and it doesn't show up in existing projects. They do show up when you create a new project, but changes do not turn up once the project has been created. Is there a way to force a refresh to push these changes down from the global project? Or aren't custom props considered "resources"?
The complication is that session props, among a few other types of resource, are a single resource. Project inheritance works on the individual resource level; so you either have the inherited session properties, or your own. It cannot work on the level of individual session properties, because the project resource system is not aware of how to manage inheritance for individual resource types added by individual modules.
Thanks for the clarification. Makes sense why they are there on a new project but changes or additions don't show up automatically..... (sigh)
In the short-to-medium term, we're planning to make it more clear what the inheritance state of these resources is and allow you to choose to override changes. There's an outside chance, when that happens, that in the Designer, we'd be able to show some kind of conflict merge UI. No promises, though.
Instead, can you simply break the resources up into individual resources? Maybe a convert on first save rule like XML for Vision windows.
How would that work for session props? A bunch of tiny resources per key?
It is in the pipeline for 8.3 for other singletons like client/gateway/session event scripts, though. That's obvious, low-hanging fruit stuff.
One json definition file "X.json" for
session.custom.X and all of its nested elements. In other words, draw a line in the sand at a reasonable/intuitive level of granularity.
There's nothing fundamentally wrong with tiny resources. They just need to have deterministic content to be git-friendly.
Psst! Project events, too! One "X.json" for the event configuration, and "X.py" for the script. In folders by event type. Already noted.