Granting access to CMDB to edit fields

[jmbrake]

I am looking for a way to be able to give access to the CMDB for IT users to be able to modify fields, such as Manufacturer; OS Version; Supported By; Support Group and many more.   I have attached a screen shot of one of the CI's.   These users all have the itil role.   I don't want to just give these users the Asset role because it turns on or makes visible the modules Asset Portfolio; Inventory; Asset Contracts; Financial Mgmt; Organizational Mgmt.   All I want to do is allow them the rights to be able to "edit" the fields for a CI.   I think an Access Control List would do this, but I don't know how to make it work.   I created one and have also attached it.

[jmbrake · Accepted solution]

I figured it out.   Instead of creating a new ACL (cmdb_ci*); I used the existing ACL cmdb_ci for write.   I added in the Required Roles section the ITIL Role and tested successfully.   I took it one more step from there.   I decided I didn't want all ITIL users to have access to write to these fields and created a new role called "cmdb_user"; then added that in the Required Roles instead of ITIL.   In the Role cmdb_user, I am then able to manage which users or groups can have this access.     Thanks to all that responded, it did help lead me in the right direction.

[randrews]

one thing you may want to consider.. in the cmdb we created a section for controlled and uncontrolled attributes.. anything that is discovered is left as read only and put in uncontrolled area.. anything   NOT discoverable that has to be manually filled in goes in the controlled area.

we also created an uncontrolled role that we can assign to certain people and gave THAT role access to write to the uncontrolled fields...

[jmbrake]

Doug, great suggestion.   Do you have more details on how you did this?

[randrews]

on the form we added a section for controlled and uncontrolled attributes.. then moved those attributes off the main section and into those sections.. which work as tabs..

then created the role and set acl's to allow the role write actions on all uncontrolled attributes.. and gave the role to configuration management group and server operations group... they also provided a list of other people that should have the role...