Web Services: Non-Admin unable to query "sys_user" table

MattGlew
Giga Contributor

This is an odd one; it only seems to be possible to query the sys_user table if one is a member of the admin role.

 

The non-admin I'm testing with has the 'soap' role, and has read + write access to all fields in the sys_user table (confirmed by logging onto the instance in a browser etc.), however they return no results when attempting to query the table using web services. No error is thrown, they simply get no results (same for other non-admin accounts). The exact same code when run using an admin's credentials successfully retrieves records.

 

I don't have any query business rules in effect for non-interactive sessions, so am stumped!

 

Can anyone offer any advice / suggestions etc.?

 

Matt

1 ACCEPTED SOLUTION

MattGlew
Giga Contributor

Solved; my test WS user was first added as a member of a custom security role. This role was later added to the soap security role. For some reason this sequence of events (adding users to roles / roles to roles) meant that my actual test user hadn't been delegated soap access.



As soon as I added a test user directly to the soap role I got results... So removed group from the custom role, re-added it and got lots of info messages about adding users to roles. Bingo.



This was SO frustrating! ServiceNow is horrifically optimistic - it just doesn't "do" error messages!! I can't believe that without a SOAP role I didn't get an error when attempting to query a table!! I just got served an empty recordset, as though everything was fine! Grrrr....  


View solution in original post

7 REPLIES 7

MattGlew
Giga Contributor

How can I identify a Business Rule that's being fired during a non-interactive session?



When I logon to my ServiceNow instance and look at the debug modules; they only appear to be relevant to the current interactive session? If I enable 'Debug Business Rule' and then filter the sys_user table I can see from the debug info that the Business Rule "query user" is being fired, however it has a condition of "gs.getSession().isInteractive()", so wouldn't be applied in a non-interactive session...



Help!


To be 100% sure you could add a log statement to the business rules in question.



gs.log('business rule xyz got fired', 'my BR test');



Then perform your soap test and check the log for all entries where the source is 'my BR test';



But if the business rule already has that condition it will not be fired as the condition will not evaluate to true …


MattGlew
Giga Contributor

Solved; my test WS user was first added as a member of a custom security role. This role was later added to the soap security role. For some reason this sequence of events (adding users to roles / roles to roles) meant that my actual test user hadn't been delegated soap access.



As soon as I added a test user directly to the soap role I got results... So removed group from the custom role, re-added it and got lots of info messages about adding users to roles. Bingo.



This was SO frustrating! ServiceNow is horrifically optimistic - it just doesn't "do" error messages!! I can't believe that without a SOAP role I didn't get an error when attempting to query a table!! I just got served an empty recordset, as though everything was fine! Grrrr....