User can edit other groups’ RITMs, Incidents, and Changes in the SOW.

[Aditya1204]

Users are editing RITMs, Incidents, and Change Requests belonging to other groups in the SOW. These should be read-only for them. How can we achieve this? It is working as expected in one instance but not in another.

[Voona Rohila]

Yes, ACL's should be configured for agents to not access other groups tickets.

You can first restrict the read access to those incidents according to your business requirement

[Community Alums]

To make sure users can only edit records that belong to their own group and see others as read-only, you need to control this using Access Control Rules (ACLs) and UI Policies or Client Scripts.

Here’s how you can do it:

1. Check the Group field and User’s groups:

   • Use ACLs on the tables (RITM, Incident, Change Request) to allow write only if the user belongs to the group on the record.

   • For example, create an ACL on the assignment_group field or the record itself that checks if the current user is part of that group.

2. Set the record or form to read-only if the user is NOT in the group:

   • Use a Client Script or UI Policy that runs on form load.

   • If the user’s groups don’t match the record’s assignment group, set all fields to read-only.

3. Why it works in one instance and not the other:

   • Maybe the ACLs or Client Scripts are missing or different between the two instances.

   • Also check that the users’ group memberships are correct in both places.

   • Sometimes, update sets or customizations don’t move properly between instances.

and try this client script

function onLoad() {
  var userGroups = gs.getUser().getMyGroups(); // server-side example, use GlideAjax for client side
  var recordGroup = g_form.getValue('assignment_group');
  if (userGroups.indexOf(recordGroup) == -1) {
    g_form.setReadonly(true);
  }
}

[Shubham_Jain]

@Aditya1204 

Since it works in one instance but not another, check:

• Are ACLs defined and active in both?
• Are the same groups assigned to users?
• Is the same logic used in UI Policies or Business Rules?
• Are there customizations or overrides in one instance?