ACL on incident table

[Chris200]

On the incident and other forms such as RITM/Catalog Task/Changes ect I have the Department field.  

I have a requirement that if the Department is set to certain values, say "ABC" then that record can only be read if the users have a specific role named "u_abc". 

I created an ACL on the incident table that is set to 
Type: record
Operation: read
Decision Type: Allow If
Name is Incident[Incident] *
Under conditions I specify the role u_abc. 

Under Data Condition I say Department is ABC.

It shows the number of records matching the condition is 4. 
Then under the script condition I also have:

(function() {
    // Define the allowed department value
    var allowedDepartment = 'ABC';

    // Allow access if the user has the 'u_abc' role and the 'u_department' field matches the allowed value
    if (current.u_department == allowedDepartment && gs.hasRole('u_abc')) {
        return true;
    }
    // Deny access otherwise
    return false;
})();

My problem is that even if a user does not have the role they can still see and interact with the ticket. How can I lock it down?

[Chris200]

Thanks for all the responses.
It isn't the field that I want to block access to, it's the entire record based on field value. It is a reference field. 

So here's how the logic should evaluate:

User comes to the incidents and if the department is set to a particular value on the form, the user cannot see the incident if they do not have the role. If they do have the role it opens up for them.  However, all other incidents that don't have that particular department set should open for them.
 
There is another read acl on the incident able, which is the default one that gives everyone access to see the tickets.

[J Siva]

Hi @Chris200 

Have you checked "Deny Unless" ACL?

[Ankur Bawiskar]

@Chris200 

for your requirement there should be only 1 table.None READ ACL because if there is more than 1 and if user satisfies that ACL and doesn't satisfy your new ACL it will give access

So ensure only 1 table.None READ ACL is present on your table

Also since this is for incident table ensure the OOB query business rule is also updated accordingly.

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Chris200]

Thank you all for the replies I am getting closer. So far I've had luck with two steps. 

1) I had to modify the existing read acl (system default one) with a Data condition  of Department IS NOT ABC.  
2) I had to modify my new ACL script to compare on the sysid of the department and not the department name (Ankur mentioned this, thank you). Once I did those two things it generally works, but I did notice one thing when you try to search for the ticket directly.  

The work notes, related records, and resolution tab are all still available for others if they search by the incident number. That seems strange. Even though the base form is completely hidden. Anyone know why that would be?

[Chris200 · Accepted solution]

Just to close the loop, I ended up with 9 ACLs + one BR to lock just the incident form enough for our needs.
3 for the main incident form. 
3 for the incident work notes.
3 for the incident task. 
And a BR to copy data from the main incident to the incident task when it was created. 

The three ACLs under each item were:
1 new ACL that setup the role and its permissions that we talked about above.  This was generally the same across all three except the script needed modified slightly for the incident task. We needed to account for it being a level deeper in the structure. We also did logic just to be safe that checked the department value on both the incident task and incident. This was overkill, I think.

For the Incident work notes we also updated the read ACLs for the sn_incident_write role and sn_incident_read roles putting exception in the Data Condition for Department IS NOT xyz. 

For the Incident task we also updated the read ACLs for the ITIL role and sn_incident_read roles putting exception in the Data Condition for Department IS NOT xyz. 

After putting those in place, everything worked as we wanted it to. I could set the department value on an incident to anything but the department I wanted to lock down and normal ITIL fulfillers could still handle the tickets. If the department was set to the one, I wanted locked, then only those with the correct role could see the tickets. 

After getting all that done, I was on a meeting with some SMEs from ServiceNow regarding ITOM and they brought up that domain separation may accomplish what we're looking to do much better. So we may be moving to that solution. Writing and maintaining so many ACLs for each and every form Incident, Change, RITM, SCTASK, Agile, etc would be a nightmare. 

Fun stuff.
Again, thanks for the feedback and input. You are all great.