ACL stops saving other fields when you dont have write access after a specific field

[Oliver D_sereck]

Hi Community,

I have a question I am currently having problems with, I will keep it simple as the basic idea is the problem I am trying to get around:

Scenario:
- ITIL User A can read all Incidents, he is also in Group A, but not in Group B
- All Incident write access has been reduced as follows:
- Users may write to an Incident if they are a member of the Group in the Assignment Group
- (For completion, Users may always create Incidents and write to Incidents if the Assignment Group is empty)

So we got the following Incident:
Assignment Group: Group A
Short Description: Help 1
Description: Test Incident 1

ITIL User A may read and write to this Incident. He opens the Incident, changes the description and short description and saves => All OK
ITIL User A is still in the same incident, changes the description, short description AND the Assignment Group (to Group B) => Not OK. Only the Assignment Group is saved, his changes to the description and short description are lost.

And why? Pretty simple. The ACL giving write access evaluates every single field, not the whole row at once. So have a look at this:
Saving Field A > Check ACL (Assignment Group = Group A) > OK Write entry
Saving Assignment Group > Check ACL (Assignment Group (old) = Group A) > OK Write entry
Saving Description > Check ACL (Assignment Group (new) = Group B) > NOT OK, dont write entry
Saving Short Description > Check ACL (Assignment Group (new) = Group B) > NOT OK, dont write entry
etc etc etc...

I have gotten around this problem using a flag which gets set using a "before update" Business Rule. But this only worked for new entries with Assignment Group = Group B. And not existing entries. I wont go into details but it seems the "before update Business Rule runs after the ACL checks.

So yeah...is there a way to tell the ACL to check the Assignment Group last? Or is there any other way of shifting access while still being able to save the rest of the fields before the access is removed from the User?

Thanks for any help about how ACL's really work in the background and their ordering,
OD

[thomas_fregin]

Hi OD, so far as I know is an explicitly with ACL assigned write access on a higher level than a ban. I would try to define ACL's (how you described above) so that the permissions are role-and/or group-dependent. And than define additional ACL's with write rights for the necessary fields and the ACL's script-writing privileges depending on condition, e.g. including: if current.assignment_group.changes () && ... {
Maybe not the best way but I would it try in this way..., kind regards, Tom

[thomas_fregin]

Hi OD, so far as I know is an explicitly with ACL assigned write access on a higher level than a ban. I would try to define ACL's (how you described above) so that the permissions are role-and/or group-dependent. And than define additional ACL's with write rights for the necessary fields and the ACL's script-writing privileges depending on condition, e.g. including: if current.assignment_group.changes () && ... {
Maybe not the best way but I would it try in this way..., kind regards, Tom

[Oliver D_sereck]

Hi Tom,

Thanks for your reply. I just cant get my head around this problem, everytime I think I have a solution, the ACL comes around and destroys it anyway. I dont want to create an explicit ACL for every field, that would be a nightmare for the client Admins (and for anyone else really) and it just doesnt look very good...also, it doesnt really solve the problem. As soon as the Assignment Group is changed and saved, every other ACL will return false and stop saving the rest of the fields.

Let me show you my flag system:
Field "flag" (boolean) on INC.
ACL allows write access when flag == false
Business Rule (before update): When Assignment Group is filled and flag is false, set flag to true.

So basically, this allows someone to create a new INC with an Assignment Group where the User isnt in (or create an INC without Assignment Group, saving, and then changing it afterwards). Unfortunately this only works once. Once the flag is set, it cannot be removed again as the Assignment Group is always filled to some degree.

Tom, could you describe your possible solution a little more? Or could you try it on a SNC Demo system for me?

For everyone test if they want to reproduce:
Go to demo.service-now.com
Activate high security
Change the ACL for the incident table that checks if you have the "itil" role and incident state != 7:
Add "answer = gs.getUser().isMemberOf(current.assignment_group);" in the script. Save
Personate the ITIL User, change INC0000039 (assignment group = "IT Finance CAB" and any other fields)

[Oliver D_sereck · Accepted solution]

For anyone reading up, having the same problem:

1. Trying to use previous. in addition to current. would have been a nice solution, but doesnt work.

2. From Patch Aspen: 04-25-2012_1204 onwards, the Problem has been SOLVED. Changing multiple fields, including those that would remove your write access after saving will now be properly saved to the database! Hurra! (Dont expect to find this change in the patch notes thought 😉