- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-10-2015 08:42 AM
Hi,
I'm doing these exercises in my personal instance in order to increase my ServiceNow skills. One of the exercises is "Disallow ANY deletion of Task records (even admins)." I have created two ACLs, one which acts on the Task[task] table and which has a column value of None and which has a script that is simply 'false;', and another which acts on the Task[task] table and has a column value of * and with a script of 'answer = false'. They are both active, and neither of them has the admin overrides box checked. Nonetheless, I find that the admin role still has the ability to delete records when I type task.list in the filter text box and try and delete a random change record or something. I have a suspicion that this is because when you do task.list it simply brings up all the tickets in the system that are in the task table or in tables descended from the task table, and when I try and delete a record in the list returned by task.list what I'm really doing is just deleting a record on one of the child tables and so the ACL doesn't apply. However, what I believe this exercise is trying to do is instill the importance of never deleting records from any table so as not to creating dangling references, which would contradict that suspicion. I've also never heard of anyone directly using the base task table to store records and am unsure how to even go about creating/finding records on that table. Any help in clearing up my confusion would be greatly appreciated.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-10-2015 09:20 AM
Most likely there is an ACL for Change Request [change_request] table that overrides your Task table level ACLs. To get an idea of the order in which various ACLs are evaluated, refer to the following Wiki article:
Using Access Control Rules - ServiceNow Wiki
By the way, another possibility for preventing deletion of records is a 'before delete' business rule:
Scripting in Business Rules - ServiceNow Wiki
Blog: https://sys.properties | Telegram: https://t.me/sys_properties | LinkedIn: https://www.linkedin.com/in/slava-savitsky/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-10-2015 09:20 AM
Most likely there is an ACL for Change Request [change_request] table that overrides your Task table level ACLs. To get an idea of the order in which various ACLs are evaluated, refer to the following Wiki article:
Using Access Control Rules - ServiceNow Wiki
By the way, another possibility for preventing deletion of records is a 'before delete' business rule:
Scripting in Business Rules - ServiceNow Wiki
Blog: https://sys.properties | Telegram: https://t.me/sys_properties | LinkedIn: https://www.linkedin.com/in/slava-savitsky/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-10-2015 09:37 AM
Just to make sure, you unchecked Admin overrides on the form?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-10-2015 09:39 AM
Hi Robert,
You can also turn the debugger and check which ACL is granting the access. Please check section 8.Debugging for more info.
http://wiki.servicenow.com/index.php?title=Using_Access_Control_Rules
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-12-2015 09:18 AM
Yeah, I'd used the debugger before but given that the delete button isn't a field I didn't think it would be much help, but when I turned on the debugger and did Ctrl+F "delete" when I got to the form I managed to find the rule that was giving me access to delete the record, and it was indeed a rule that was specific to change as Slava suspected above. I think most if not all of the different child tables of task have these ACLs that are specific to them out of the box in the personal developer instance, so that's why I wasn't able to delete anything.