How to run server side scripts as System so that it works for non-admin users?

Subhashree Sub2
Tera Contributor

‎05-15-2024 08:57 AM

Hi All,

 

I have a requirement to execute a script include which is querying sys_user table to fetch INACTIVE user's details. This script include code is not working for Non-Admin users as they can fetch only ACTIVE user's data.

I want the script include logic to execute normally as System (with privileged access) so that end users can perform testing for all users including INACTIVE.

 

I have tried below approach in my code but it doesn't seem to update "userCountry" in my case. Please let me know your suggestion.

Referred article: How to excute a script as system - Support and Troubleshooting (servicenow.com)

 

Please review below code and let me know how can I return the 'country' value and pass it to the Client side through GlideAjax.

 

 fetchUserCountry: function() {
        var exitUser = this.getParameter('sysparm_userid');
        var userRec = new GlideRecord('sys_user');
        userRec.addQuery('user_name', exitUser);
        userRec.query();
        var userCountry;
        if (userRec.next()) {
            userCountry = userRec.country;
        }

        var gdt = new GlideDateTime();
        gdt.addSeconds(5);
        gs.info("seconds: " + gdt);

	var script ="gs.log('***** DEBUG - sess:' + gs.getSessionID() + ', time:' + new Date().getTime() + ' - \\n' + GlideLog.getStackTrace(new Packages.java.lang.Throwable()), 'Stacktrace Debug');";
        //create the sys_trigger record to be executed by the schedule worker thread
        var sched = new ScheduleOnce();
        sched.script = script;
        sched.setTime(gdt);
        sched.setDocument(userRec);
        sched.setLabel("run this as system");
        sched.schedule();

	return userCountry;

    }

 

0 Helpfuls
  • 1,180 Views
1 REPLY 1

Marshall Parker
Tera Guru

‎05-17-2024 11:53 AM

A couple concerns here for you to evaluate:

 

1) ACL restrictions that are keeping non-admin users from seeing Inactive user records are most likely in place for a reason. You may need to evaluate the use case and determine do you really need or want to expose inactive user record details to other non-admin users. If this is a legitimate change for your environment, it may be that you need to adjust the ACL restrictions for a certain user role, depending on where & how this script include is planned on being used.

 

2) The linked KB does show how to use the scheduler for running as system user, however the article calls out this is a troubleshooting technique so I would be hesitant to use this method for a deployed production script include.

 

Those concerns aside - looking at your code, you have taken the sample code from the KB but have not adjusted it to apply to your scenario.

 

The sample code is saying that the variable 'script' should contain the full script of what you want to execute by the system user. In your case, you would need to build a script that calls the user table, filters to the specific record and returns the country field.

 

Since this execution will run independently of the script include finishing, you may need to determine where this value will be stored [i.e. is this SI called from a workflow, from a specific type of table, etc..] and you may need to identify where the value could be stored on a record, so that you can pass in the sys_id into your built up script variable and update the relevant record in that script call. 

0 Helpfuls