Admin for devs/BAs after a clone?

[Chris H2]

Dear community,

After a clone from production to one of our 8 sub-production instances, we need members of certain groups (Developers, Testers, BAs, Trainers) to have/keep the admin role. These groups/users don't have admin in Prod due to our organisation's security policy. I don't want to use Data Preserve Rules, otherwise I would have to manually set up new sub-production admins (/ remove this access) in each instance every time someone joins/leaves.

I tried writing a Clone Cleanup Script to automatically reset admin access every time there is a clone. This works when I run it as a background script, but fails when the clone runs:

// Grant admin to specified groups in all sub-prod instances
var logSource = 'PostCloneScript';

// List of groups to grant admin role
var subProdAdminGroups = [
	'0a52d3dcd7011200f2d224837e6103f2', // ServiceNow Developers
	'f10d0444ffa33100158bfffffffffff3', // ServiceNow Testers
	'3cc3c7680b982300cac6c08393673a03', // ServiceNow BAs
	'2156c3a80b982300cac6c08393673a7e' // ServiceNow Trainers
];

// Delegate admin role to each group
var message = ['Delegating admin to groups'];
for(var i in subProdAdminGroups){
	var groupID = subProdAdminGroups[i];

	// Get group GR to print name in logs
	var groupGR = new GlideRecord('sys_user_group');
	if(groupGR.get(groupID)){
		try{
			var groupName = groupGR.getValue('name');

			// Check if group already has admin role
			var groupRoleGR = new GlideRecord('sys_group_has_role');
			groupRoleGR.setLimit(1);
			groupRoleGR.addQuery('role','2831a114c611228501d4ea6c309d626d'); // admin
			groupRoleGR.addQuery('group',groupID);
			groupRoleGR.query();

			// Remove if group already has admin; clean assignment is better for inherited roles
			if(groupRoleGR.next()){
				groupRoleGR.deleteRecord();
			}

			// Delegate admin role
			groupRoleGR.initialize();
			groupRoleGR.setValue('role','2831a114c611228501d4ea6c309d626d'); // admin
			groupRoleGR.setValue('group',groupID);
			var result = groupRoleGR.insert();
			message.push((result ? 'Success - admin role' : 'Error - admin role not') + ' granted to group ' + groupName + '\n');
		}
		catch(e){
			gs.log('Error message thrown when trying to delegate admin to group:\n' + e.message,logSource);
		}
	}
	else{
		message.push(['Error - group with sys_id ',groupID,' does not exist'].join(''));
	}
}

gs.log(message.join('\n'),logSource);

There are no errors caught on line 42; the logged message on line 51 appears confirming failure, but the following warning does appear in the logs:

User system does not have the role 'sn_templated_snip.template_snippet_admin' which is required to grant/remove 'sn_templated_snip.template_snippet_admin' under application administration, Resource: 'record/sys_group_has_role/create'

(Source: RoleAccessHandler)

It looks like the system user lacks the access to delegate one of the admin-inherited roles. Is there any way to grant the system user this access?

Otherwise, I can't be the only one with this problem - does anyone else use anything besides a post-clone cleanup script?

Look forward to hearing everyone's thoughts,

Chris

[Willem]

Hi Chris,

Have you considered using Exclude tables and a Data preserver? That way you can exclude users from being copied over from Prod to your target instance. With the Data preserver you can preserve the Users(sys_user table) and Roles(sys_user_role table).

Reference:

Exclude table

Data preserver

[Chris H2]

Hi Willem,

I did consider using preserve/exclude data rules - this is our workaround until I can get the script working again - but this is a bit messy since I need to manually manage admin access in all 8 sub-production instances every time someone joins/leaves the team.

New York also introduces an OOTB checkbox option for preserving user data during clones, but this also doesn't meet our use case since we WANT access changes in prod to propagate down to sub-production instances.

Thank you for your suggestion,

Chris

[Kieran Anson · Accepted solution]

This is part of KB0784172 which was fixed in London (PRB1281549).

Might be worth reaching out to HI to ensure your system user has this role added and your instance is correctly patched to avoid this sort of mishap in other areas.

[Chris H2]

Thank you Kieran, that looks to be the one! I'll raise a HI case with this as the suggested cause, and mark this as correct if this fixes the issue.

Many thanks,
Chris