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

[Anupriya_11]

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

[GlideFather]

Hi @ChallaR,

may I ask you why do you recommend an approach with BR? your business rule has no conditions so it will triggered ALWAYS! How that can be recommended script? By whom?

Your code has a condition

if (current.planned_start_date.changes() || current.planned_end_date.changes()) {

but it is after it was already triggered. Wouldn't it be better to make the BR's condition to be executed only if one of the 2 fields changes? This would trigger your BR for every record change to evaluate false, it is better not to trigger it if not possible.

Not only that, also your BR will abort the operation so the user spends time on updating a record and then after submission it will not be saved, it will lead to confusions and eventual data loss as the record will not be saved and end user might not notice.

Wouldn't it be better to apply ACL and if the user is not allowed to update a field, then it will be directly read-only with no confusion and directly when loaded? Instead of finding that they are missing rights after time spent on it for nothing?

This question comes with good intentions, I am trying to understand this approach, can you explain your motivations?

Thanks!

EDIT:

Also wondering about the notes in the end:

• Make sure "Group A" is the exact group name
  • GF: that shall be handled by sys ID, no?
• Confirm that 'new' is the actual state value (sometimes it might be 1 instead of 'new' depending on your setup)
  • GF: be careful about the state value
    

     

[GlideFather]

@ChallaR, any chance to discuss your approach?

[GlideFather]

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!

[GlideFather]

@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.

[GlideFather]

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: