sanker sanal wrote:
When I disable the None acl, user does not have access to the table and fields as "Security constraints prevent access to requested page"
when I enable it, it is providing access to all the fields as it is a table level acl.
Indeed. As I wrote higher up:
incident.NONE = a rule for the table itself. Think of it as a key to the room's door - if there's no table.none rule, all other field rules are redundant.
Without it, all other permissions don't count. The diagram in the documentation about the ACL processing order feels incorrect to me - it claims, fields rules are processed before table rules (which may be true) but my experimentation has shown:
- if there's no table rule then all field rules are blocked
- it's possible to have a table rule and no field rules and access is still granted
This suggests to me that - logically - table rules are processed first, then field rules to ascertain what level of access a user has to the table contents.
sanker sanal wrote:
Hi Dave
In my case only the created_by should be readable for the ITIL users, rest of the fields should be hidden. What should be the step that has to be followed?
Are you saying that those with the ITIL role should only see the "created_by" field and nothing else? Are there any other ACLs on this table?
It may help to create yourself a security model - a diagram depicting:
- what the object is (field, table, etc)
- what level of access is required
- what role is granted it (who)
Proper design is the key to good implementation. At present your requirements feel vague; clarify those then building it should be fairly easy.
