Hi,
I have a strange problem. I'm trying to set the value of a system property that's in a different scoped application. To make matters more complicated, I'm actually executing a script include when someone clicks on a UI action on a form in my application, which then calls a script include in global scope, which then calls a REST API to get a value, and sets (and reports back) the value of this system property which is yet in a different application scope:
If I click on the UI Action on my form, the form loads and then displays the message "Now allowing update of property: propertyName". I thought that this for sure would have something to do with cross-scope access settings, so I tried executing my script include from a background script to see if I can provoke an "access to scope denied" log message.
But, to my surprise, executing my script include from a background script worked, even if my scope is selected in the "Run script in scope" dropdown. I can see in the operations table that there was a successful update to sys_properties.
I then tried executing my script from a scheduled job (also in my app scope), and there it gets even weirder. If I click on "Execute Now" in the scheduled job, the script executes just fine, similar to the background script. If I click on the "Test script" button, I get the same error as when I'm executing the script from the UI action on my form: "Not allowing update of property...".
For fun, I then created an async BR in my app scope, in which I called my script include. In this BR, it also worked flawlessly.
So I guess my question is this: why do I get different results when executing the same exact script call from different places in my application? If this was a cross-scope access problem, shouldn't the result be the same from every object in my application scope, regardless of wether it's a scheduled job executed with "Execute Now", "Test script", a BR, or a UI action?
Thanks in advance for your help,
Max
 
