ACL rule removed - why access now?

[Kenneth Zabrisk]

After a plug-in install, certain users couldn't edit form fields.

We couldn't figure out what had changed.

In desperation, we disabled a new ACL rule.  Users could now edit as before.

Why?   According to SN documentation, ACL rules are cumulative "unlocks" not "locks".  In other words, a user only needs to pass one (of several) table level rules to have access to the table and only one (of several) field level rules to have access to the field.   Why would removing one of the "unlocks", suddenly allow a user access?

[Allen Andreas]

Hi,

Without specifics of your exact scenario, we can't really say...but it sounds like an ACL of table.* was introduced. With the introduction of that type of ACL, it would then set the stage for permissions of the fields on records.

• So there's a table.none ACL...for the table
• Then a table.* ACL...for ALL fields
• Then a table.field ACL...for specific fields (which would override the generic table.* ACL)

So just from experience and giving an educated guess...it sounds like you didn't have a table.* previously, so all the fields were able to be written to (for example)...but then the introduction of a table.* came in (with a role or something people didn't have) -- to then cause this to play out the way it did.

If I'm way off...please give more information.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Kenneth Zabrisk]

Thank you.  Agreed that what we are seeing is that the old *.* ACL, which gave access, is not executed when a table.field rule exists that fails to give access.

[Kenneth Zabrisk]

So, one more clarification.    Field rules are checked as follows:

1. Match the table and field name. For example, incident.number.
2. Match the parent table and field name. For example, task.number.
3. Match any table (*) and field name. For example, *.number.
4. Match the table and any field (*). For example, incident.*.
5. Match the parent table and any field (*). For example, task.*.
6. Match any table (*) and any field (*). For example, *.*.

Do I interpret correctly that if ACL rule(s) exist at step N but all fail to give access, SN will not check for anything at step N+1?  It will only go on to Step N+1 if there is nothing at step N?  Or does it simply not go to Step 6 unless there were no ACLs before it?

[Allen Andreas]

Hi,

It is going to consider ALL of those places.

First assuming no one has access and then checking those 6 steps for any one that gives access. Once found, it allows it to pass.

As you researched and found, like in this example here: https://developer.servicenow.com/dev.do#!/learn/learning-plans/sandiego/new_to_servicenow/app_store_...

It's going to search from most specific to least in that order, but that order none the less.

I actually think there's a typo in there where for field level that documentation and what you wrote shows: *.number (step 3) and this part not only seems untrue, I don't think it's even possible. You can go to ACLs yourself and try and create a *.field_name and you can't. I think that's a typo and not really a step at all.

I'd recommend referring to this support article and pay close attention to the field level evaluation, this one seems more accurate to me: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0541355

That one only consists of 5 steps and makes sense. Having step 3, like in your example and what was included on the Dev Site (my first link)...doesn't even make sense because then that would mean anywhere in the platform if you had access to *.number -- all number fields would then be accessible anywhere in the platform and that just isn't correct in how ACLs work and how you would set them up anyway (both technically and literally).

Please mark reply as Helpful, if applicable. Thanks!