5 Replies · Latest reply on Sep 13, 2017 7:58 AM by Steve Hill

    Run Glide Query as Different User

      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.

        • Re: Run Glide Query as Different User
          Anurag Tripathi

          Instead of GlideRecord use GlideRecordSecure, it takes care of roles and ACLs itself


          Read more here


          Anurag Tripathi

            • Re: Run Glide Query as Different User

              Thank you for the reply.  I tried using GlideRecordSecure in both ways below.  It still does not find the record.


              var target = new GlideRecordSecure('hr_case');


                while (target.next()) {

                    // never hits this block



              and this...


              var target = new GlideRecordSecure('hr_case');

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

                 // never hits this block



              Am I using it correctly? 

            • Re: Run Glide Query as Different User
              Cory Seering

              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.




              I have strange and mystical powers.