Planned start /end date should be editable for admin and Group A in all states

Anupriya_11
Tera Contributor

Hi Team ,

I have a requirement where the Planned Start Date and Planned End Date should be editable in all states for Admin users and members of Group A . For users who are not part of Group A, these fields should be editable only when the record is in the New state on On change form ,.

Could someone please assist with how to achieve this

 

Thank you

12 REPLIES 12

GlideFather
Tera Patron

Ahoy @Anupriya_11,

 

I just replicated in my PDI and it works like a charm! :))

 

Before you start, it is important to realise if you want to restrict only for editing (write) or for entering new value (create).

 

Based on the decision above, you will need one ACL definition for each field and for each operation:

  • change_request.planned_start_date
    • create
    • write
    • (delete??)
  • change_request.planned_end_date
    • create
    • write
    • (delete??)

Keep the "Admin overrides" checked ), it will let admins to have the permission and check also the Advanced field to have the script options in the bottom of the form, there you can use existing code taken from other ACLs:

if (current.assignment_group) {
    //replace the group's sys ID
    answer = gs.getUser().isMemberOf('77b0ad65c34522109e6298ec0501319c');
}

 

And then a user who has access to the change request record (itil) who is a member of the group can access the field but an itil who isn't member cannot edit that field.

 

Example of your ACL (you will need one for Planned start and one for Planned end)

Screenshot 2026-05-03 at 22.12.18.png

Check Advanced field as seen above and scroll to the script field and copy the code I shared above:

(replace with the group sys ID to match your requirement)

Screenshot 2026-05-03 at 22.12.27.png

Verification - user who has permissions to update orther fields who is NOT a member of that group:

Screenshot 2026-05-03 at 22.12.31.png

 

Verification - user who has permissions to update other fields who IS a member of that group:

Screenshot 2026-05-03 at 22.18.33.png

 

PS: if you want to debug ACL and permissions, go to Access Analyser:

Screenshot 2026-05-03 at 22.25.41.png

It provides insights to the ACL rules per given table, user, record, field, ... and it is an excellent tool!

 

_____
Answers generated by GlideFather. Check for accuracy.

@Anupriya_11 

 

i just noticed that the code I shared above is not correct, it will work as long as there is an assignment group but it will not work for changes with unassigned groups...

 

It shall rather be:

answer = gs.getUser().isMemberOf('sys_id_of_your_group');

 

Eventually to be debugged and adjusted accordingly.

_____
Answers generated by GlideFather. Check for accuracy.

Sorry, I am not able to edit my previous posts. I completely missed your part about the state.

 

In the Data condition add "State is not New", so the ACL will not be effective in this state and not members and non-admins will be able to update the field:

Screenshot 2026-05-03 at 22.47.49.png

 

 

 

 

_____
Answers generated by GlideFather. Check for accuracy.