Having issues with ACLs

[bookman1502]

Hi,

I'm doing these exercises on my personal instance to try and gain proficiency in ServiceNow. One of the exercises under the system security section is "Allow admins to update all user records and everybody else to update their own record." Initially, I created two new access controls: one which had the Name field set as User[sys_user] and * set as the field to control access to. It had no scripts or conditions and simply had admin in the Roles section. In retrospect this probably wasn't necessary given that it appears that admin overrides all the access controls for writing to the user table anyway, but oh well. The next access control I created also had the Name field set as User[sys_user] and * set as the field to control access to. It had no roles or scripts but it had the condition User ID is javascript: gs.getUserID(). This was meant to keep users from updating user records that weren't their own. However, creating these rules didn't appear to change anything, and the only way I seem to be able to control access to fields on the user table to non-admins is by making changes to the update rules specific to the field (e.g. sys_user.title, sys_user.department, sys_user.email).At first this made sense given that ServiceNow prioritizes more specific access controls over more general ones, but even when I make these access controls inactive all that happens is that the fields become read only, so somehow the second access control I created isn't working.

At first I thought my condition might be bad (although I can't see how it would be), so I created this script instead of having the condition, but it still didn't work:

if (gs.getUserID() == current.sys_id)

      answer = true;

else

      answer = false;

Can anyone help me figure out what might be gong on?

[bookman1502]

I see what you're saying. One issue I'm running into is that when I click on the name of the rule that denied access in order to go to the access control I can't see anything because of course I'm impersonating someone who has no roles. This seems to undercut the purpose of those links given that only admins can see ACLs. I guess the only solution is to copy the name of the rule from the debug output and go back to being an admin role in order to look at it?

[coryseering]

Hi Robert,

You are correct, you have to un-impersonate to get your access back. The reasoning is fairly simple- there is no way for the system to know that you want to impersonate this user when accessing this form but not when accessing this other form.

Impersonation gives you the experience that user would have. If that user can't access ACL's, neither can you (while impersonating). It's possible to build a system that only did impersonation for a single transaction or something, but there is a trade-off in terms of use and time spent. It would make debugging easier some of the time, but is that enough to justify building out that system versus enhancing the SLA Engine, or creating the scoping model?

I usually test in two browsers (Chrome and Firefox), or in Chrome and Chrome (Incognito mode). This side-steps the issue, since only one of your sessions will be impersonating, and the other has the access needs required. You can copy/paste links, or just look at the rule name being output, and navigate there manually in the other browser.

Have you figured out the root cause yet?

[bookman1502 · Accepted solution]

Well, after fiddling around with the debugger and making various changes to access controls, I've somehow managed to get the system to behave the way I want to. After I managed to get everything working I originally thought it was due to a bad script, but then I compared it to what I put in my original post and it's the same. The way I have it now is that I have inactivated all of the access control rules for specific fields on sys_user, and instead have an update rule which applies on all the fields in the table and which requires admin, and I have another update rule which applies on all the fields in the table and which has the following script (the same as what I had before):

if(gs.getUserID() == current.sys_id)

{

        answer = true;

}

else{

        answer = false;

}

Given that this should be the same state I described above in my original post, I believe that what happened was that something about the system was not actually how I described it before and somehow going through the debugging process and making various changes accordingly just shook it all out. Thanks again for the help. I'll definitely be relying on that debugger if I have ACL issues in the future.

[Michael Fry1]

I think your script is fine, but you need to rules: one for Read, one for Write, both with that same script and no roles. Your test User shouldn't have any roles either.

[bookman1502]

Thanks for your suggestion. It makes sense you would want your test User to have the least level of access possible when testing ACLs, which in my case would be a user that has no roles. I also see what it would be important to have both write and read access control rules, even though right now I'm only concerned with who can update what.