Edit fields after incident is closed

Pedro33 · 3 weeks ago

Is it possible to allow a specific group to edit certain Incident fields after the Incident is closed?

I need members of one group to update a few fields after the Incident state is Closed. I already verified the user's group membership with a Script Include, but the fields remain read-only.

What is the recommended approach? Should this be handled with UI Policies, ACLs, or another method?

Umar Akbar · 3 weeks ago

@Pedro33,

Yes, this is possible. However, its not a best practice and should avoid on Incident records.

Still, if that's a hard requirement at your end, here's how you can do that:

1. Add a record-level write ACL (the "building key").

ACLs at the same level evaluate with OR, so you don't have to edit the OOB one (leave it alone - editing OOB records invites upgrade pain). Create a new incident / write ACL whose script grants access when the user is in your group, even when closed:

answer = false;
var state = current.getValue('state');
// 7 = Closed, 8 = Cancelled — verify against your state choice list
if (state == 7 || state == 8) {
    answer = new YourGroupCheck().isUserInSpecialGroup(gs.getUserID());
    // or simply: answer = gs.getUser().isMemberOf('Your Group Name');
}

Now, when closed: normal itil users fail both ACLs and stay locked; your group members pass this one and get record write access.

2. Scope it to the specific fields.

Step 1 opens the whole record for the group. To keep it to a few fields, the cleanest path leans on the fact that the form automatically renders any ACL-read-only field as greyed out — you don't need a client script for that. So:

Copy/deactivate the OOB "Make fields read-only on close" UI Policy and, in your version, remove your target fields from its read-only actions. Now those fields aren't force-disabled on the form.
For the group, the record-write ACL from step 1 makes them editable. For everyone else, they stay read-only because those users fail the ACL and the form greys them automatically.

If my answer has helped with your question, please mark my answer as the accepted solution and give a thumbs up.

Best regards,

Umar

View solution in original post

Tejas Adhalrao · 3 weeks ago

hi @Pedro33 ,

Yes, this can be handled using a field-level Write ACL. Create a Write ACL for each field that should remain editable after the Incident is Closed, and use a script/condition to allow only members of the specific group.

For example, the ACL can allow access when the Incident is closed and the user belongs to the required group. Also check whether an existing UI Policy/Client Script is making the fields read-only, because an ACL alone won't override a client-side read-only setting.

For security, use the ACL as the actual access control and UI Policy only for the UI experience.

Regards,
Tejas

If you found my solution helpful, please mark it as Helpful and Accept Solution.

KrushnakumaT · 3 weeks ago

@Pedro33,

Use a field-level Write ACL to allow the specific group to edit the required fields when the Incident is Closed, and verify that no UI Policy is forcing those fields to remain read-only.

Nishant8 · 3 weeks ago

Hello @Pedro33 , Although this is technically possible, I recommend not changing this behavior. Instead, try to find an alternative, such as extending the auto-close period from the resolved to the closed state.
If you still wish to change this behavior after analyzing all aspects, you will need to make adjustments in a couple of places: UI Policies and ACLs.
UI Policy: Review the OOB UI policy, 'Make fields read-only on close', and make the necessary adjustments, or create another policy that makes the desired fields editable.
ACL: There are OOB Write ACLs that allow editing fields for specific roles. Review them and make the necessary adjustments.

Should you need any assistance while implementing this, please feel free to reach out. Will be happy to help.

Regards,

Nishant

Pedro33 · 3 weeks ago

Hello @Nishant8 , i know that is not the best pratice but thank for the help.
I already saw that UI policy and if i need to change the behavior its better to create a new UI Policy and deactivated the OOTB UI Policy.
About the ACLs, thank you for the tip.

Best regards