Having issues with ACLs

bookman1502
Giga Expert

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?

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


View solution in original post

9 REPLIES 9

bookman1502
Giga Expert

Let me clarify something: when I say "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," I mean they become read only to the non-admin user on both other user's records and his own record, whereas I only want the former to happen.


Hi Robert,



You should start by enabling ACL Debugging, and then trying to read the records again. Pay special attention to the output messages, and make sure you understand what the icons and summaries mean.



It will probably be helpful to attempt to view the User record outside of the ServiceNow frameset, after you enable debugging. You do this by navigating directly to the user record:


https://YOURINSTANCEURL.com/sys_user.do?sys_id=SOMELONGSYSIDHERE



I've also dounf that it helps to navigate to non-existant pages between attempts, so that the output from the *previous* page view isn't appended to the *current* page view. I do this by opening a second tab to a non-existent page:


https://YOURINSTANCEURL.com/this_page_doesnt_exist_woo.do



You can use the debug messages to figure out which rule or rules are blocking your users from editing their own pages, and make updates accordingly.


Thanks for pointing out the ACL debugging feature. I'm not entirely sure yet how viewing the user records outside of the servicenow framework helps but this has definitely given me more to play around with.


Hi Robert,



Viewing the records directly, and visiting non-existent pages between views- just helps to reduce the log output to only the stuff relevant to this page load. Otherwise, you could end up with a bunch of lines from whatever the preceding transaction was.



Sometimes it's not much info, but if for some reason the left-nav had to be refreshed (for example) you could end up with a bunch of ACL logging for the applications and modules records that are evaluated to build the nav in addition to the output you actually care about.



I've found it a valuable way to reduce inconsequential or unwanted output.