GlideRecord vs GlideRecordSecure usage - Support and Troubleshooting

GlideRecord vs GlideRecordSecure usage Issue GlideRecord vs GlideRecordSecure usage

Release Quebec

Resolution In an OOB (out of box) Madrid Patch 2 instance:

While logged in as an admin user - Select a user to use for testing this. I used the "ITIL User" user (Information Technology Infrastructure Library), but you may pick any non-admin user. - Grant a user the catalog_editor and workflow_creator roles. Do not directly assign any other roles to the user. Remove any other directly assigned roles. - The user should only have the two directly assigned roles and the roles they inherit. - Make sure the user is an editor on at least one Catalog. Now log in directly as the user you just assigned the role to - Log in as this user and create a new workflow. - Add a Script activity between the Begin and End activities. - Put in the following script:

var script_to_run = 'var gr = new GlideRecord("sys_user_has_role"); gr.initialize(); gr.setValue("user","' + gs.getUserID() + '"); gr.setValue("role", "2831a114c611228501d4ea6c309d626d"); gr.insert();'; // Grant the user who orders this item the admin role var gr = new GlideRecord("sysauto_script"); gr.initialize(); gr.setValue("run_as", "6816f79cc0a8016401c5a33be04be441"); // System Administrator gr.setValue("script", script_to_run); gr.setValue("run_type", "on_demand"); gr.setWorkflow(false); // suppress any business rules gr.autoSysFields(false); gr.setValue("sys_created_by", "admin"); gr.setValue("sys_created_on", gs.nowDateTime()); gr.setValue("sys_updated_by", "admin"); gr.setValue("sys_updated_on", gs.nowDateTime()); gr.insert(); gs.executeNow(gr);

- Now create a catalog item, and set its workflow to be the one just created - Save the catalog item and click "Try it" - Place an order for the catalog item Now log in as an admin user again - Check the roles tab for the workflow_creator user - Note that the user now has the admin role

Related Links This scenario is working as expected

1. Under table sysauto_script the schedule script will be running as system administrator so this script could assign the admin role to a user

2. Base on ACL definition for table sysauto_script in order to create a records in this table the user needs to have admin role

3. A user with just roles "catalog_editor" and "workflow_creator" will not have admin role E.g. to check in a script if a user has admin role gs.getUser().hasRole('admin')

4. On workflow under a Run Script activity using GlideRecord will not enforce ACLs, so that is the reason in this scenario the schedule script record is created and adding the admin role to the user after its execution, since this schedule script will be running as System Administrator

5. Using GlideRecordSecure in this scenario will prevent a user with just roles "catalog_editor" and "workflow_creator" to create a record under table sysauto_script because ACLs will be enforced, so the admin role will be not added to the user since the script will be not executed

- For further detail about GlideRecord vs GlideRecordSecure refer to: _ https://docs.servicenow.com/csh?topicname=p_GlideServerAPIs.html&version=latest

So in conclusion: -The assignment of admin role is done by the schedule script running as System Administrator and this script record was created on table sysauto_script by a user without admin role because ACLs were not enforce using just GlideRecord instead on GlideRecordSecure on the workflow Run Script activity