Query Business Rules against OOB Rest calls

[Hamza Berouil2]

Hi all,

We would like to use the OOB REST API to get a list of incidents.

End users (with restricted access) should be able to retrieve a list of incidents and because of performance issue we want to use the "sysparm_limit" parameter.

Unfortunately, in some cases it does not work as expected (we get 403 forbidden error) and we know why ! It's because a read ACL and here are the details :

Lets say for example Bob Employee has access to 10 incidents among 20, if he triggers REST call with   "sysparm_limit=2", then the system retrieves the 2 first rows (incidents), if Bob does not have access to both incidents then he will get a 403 error (dues to the ACL)

Now if he puts sysparm_limit=10, the system will return only the incidents to which he has access and are among the first 10 incidents that returns the query without applying (there will be probably some incident hidden and in this case the user will less than 10 incidents). Of if he does not have access to all the first 10 incidents then he gets 403 error.

Actually this is the same issue you get when show incident list (you get the message : Number of rows removed from this list by Security constraints : x). The solution would to use a Before Query Business Rule to hide the error message, so we thought the before QBR would resolve our but it soudsn like the Before Query BRs don't apply against OOB REST calls,

am I wrong ? is there any workaround ? how about scripted REST APIs, can I use them instead the OOB APis to resolve the issue ?

Thank you in advance

Rgeards,

[vab_13]

Thanks Hamza. I executed a quick test and yes you are spot on with this.

Root Cause is the execution order and I do not think there is a way around this.

Let me check if we have anything on this.

[Hamza Berouil2]

Hi Vab,

Thank you for your answer.

Actually we were wrong, the Query Business Rule which is not applied on REST calls is triggered only   if the user interacts with ServiceNow interface (i.e. gs.isIntrecative()), which means the external calls are always excluded, we just need to remove (replace) this from the BR conditions. And this is not an OOB behavior.

The solution is not so complex as we expected