GRANT on a System.Image specialization writes a member access for the non-existent System.Thumbnail_Image (CE1613)

[Chendodelangen]

GRANT on a System.Image specialization writes a member access for the non-existent System.Thumbnail_Image (CE1613)

• mxcli version: v0.19.0 (2026-08-21T13:13:26Z)
• Mendix version: 11.12.2
• Severity: High — silent security-document corruption; mxcli check/exec report success, describe renders the rule clean, and only mx check/Studio Pro reveal it. REVOKE cannot remove the broken member access; even dropping and recreating the entity and re-granting reproduces it.
• Tracker searches: "Thumbnail_Image" (0 hits), "access rule image", "System.Image grant" → Security reconciliation (UPDATE SECURITY / CREATE ASSOCIATION) strips inherited members from access rules of specialized entities; damage masked by CE0066 and unrepairable via GRANT #758/Root cause: member/attribute enumerators don't walk the generalization chain (umbrella for #758, #703, #451) #765 cover the opposite symptom (inherited members being stripped); nothing covers an access rule gaining a member that does not exist in the target Mendix version.

Steps to reproduce

CREATE PERSISTENT ENTITY MyModule.CaseImage EXTENDS System.Image ("ImageNumber": Integer);
GRANT MyModule.SomeRole ON MyModule.CaseImage (READ ("ImageNumber"));

Then run Studio Pro's consistency check (or mx.exe check).

Expected

An access rule containing exactly the named members (plus whatever inherited members the platform requires), all of which exist in the project's Mendix version.

Actual

Two errors per rule set:

[error] [CE1613] "The selected association 'System.Thumbnail_Image' no longer exists." at Access rule of entity 'NCRManagement.CaseImage'

System.Thumbnail_Image does not exist in Mendix 11; the writer appears to expand inherited System.Image members from a hardcoded/system-model list that still contains it. mxcli describe entity renders the rule without the broken member, so the damage is invisible from mxcli's own surface, and REVOKE <role> ON <entity> followed by a fresh GRANT reproduces it. Confirmed on a freshly created entity after DROP ENTITY as well.

Workaround

Leave System.Image specializations without MDL-written access rules and add the rules by hand in Studio Pro.

• Diagnostic bundle: available, mxcli-diag-20260827-184627.tar.gz

[Chendodelangen]

Additional finding while working around this on v0.19.0: Studio Pro's own 'Update security' reconciliation strips the injected dead System.Thumbnail_Image member from access rules WITHOUT an XPath constraint, but leaves rules WITH an XPath constraint untouched, so a constrained rule keeps its CE1613 across reconciles. Also: mxcli's own UPDATE SECURITY statement does not strip the dead member either (and always ends in the #981 System-module error). Practical workaround ordering: write the rules unconstrained via GRANT, then one Studio Pro 'Update security' click cleans them.