I’ve noticed that if I make any changes to the Perspective session properties (add a custom property, add a property change script, add a binding to a custom property) none of the changes are saved with the project. So I can’t add my own custom properties unless I have a script run to do it in every session - and then can’t add property change scripts or bindings to that property. Is there a different way to go about performing an action when a session property changes?
What’s the build number? Some of these things were fixed recently.
8.0.0-beta0 (b2019031502)
This sounds a bit like an issue I have run into, see if this doesn’t help as a workaround for the time being.
http://forum.inductiveautomation.com/t/bug-designer-edits-not-being-saved-implemented/23299
I am also having this issue. In perspective I can create a SESSION CUSTOM property like I can on any other view, but I cannot save this change. Saving shows ‘No changes to save’ in the bottom left corner and closing and opening the designer wipes any custom session property I added.
The workaround, restarting the ignition server, did not work for me as of the latest build `8.0.0-beta0 (b2019032002)
1 Like
Hi -
Are you all still seeing this issue on the latest build?
If you ARE still seeing this, could you supply the view.json file for the offending View, as well as the content you are ATTEMPTING to supply in the same post?
For example:
Yes, this is still happening on today’s build. Right now I’m trying to make a new property session.custom.plant with a value of 1.
props.json (812 Bytes)
It’s not on a view, it’s on the session. As you can see, we actually created a script on the “authenticated” property at one point - but that script is no longer visible or accessible from the designer. It’s still working but can’t be edited or seen except from the file on the gateway.
Here’s what my session props look like in the designer when I first start the designer session (no script visible on authenticated):
Following these steps:
Create a New Project.
Replace
Inductive Automation\Ignition\data\projects\<project_name>\com.inductiveautomation.perspective\session-props\props.json
with the provided props.json file.
Open Designer.
I can see your script in place.
After modifying your script to include logging (irrelevant - I just wanted to modify it to see if it would save) and adding in a session.custom property “plant” and setting its value to 1, I saved the Project, quit the Designer, and re-opened the Designer and the script was still present, as was the new custom property.
Next steps:
Do you have any Session OnStartup/onShutdown scripts in place?
Is this a child project, a parent project, or a stand-alone project?
Do you have any File Explorer/Finder windows open to the directory which contains the props.json file?
Following your next steps:
- I do have an onStartup session script. It creates the custom property that I was unable to save, so the same property is generated each time the session starts.
- The project is a child project.
- No.
The fact that it’s a child project appears to be what is causing the problem! When I save the custom property on a new, stand alone project it works as expected - when I create a new child project under the auto-generated “global” project, I can’t save custom properties to it.
Unfortunately, almost all of the QA projects are children of a “global” project, and they do not exhibit this issue, so it’s unlikely the result of your project being a child of the “global” project, unless yours contains something which other user’s projects do not.
What makes this even MORE unlikely is that Session props are only inherited during project conception - so inheritance shouldn’t factor in here.
Is your Session startUp script anything other than session.custom.plant = 1 ?
Session startUp scripts ARE inherited… Does your Parent project have any Session startUp/shutDown scripts?
The parent project does not have any Session Event scripts. The only thing in the global project is shared scripts.
In the child session startup script there is a bit more going on right now, stuff we might add to a binding if we could create the property:
gateway = session.props.gateway.address
assigned_plant = project.dbFunctions.getAssignedPlant(gateway)
session.custom.plant = assigned_plant
type_ds = system.dataset.toDataSet(['Value'], [['SAMPLE']])
type_array = shared.jsonArray.dropdownDataSetToOptions(type_ds)
session.custom.sampleTypes = type_array
Here’s our global session props, if that’s useful:
props.json (499 Bytes)
I created a stand alone project called TEST_PARENT, edited the project.json file to set "inheritable": true which then allowed me to create a child project called TEST_CHILD_OF_PARENT from TEST_PARENT.
After saving CHILD I can see that its session-props/props.json file is exactly the same as PARENT's, specifically it included my custom property:
"custom": {
"testing": "value"
}
This doesn't sound like it should be expected does it?
I mis-spoke when I said they aren’t inherited. What I meant to convey is that CHANGES to a Parent Project’s Session Properties are not conveyed to children which already exist, as this could obliterate a child project’s values.
So after the child project has been created, you will not see Session Property changes in the parent also appear in the child. This behavior is different then if you were to make a new View in a Parent Project, as that View WOULD be visible/usable by any children.
I’ll edit the older post for clarity.
I think I found the solution. The session-props\resource.json was the culprit. Our project had “overridable” set to false and I noticed that all the new parent projects I created had that set to true.
I’m not sure why this had changed though. It definitely wasn’t something we manually changed ourselves.
1 Like
Ah, I’m betting that Parent project is back from the VERY early days of the Beta - before we set the default for overridable to True. There was a script floating around that fixed the issue by finding all overridable properties and swapping them to True, but it sounds like you’ve been skirting the issue this whole time.
@SMcIntosh: Does your accompanying resource.json include the same value for “overridable”?
Replace the value in question with true and see if that resolves the issue.
Yes, issue resolved (“overridable”, not “inheritable” though). Thank you everyone for the help!
1 Like