Why a proposed field-permission state would leave the MJ system user short of its entity-level
access, or null when it would not.
Callers pass the rules as they would be after their change — with the edited row's new
values substituted, or the deleted row removed. Classifying the changed row on its own cannot
answer this question; see the module comment.
Answers null (permits the change) in three cases, each deliberate:
No system user resolves. A cold UserCache is the normal state during a process's own
bootstrap. Blocking an administrator on missing state would be worse than the risk, and
FindSystemUserFieldAccessViolations runs at startup precisely to catch whatever slips
through here.
The field is unrestrictable. Primary keys, __mj_ columns and the security-configuration
entities are forced open by the aggregation regardless of any row, so no rule about them can
restrict anyone.
The system user has no entity-level read. It is already denied one level up, where the
entity permission check has no exemption either, so field rules change nothing for it here.
Note this does NOT gate on EnableFieldLevelSecurity. Rules on a disabled entity are dormant
rather than gone — disabling deliberately preserves them — so gating would leave a three-step
hole: disable, strip the system user's rows, re-enable.
Why a proposed field-permission state would leave the MJ system user short of its entity-level access, or null when it would not.
Callers pass the rules as they would be after their change — with the edited row's new values substituted, or the deleted row removed. Classifying the changed row on its own cannot answer this question; see the module comment.
Answers null (permits the change) in three cases, each deliberate:
UserCacheis the normal state during a process's own bootstrap. Blocking an administrator on missing state would be worse than the risk, and FindSystemUserFieldAccessViolations runs at startup precisely to catch whatever slips through here.__mj_columns and the security-configuration entities are forced open by the aggregation regardless of any row, so no rule about them can restrict anyone.Note this does NOT gate on
EnableFieldLevelSecurity. Rules on a disabled entity are dormant rather than gone — disabling deliberately preserves them — so gating would leave a three-step hole: disable, strip the system user's rows, re-enable.