Cross-Scope access policy on a global scope table

thinker
Giga Contributor

I am writing a Custom Scoped Application. The application has logic to create, update and delete records in one of the Global scoped tables. However when it tries to delete a record, it gets a cross-scope error.

The reason is that the target table's Application Access does not allow delete (Can Delete unchecked). Understandable.

I read all about the Application Access Settings and understand that I shall create a cross-scope privilege record however the deletion is still refused unless the table's Application Access settings allow it. But then, if the table's Application Access settings allow it, then I don't even need the cross-scope privilege record.

I created a sample for it:

  1. Created a new table in Global scope, MyTable, with a field, Name. Set the table's Application Access to AllApplicationScopes with CanRead, CanCreate, CanUpdate and AllowAccessToThisTableViaWebServices.
  2. Create a new Custom Application, Test. Set the RuntimeAccessTracking to Tracking.
  3. Create another Custom Application, Test2. Leave the RuntimeAccessTracking to None.
  4. From within Test's scope, I execute a script to create a new record in MyTable:
    var rec = new GlideRecord('u_mytable');
    rec.u_name =  'A';
    rec.insert();
    
    // Adds cross scope privilege record for Execute operation on GlideRecord.insert
    // Adds cross scope privilege record for Create operation on u_mytable
    // It also adds the record in MyTable because there are these two cross scope privilege records with Allowed AND the table's Application Access allows CanCreate
  5.  From within Test2's scope, I execute a script to create a new record in MyTable:
    var rec = new GlideRecord('u_mytable');
    rec.u_name =  'B';
    rec.insert();
    
    // No cross scope privilege records are created because RuntimeAccessTracking is set to None
    // But the record is still added to MyTable because table's Application Access allows it
  6. Now from within Test's scope, I execute the following script to delete a record in Mytable:
    var rec = new GlideRecord('u_mytable');
    rec.addQuery('u_name', 'A');
    rec.query();
    if(rec.next())
    	rec.deleteRecord();
    
    // Adds cross scope privilege record for Read operation on MyTable.
    // Adds cross scope privilege record for Execute operation on GlideRecord.deleteRecord
    // However the delete is refused because the table's Application Access Delete is not allowed (CanDelete is unchecked)
  7. Then from within Test2's scope, I execute the following script to delete a record in MyTable:
    var rec = new GlideRecord('u_mytable');
    rec.addQuery('u_name', 'B');
    rec.query();
    if(rec.next())
    	rec.deleteRecord();
    
    // No cross scope privilege records are created because RuntimeAccessTracking is set to None.
    // However the delete is refused because the table's Application Access Delete is not allowed (CanDelete is unchecked)
  8. Looks like I have to enable CanDelete for table's Application Access settings. So I went ahead and did that.
  9. Then I executed the delete script again in Test's scope:
     
    var rec = new GlideRecord('u_mytable');
    rec.addQuery('u_name', 'A');
    rec.query();
    if(rec.next())
    	rec.deleteRecord();
    
    // Adds cross scope privilege record for Delete operation on MyTable.
    // Deletes the record in MyTable because the cross scope privilege record exists and table's Application Access for CanDelete is set to true.​
  10. Finally I went ahead and executed the delete script again in Test2's scope:
    var rec = new GlideRecord('u_mytable');
    rec.addQuery('u_name', 'B');
    rec.query();
    if(rec.next())
    	rec.deleteRecord();
    
    // No cross scope privilege records are created because RuntimeAccessTracking is set to None
    // The record is still deleted because the table's Application Access has CanDelete set to true​

Now if the table's Application Access is mandatory, why do I need the cross scope privilege records at all?

Also, the target ServiceNow instance's administrator may want to allow Test application to be able to delete records but not every custom application like Test2.

So how can an administrator allow certain applications on certain tables without opening them for modifications from every application?

Thanks,

Vipin

1 ACCEPTED SOLUTION

Brad Tilton
ServiceNow Employee
ServiceNow Employee

Hi Vipin,

I understand the use case here, but the policy of not allowing store apps to delete any records is not something we would grant an exception for. I think the best you could do is have your app identify those records via a flag or setting them inactive, and then your customer can decide what to do with them. That could involve manually deleting them or just leaving them inactive.

Even with the asset/ci deletions oob, our recommendation is to only delete accets/cis in order to clean up errors. Once an asset or ci record exists in production it could have any number of task records open against it, which makes it much more difficult to delete.

View solution in original post

17 REPLIES 17

Brad Tilton
ServiceNow Employee
ServiceNow Employee

I'm not sure that it's spelled out in the policy or not, but if you're a technology partner you can see the certification policy in the publisher portal.

Basically, all store apps have to be scoped apps, and a scoped app can't delete records from another table. There are sometimes exceptions made for scoped/global APIs, etc, but not for something like deletions.

Michael Domke
Tera Guru

I know this has been answered, but the way I get around this restriction is to build the functionality I need in the target scope itself and then call that custom functionality from my scoped app.

For example, I have a scoped application in which I'd like to manage sys_group_has_role relationships. The sys_user_has_role table is in the Global scope and does not allow application access to "Can delete". If I need to remove a sys_group_has_role relationship from my scoped app, I'm not allowed do it.

To get around this restriction, I add a method to a script include that is in the Global scope to do the work that would normally be restricted from my scoped app. From my scoped app, I simply call my custom Global scope method and there's no issue with access.

I'm able to add or delete from the sys_group_has_role table from my scoped app without issue.

Hope this helps,
Michael

verda
Mega Expert

I needed to reset the number counter at the beginning of each fiscal year. sys_number_counter table refused all modifications to cross-scope access to reset the counter until i built the business rule in global. done. Clean? no!!