ITIL Users should have read only access to the CMDB tables....Is there an other way to approach this rather than making it read only for each cmdb table ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-06-2018 07:11 AM
As an ITIL user, EDIT Option should not be available for CMDB Tables. They are Read Only........
ITIL Users will have read only access not write or create access. How to approach this ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-06-2018 07:21 AM
That's going to depend on the structure of your CMDB and the ACLs that are already in place. Unfortunately, there's probably not a single ACL you'll have to adjust to make it work. You can make it easier by starting at the root of the structure though. I would start with the 'cmdb' and 'cmdb_ci' tables' 'write' ACLs and remove access for the 'itil' role. Then just work your way down to more specific tables and fields. You can easily target the ACLs you'll need by filtering for ACLs that contain 'cmdb' and the 'write' operation.
https://YOURINSTANCENAME.service-now.com/sys_security_acl_list.do?sysparm_query=operation%3Dwrite%5EGOTOnameLIKEcmdb_ci%5EnameSTARTSWITHcmdb_ci
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-06-2018 07:25 AM
What if we create a single business rule on cmdb_ci and it gets inherited to all of its child table. Write a logic to prevent editing if a user is an ITIL or some other specific conditions?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-06-2018 07:33 AM
You could do that, but I would advise against it. If you were to do it, you would want a business rule that would run on insert/update, check to see if the user had the 'itil' role specifically, and then use 'current.setAbortAction(true)' to abort the submission. There are a couple of problems with this though. The first is that the UI would still be open and give an indication to the user that they actually could update so it would be a bad user experience. The second is that you might have specific workflow situations where the updates aren't necessarily a direct button click on that record that could get hung up on your business rule when you didn't intend for that to happen. It can be done either way, but I think the ACL route is much cleaner...although it may take a bit longer.
