Planned start /end date should be editable for admin and Group A in all states
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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)
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)
Verification - user who has permissions to update orther fields who is NOT a member of that group:
Verification - user who has permissions to update other fields who IS a member of that group:
PS: if you want to debug ACL and permissions, go to Access Analyser:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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:
Answers generated by GlideFather. Check for accuracy.