Security reconciliation (UPDATE SECURITY / CREATE ASSOCIATION) strips inherited members from access rules of specialized entities; damage masked by CE0066 and unrepairable via GRANT

[TOFBuck]

Summary

On a Mendix 10.24 project, any operation that triggers mxcli's access-rule reconciliation — UPDATE SECURITY [IN <Module>], but also a plain CREATE ASSOCIATION in that module (output: Reconciled N access rule(s) ...) — strips all inherited members (attributes and associations coming from a generalization) from the access rules of every specialized entity in that module. Own (non-inherited) members are kept. A rule that consisted only of inherited members ends up empty (CE0004).

Two aggravating factors make this dangerous:

1. The damage is masked. After the reconciliation, mx check only reports CE0066 ("Entity access is out of date...") on the module (plus CE0004 if a rule ended up empty). The real damage — a large CE2729 cascade ("No read access to attribute 'X' in entity 'Y' for user role 'Z'") on every page/widget that uses the stripped inherited members — is suppressed while CE0066 is present. It only renders after clicking Update security in Studio Pro. In our case that was 172 hidden CE2729 errors behind an apparently "almost clean" mx check. CLI-only/AI-agent workflows will happily ship this state.
2. The damage cannot be repaired via mxcli. GRANT <role> ON <Module>.<SpecializedEntity> (READ (InheritedAttr, ...), WRITE (...)) prints Granted access ... but does not persist: a subsequent DESCRIBE ENTITY shows no rule members and mx check still reports CE0004. REVOKE + fresh GRANT behaves the same. Only Studio Pro can restore these rules (or a git restore of the model).

Environment

• mxcli v0.16.0 (windows-amd64)
• Mendix project version 10.24.16.96987 (.mpr v2 with mprcontents/)
• Validation: mx.exe check from the matching Studio Pro 10.24.16 installation

Reproduction

Starting point: a project where mx check reports 0 errors, containing in MyModule:

• MyModule.Attachment extends System.FileDocument with an access rule for role Editor: read (FileID, DeleteAfterDownload, HasContents, Size, Name, Contents), write (Name, Contents) — i.e. only inherited members;
• MyModule.Item extends OtherModule.Base with access rules containing a mix of own and inherited members.

Steps:

mxcli -p App.mpr -c "UPDATE SECURITY IN MyModule"
# output: Reconciled 4 access rule(s) in module MyModule

Result:

• DESCRIBE ENTITY MyModule.Attachment → the entity now renders without any grant (rule stripped empty).
• DESCRIBE ENTITY MyModule.Item → rules only contain the own members; every inherited attribute/association (including write rights on inherited members) is gone.
• mx check → only 2 errors: CE0004 (empty rule on Attachment) + CE0066 (module security out of date). No CE2729 errors are reported at this point.
• Open the project in Studio Pro 10.24 → click Update security → 170+ CE2729 errors appear for pages/widgets referencing the stripped inherited members.

The same reconciliation (and the same stripping) also happens without ever calling UPDATE SECURITY, e.g. when creating an association in the module:

mxcli exec create-association.mdl -p App.mpr
# output: ...
# Reconciled 4 access rule(s) for new association
# Created association: MyModule.Child_Parent

So plain domain-model authoring via MDL silently corrupts the security of other entities in the module.

Failed repair via mxcli

mxcli -p App.mpr -c "GRANT MyModule.Editor ON MyModule.Attachment (READ (FileID, DeleteAfterDownload, HasContents, Size, Name, Contents), WRITE (Name, Contents))"
# output: Granted access on MyModule.Attachment to MyModule.Editor
mxcli -p App.mpr -c "DESCRIBE ENTITY MyModule.Attachment"
# → still no grants rendered; mx check still reports CE0004

REVOKE followed by a fresh GRANT gives the same result. Grants that only touch own members of non-specialized entities persist fine.

Expected behavior

• Reconciliation should preserve rights on inherited members (they are valid access-rule members in Studio Pro).
• GRANT on inherited members should persist (or fail loudly instead of reporting success).
• If reconciliation intentionally rewrites rules, mx check should not understate the result; the CE2729 cascade should be visible without a Studio Pro round-trip.

Possibly related

• ALTER ENTITY ADD ATTRIBUTE drops system members (createdDate) on sibling generalization root — CE1613 across inheriting entities #657 (unit re-serialization dropped system-member configuration of sibling entities — fixed in v0.13.0; same "writing document A corrupts entity B in the same unit" family)
• Create or modify import/export mapping silently skips attributes inherited from a generalized (parent) entity #703 (inherited attributes silently skipped in import/export mappings)
• GRANT VIEW ON PAGE reports success but does not persist page access (allowed roles stay empty; CE0557) #696 (GRANT VIEW ON PAGE reports success but does not persist)
• GRANT with XPath WHERE clause produces empty access rules (permissions lost) #431 (GRANT with XPath WHERE produced empty access rules)