Run Glide Query as Different User

mspeers
Kilo Contributor

We have some business rules in place to create an incident from an hr case (Case Management) if the case should have been an incident (and vice versa, creates an hr case from an incident if it should have been an hr case to begin with.)

We then keep the two records in sync, when changes are made in one, it updates the other.   The problem is, when changes are made in the incident, the changes aren't syncing in the hr case table because the user with access to incidents does not have access to the hr case records (and shouldn't).   The GlideRecord query on our "hr_case" table returns no results (though the record does exist) because it is seemingly filtering out records for which the current user has no access.   This seems like out of the box behavior as we do not have any 'where' clause on the query (shown below, 'current' is the current incident record):

var target = new GlideRecord('hr_case');

if (target.get('u_incident_ref', current.sys_id)) {

// syncLogic is here, but this block never runs because

// the 'get' returns no results because the query executes

// under the context of the user with no access to the hr_case table

}

Is there any way to execute queries like this under the context of a system user with elevated rights?   That way, we can programmatically execute queries and updates on records under scenarios like this, without granting additional permissions to users who shouldn't have those permissions under normal circumstances.

1 ACCEPTED SOLUTION

coryseering
ServiceNow Employee
ServiceNow Employee

Hi Michael,



This doesn't sound correct. The query run from the business rule isn't subject to ACLs. For instance, an itil user, by default can not read records in the sys_script_include table. Yet a business rule like this (set to run Before update):


Screen Shot 2016-04-26 at 3.56.06 PM.PNG


Will result in a message like this:


Screen Shot 2016-04-26 at 3.57.49 PM.PNG



If the Itil user updated an incident.




GlideRecordSecure actually does use ACLs to restrict access when doing queries from script. In essence, you are describing a situation where GlideRecord is acting like GlideRecordSecure. However, I do not believe that is the problem. Instead, I believe there is a Before Query business rule on hr_case which is adding additional query parameters. Those do run when you do a query via GlideRecord, and can change the results of a query to prevent results from returning.



It looks like there is a default Business Rule in the Human Resources Core plugin which does exactly this:


Screen Shot 2016-04-26 at 4.06.42 PM.PNG


Screen Shot 2016-04-26 at 4.07.18 PM.PNG



It is possible to query without running the Before Query business rule. In your script, before you get the record, try adding target.setWorkflow(false);


This turns off the Business Rules for that particular query action, and therefore skips the additional parameters added by the Before Query rule on hr_case. However, it also turns off all the other business rules that might be running on that operation. If you plan on doing something with that target record, you may prefer to change the condition under which that Before Query rules runs instead.



Thanks


Cory


View solution in original post

9 REPLIES 9

Cory,


Kind of related to this, I have a need to 'open up' a specific user reference variable in the catalog to allow selection of disabled users that are restricted by a before query BR.


I thought I might be able to use an advanced reference qualifier on the variable with the setworkflow('false) somehow in the query, but not sure if if this is possible?


Hey, 

for some reason it did not worked for me.

I set my business rule to run on before 50 (while restric query runs on before 100), I add the set workflow(false) but still wasnot able to change a field on HR case via incident with an assigned to without an HR role.

my business rule:

before 50 (on update)

var gr = new GlideRecord(current.u_created_from.sys_class_name);

if(current.assignment_group != previous.assignment_group)
gr.u_converted_to_assignment_group = current.assignment_group;
if(current.assigned_to != previous.assigned_to)
gr.u_converted_to_assigned_to = current.assigned_to;
if(current.state != previous.state)
gr.u_converted_to_status = current.state;
gr.setWorkflow(false);
gr.update();

Hey,

I have exactly the same issue, but for some reason this solution is not working for me. please take a llok and tell me if i'm doing something wrong:

my buisness rule runs on before update (order 50, the resctric query is running on 100)

 

var gr = new GlideRecord(current.u_created_from.sys_class_name);

gr.setWorkflow(false);

gr.get(current.u_created_from.sys_id);

if(current.assignment_group != previous.assignment_group)

   gr.u_converted_to_assignment_group = current.assignment_group;

if(current.assigned_to != previous.assigned_to)

   gr.u_converted_to_assigned_to = current.assigned_to;

if(current.state != previous.state)

   gr.u_converted_to_status = current.state.getDisplayValue();

//gr.setWorkflow(false);

gr.update();

I'm just taking the time to log in to say you literally just saved my life with this reply lol. we went live with something and didn't anticipate the script includes to be running with ANY issues because they run as system. The same thing must have been happening to me with the query restrictions. I can't explain enough how much you just saved me haha. THANKS!

Runjay Patel
Giga Sage

Check out this video, it will clear all your doubts and help you to understand Business Rule queries in details.

Link: https://www.youtube.com/watch?v=hLottNnk21U&ab_channel=ServiceNowHelpdesk

It help you to understand below points.

  • Scenario based business rule uses
  • Best business use cases for all types of business rules
  • Current .update in before business rule
  • Difference between Before BR and Before query BR?
  • Where can we use query business rule?
  • All type of business rule with real world scenario
    • Before
    • After
    • Async
    • Display

 

Please mark reply as Helpful/Correct, if applicable. Thanks!!