ACL for child table

[krishnakumar2]

Hi Community,

I have a requirement to expose one (State) field from alm_consumable table to users having inventory_admin role. Currently this table does not have any ACL of it's own and are being inherited by alm_asset table. And ASSET table has asset, asset_user and few other roles added.

So, here is what I did.

Added Table level ACL on alm_consumable for inventory_admin role

And added state field ACL for inventory admin.

Above ACLs exposed all the fields for inventory_admin users. so, I had to add few more fields level ACL using asset and asset_user roles for all other fields.

I am worried that this is not right. So, any guidance/help you provide will be of great assistance?

[jMarshal]

If you only want to provide field level view of "alm_consumable.install_status" to those with "inventory_admin" role, you should be able to do that with just the field level AC - you don't need the table-level AC...depending on your use case.

If you need those with "inventory_admin" to be able to navigate to the data on the table in order to manipulate it, the table-level AC is needed and it seems like you've done this right.

However, if those with "inventory_admin" are getting the data on a different form by way of a script or reference field, report or dashboard, etc...only the field-level AC should be needed.

Also, don't forget about the wildcard field-level AC (alm_consumable.*) so you could probably replace the "few more field level ACs" with one wildcard - this would limit access on a field level to all fields on the table, so you can expose the table to "inventory_admin" role, but none of the fields -- except for "install_status" explicitly (with a specific ACL on that field).

[krishnakumar2]

Hi, thanks for your immediate response. Actually, I was thinking the same. Just having field level ACL on alm_consumable should provide editable field to inventory_admin. Unfortunately that's not the case. If I do not provide Table level ACL, no matter what ACL I add for field level, it does not work. 

I do not want navigation access, users will come from stock room and eventually open the consumables from there. All I need is, when users open consumable, they should be able to update/modify install status of the consumable record. And only Install status no other field. All other fields should remain read only. 

If I add Table level ACL, it provides editable access to all the fields and I will have to manually add field level ACLs for all other fields or wild card ACL (*). 

Another question: Most of the ACLs are derived from allm_Asset table for consumable. So, if I add new table level ACL, will the ACLs from alm_asset continue to work or newly added ACL on alm_consumable will override that? Sorry, this ACL never ceases to confuse me 😞

[jMarshal · Accepted solution]

I can relate - Access Control rules are difficult to evaluate and predict as they're not ordered and have particular ("non-intuitive"?) inheritance rules - and as such, difficult to conceptualize and plan!

If you add AC rules to alm_consumable (which extends alm_asset), those rules will only apply to alm_consumable and not be enforced when looking at alm_asset directly. IE - if someone has access to "alm_asset.name" and you put an AC on "alm_consumable.name" which is restricted to a role they don't have...they will still be able to access that filed on alm_asset (for records IN that table).

Hope it helps, good luck!