
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2017 01:46 AM
What is the best way to allow access to all classes/types under Configuration Items so that they are visible both as a module (if there is one) and in the list view. I want everyone with the role asset to have access to these objects for viewing.
- Is there a way to do this from base table Configuration Items [cmdb_ci] to all the tables that extend from it?
- Also, if I want to add a role for creating and updating only certain classes extended from Hardware class. Is there any good article that handles this relating to CMDB?
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2017 05:57 AM
Hi Henrik,
The security is hierarchical and contextual, so it is very flexible. The downside is that it is a bit complex to manage.
For #1, yes, create a role, and then create an ACL that grants read access to anyone with that role. If you grant read access on cmdb_ci for that user, it is inherited to the child classes. You can see an example of this on task. Per best practices, create a group and assign the role to that group, then as you add/remove people from the group, they automatically have the role granted/removed. This is preferred over granting access to individual users.
For #2, It is a similar approach. Grant your create and write operation ACLs on cmdb_ci_hardware and it is inherited to child classes for those with that role.
Docs: Access control rules
Docs: Contextual security

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2017 05:57 AM
Hi Henrik,
The security is hierarchical and contextual, so it is very flexible. The downside is that it is a bit complex to manage.
For #1, yes, create a role, and then create an ACL that grants read access to anyone with that role. If you grant read access on cmdb_ci for that user, it is inherited to the child classes. You can see an example of this on task. Per best practices, create a group and assign the role to that group, then as you add/remove people from the group, they automatically have the role granted/removed. This is preferred over granting access to individual users.
For #2, It is a similar approach. Grant your create and write operation ACLs on cmdb_ci_hardware and it is inherited to child classes for those with that role.
Docs: Access control rules
Docs: Contextual security

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2017 06:23 AM
Thanks, but looking at this screenshot:
Does that mean that mean I have to check the Create access controls and fill out a role in order for a user to see items in this table and everything underneath?
I'll take a look at the links you sent but the modules are not automatically shown in the Application navigator by default. It would be nice if this can be inherited as well.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2017 06:35 AM
Create access controls is normally not used once the table is created. It sets up default create, update, delete, and read ACLs for that role. I don't recommend using it as it will grant your itil role people with delete access in that mix. Bad idea.
Just create the ACLs by hand under System Security> Access Control

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2017 06:43 AM
Will this (ACL) also enable modules under Configuration Items in the application navigator?