ATF Failure in scoped applications.

[Srikanth Menava]

Hello All,

 I've created an ATF for a scoped application in my dev environment, It was running fine and I moved it to test. TI cloned back Dev from TEST. Then 'run server side' step in the test giving me an error.

Basically, I am submitting a record producer and it will create a record in a table and also creates an RITM, I am trying to open the record submitted and open a field having "i" icon. Below is the error code.

Test failed due to JavaScript error executing step:
JavaException: com.glide.script.fencing.CrossScopeAccessNotAllowedException: Access to Step.sibling from scope x_gdot_pir_scope not allowed
at:21


Full logging from step execution:
15:52:37.534 Loading script: jasmine_lib/jasmine31.js
15:52:37.737 Successfully loaded jasmine_lib/jasmine31.js
15:54:07.738 Security restricted: Execute operation on API 'Step.sibling' from scope 'PIR Scope Document' was denied. The application 'PIR Scope Document' must declare 

my run script test has the below code in it.

did anyone faced this?

[Laszlo Balla]

Hey Srikanth,

Right, the issue is all the same, except this this, you need to grant access to the change_request table and not an API.

To answer your questions: basically it happens because because the underlying artefacts (everything is an XML code at the end) changed. Or at least, that's how the system sees it. So this is expected behavior every time one of these artefacts change - even a system patching can invalidate these permissions.

You can transfer the cross-scope privilege records in an update set, however I recommend listing them specifically in your runbook too. As you cannot run ATF in production, you will not have this problem there 🙂

This is typically a result of the application or the artefacts having a Caller Restricted setting on them, instead of Caller Tracking.

[Srikanth Menava]

Thanks for answering my questions @Laszlo Balla 

I,ve created the below 

but still I got the error.

Test failed due to JavaScript error executing step:
com.glide.script.fencing.access.ScopeAccessNotGrantedException: read access to change_request not granted

Please help me fix this.

[Srikanth Menava]

@Laszlo Balla 

 it is automatically changing it to 'Requested' state after runing the test.. WIERD..

[Laszlo Balla]

It is strange indeed. Can you perhaps check with ServiceNow Support why does that happen? In my opinion, once you set this to Allowed, it should stay that way.

[Laszlo Balla]

Also, write the table name without capitalization, i.e. 'change_request'. Not sure if this matters.