Running Script with Elevated Access

[raprohaska]

I have a simple bit of script the updates a configurable set of fields:

///Pseudo Code
var gr = new GlideRecord(table);

gr.addQuery('sys_id', id);

gr.query();

if (gr.next()){

for each field/value {

      gr.setValue(field, value);

}

gr.update();

}

Some of the fields update and the others get set to "null". There seems to be a correlation from the fields that don't update to active ACLs... The odd part is, my user is an admin and has rights to update all of these fields. BUT, if I run while I have my access elevated to security admin, then they all get set just fine.

• I'm using glide record and not glide record secure.
• I need to run this script with elevated access even if it isn't an admin invoking the feature. (the script is located in a Business Rule)

Thanks in advance for any help you can give.

[bernyalvarado]

Hi Aaron, is any of the fields that are getting updated with a null value an OOB one that you can share so that we can troubleshoot to see what could be wrong?

Running a server side script (a business rule on this case) with elevated privileges from the server sounds a little bit odd. Would you agree?

Thanks,

Berny

[raprohaska]

Sorry I haven't replied in a moment. Lots going on. Thanks for all these ideas. I'll look at each closer to see which pan out for future needs. My issue ended up not being access related. I was confused as to why some fields were being updated and not for others which lead me to look at ACLs. BUT, it was much simplier. I'm constructing my glide record dynamically based on configuration. Meaning, new GlideRecord(configRecord.targetTableName). Well my target table was the base table, in this case CMDB_CI... but the fields I was trying to set were actually defined on CMDB_CI_Server... Of course this gave me a false view when I looked at ACL, the ACL was defined at the level the field existed, not CMDB_CI. I just had to reload the glide record based on the CI's sys_class_name and now all is well in the world.

Sorry to lead you astray but it appears there are some creative and useful ideas when I run into access issues in the future.

Thanks again to all,

AA

[jason_siegrist]

I would really like to have away to run a script Async in the context of a user with the role elevated "security-admin"

So I am looking for away to manage my 80+ instances with Okta. 

Admin is the easy one... but Security Admin has proven to be a challenge.  It is given via the group the user is a member of.  When I did the same thing with Security Admin it causes an error on OKTA and that halts all other syncs. 

The idea would be, based on specific criteria, when a user is added to a group it would also give that user Security Admin.

(function executeRule(current, previous /*null when async*/ ) {
    // when a user is added to a group
    // user gets secuity admin if the Group has it in the description
	var gdt = new GlideDateTime();
	
gs.log('BEER --1-- In Group Member Add-Okta   ' + gdt.getLocalTime().getByFormat('hh:mm:ss'));
	
    var roleID = new GlideRecord('sys_user_role');
    roleID.get('name', 'security_admin');
	
gs.log('BEER --2-- role SYSID ' + roleID.sys_id);
	
    var grprolechk = new GlideRecord('sys_group_has_role');

    grprolechk.addQuery('group', current.group);
    grprolechk.addQuery('role', roleID.sys_id);
    grprolechk.query();
    
gs.log('BEER --3-- current.group  ' + current.group);
gs.log('BEER --3-- roleID.sys_id  ' + roleID.sys_id);
    
    if (!grprolechk.hasNext()) {
        
gs.log('BEER --4-- USER does not have a record');
        
        //gs.addInfoMessage(gs.getMessage("Granting role") + ": " + roles.role.name + " = " + roles.inherits);
        var roleAdd = new GlideRecord('sys_user_has_role');
		
        roleAdd.initialize();
        roleAdd.role = roleID.sys_id;
        roleAdd.user = current.user;
        //roleAdd.granted_by = current.group;
        roleAdd.inherited = 'true';
        roleAdd.state = "active";
		roleAdd.setWorkflow(false);
        var itAdded = roleAdd.insert();
        
gs.log('BEER --5--  record Added  '+ itAdded);
    } 
})(current, previous);