True when a rule takes access AWAY rather than granting or abstaining.
Deny is the only restricting value within a single rule. No Access is the aggregation's
identity element: it can leave a role without access, but it can never remove access one of the
user's other roles granted.
This answers a question about one rule, not about a change. Whether a CHANGE restricts a
user is a property of the aggregate across every role they hold — setting each of a user's roles
to No Access in turn writes no Deny anywhere and still ends with the field denied. So this
is sound for an INSERT, which can only add rules and therefore cannot remove an existing
Allow, and is NOT sufficient for an edit or a delete. Those must project the resulting rule
set and aggregate it — see EntityFieldInfo.AggregateFieldRulesForUser.
True when a rule takes access AWAY rather than granting or abstaining.
Denyis the only restricting value within a single rule.No Accessis the aggregation's identity element: it can leave a role without access, but it can never remove access one of the user's other roles granted.This answers a question about one rule, not about a change. Whether a CHANGE restricts a user is a property of the aggregate across every role they hold — setting each of a user's roles to
No Accessin turn writes noDenyanywhere and still ends with the field denied. So this is sound for an INSERT, which can only add rules and therefore cannot remove an existingAllow, and is NOT sufficient for an edit or a delete. Those must project the resulting rule set and aggregate it — see EntityFieldInfo.AggregateFieldRulesForUser.