Cross-scope table access issues: "...has been refused due to the api's cross-scope access policy"

davidmcdonald
Kilo Guru

I've created a scoped application, lets call it "x_scopedapp_a", and a second scoped app which provides some additional features to x_scopedapp_a, lets called this other one "x_scopedapp_b". This includes a "Copy" button to copy a record in a fancy way, but would be crossing app scopes to do it.

When I try to use a script to read, write, and insert into a table in "x_scopedapp_a" from a script in "x_scopedapp_b", I'm getting all sorts of cross-scope access issues.

Source descriptor is empty while recording access for table x_scoped_app_a_table: no thrown error
Security restricted: Read operation on table 'x_scoped_app_a_table' from scope 'Scoped app B' was denied because the source could not be found. Please contact the application admin.
x_scoped_app_b (SomeScriptInclude): Creating copy of: 76f7dd4adbafc0906eed8f423a961951
Security restricted: Access to api 'setValue(x_scoped_app_a_table.name)' from scope 'x_scoped_app_b' has been refused due to the api's cross-scope access policy
Security restricted: Access to api 'setValue(x_scoped_app_a_table.process_vulnerability)' from scope 'x_scoped_app_b' has been refused due to the api's cross-scope access policy
Security restricted: Access to api 'setValue(x_scoped_app_a_table.process_id)' from scope 'x_scoped_app_b' has been refused due to the api's cross-scope access policy
Security restricted: Access to api 'setValue(x_scoped_app_a_table.name)' from scope 'x_scoped_app_b' has been refused due to the api's cross-scope access policy
Security restricted: Create operation against 'x_scoped_app_a_table' from scope 'x_scoped_app_b' has been refused due to the table's cross-scope access policy

The table itself has had all of the cross-scope access options enabled on it.

find_real_file.png

In the application settings for x_scoped_app_b, I can see some Cross Scope Privileges being created, but for this table it's just a read one.

find_real_file.png

Changing the operation to Write or anything else doesn't appear to have any affect.

I feel like I'm missing something. Any thoughts?

1 ACCEPTED SOLUTION

davidmcdonald
Kilo Guru

I'm not sure why, but the issue has been resolved.

After a colleague clicked on "Publish to update set" on Application A, all of the cross-scope issues I was having have been fixed.

I'd like to know more about the cause of the issue, but clicking that button has resolved it.

View solution in original post

13 REPLIES 13

davidmcdonald
Kilo Guru

I'm not sure why, but the issue has been resolved.

After a colleague clicked on "Publish to update set" on Application A, all of the cross-scope issues I was having have been fixed.

I'd like to know more about the cause of the issue, but clicking that button has resolved it.

Community Alums
Not applicable

I was having the same problem today. Publishing to update set did not do the trick for me.

The Cross scope privilage record gets created automatically for read operation when reading records with GlideRecord in background script. This is not happening for write operation. Creating the cross scope access record for write manually did not help as well. This happens for me only for access between scoped applications. Scoped app to global or the other way round is fine.

I ended up creating a script include in target scope that makes the write operation. When calling my function from another scoped app the Execute API privilige record is added automatically (same as read table operation). This way I was able to make the write operation.

I am also interested to know more about this and how to mnage table access cross scope priviliges between scoped apps the right way.

Sravan K Nair
Kilo Expert

I am facing the same issue. I am using a Transfrom Map to write to a scoped table from a staging table and getting the same error even though the cross scope access has been enabled. 

Any info on the issue is appreciated

Cheers,

Sravan

Peter de Bock1
Mega Guru

hi Stravan, Marek and David,

Today I faced exactly the same issue "Access to api 'setWorkflow' has been refused due to the api's cross-scope access policy."

After analyzing I found the root cause and a solution for it. The root cause is that this function 'setWorkflow' is not supported in a scoped application. I doubt that it is feasible to allow this by configuring a cross scoped privilege as it is not an object (table, script include, ...).
To resolve it, you can create a new script Include in the global scope with a function which has the query and the setWorkflow in it. Then return your response. The setWorkflow can be used to disable Business Rules for Updates, Deletes and Inserts, though also so to circumvent Business Rule Before queries.

The setWorkflow is working 100% in a global scope script include 🙂

 

Example call:

var glSI = new global.your-global-script-include();
var responseObject = glSI.your-function();

 

Please mark helpfull or answered when when it does 🙂

 

regards, Peter