Understanding ACLs and Debug

[EricG]

I'm feeling really dumb at the moment.

We are getting our CMDB up and running.

I've verified all the data points and integrations, so data is getting in and updated automatically.

The OOB has CMDB editable by any user with ITIL.   I've removed that and left only Asset role.

I'm creating new field specific ACL's to allow users to update Managed By Group, Comments and a few other "Custom" data points.

In debug, the ACL results are not evaluating.

Is there something I've forgotten?

If I update the OOB cmdb_ci write acl that has the "Certification" role, the person I'm impersonating on the team can update/change all fields.

[Allen Andreas]

Hello,

Does that user have table write access as well though?

The field write comes after the table write, so if they can't write on the table, they can't write to the field(s).

Check to see if there was a cmdb_ci_server.* ACL added when you created the field specific ACL, which I believe does get auto-created, but then check the settings for it to make sure it aligns how you'd like.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[EricG]

OK, that makes a lot or sense.  I update these so infrequently that I thought that was the case, had tried doing table_name.* and table_name.blank, but nothing "Appeared to work" when I impersonated the user.  It's doing that now.

Final question, as my brain doesn't seem to be working (LOL).  What is the best practice going forward.

I only want specific fields "Editable".   Lets say Comments, Managed by Group, and a couple of more.

Is it:

1. Use UI Policies to make other fields "Read Only"

2. Add ACL's for each field to state NOBODY is the roles.

I need to make sure that if some adds a device manually, they can add info in all fields.

Thanks

[Allen Andreas · Accepted solution]

Hi,

Glad what I mentioned above helped guide you towards a resolution 🙂

For your question, it's more of a determination as to "when" they should be writable.

If you mean never writable, but only via server script/actions (if applicable, for example), then you'd want to utilize ACLs.

Otherwise, if you use UI Policies, or any client side scripting to prevent that behavior, you run into issues where in list view, the user could change the field or...if they're savvy...they can use browser developer tools for example, to make those fields appear and/or become editable.

When using the "nobody" role, you want to be careful there because even admins won't be able to use it as it overrides the admin override checkbox as well. So you could just set it with the admin role instead, but that's up to you.

Please mark reply as Helpful/Correct, if applicable. Thanks!