GRANT/CREATE ASSOCIATION on Document-hierarchy entity silently strips sibling entities' inherited access rules; DOWNLOAD FILE creates empty action

[WouterHooglandTOF]

mxcli bug report (draft — needs lead developer approval before submitting)

mxcli version

v0.16.0 (2026-07-12T11:44:17Z)

Mendix version

10.24.20.105674 (from mx check output: "Mendix 10.24.20.105674")

Severity

High. Silently strips previously-granted read/write access on unrelated,
pre-existing entities — a security regression with no error or warning at the
time it happens. Only surfaces later via mxcli docker check / mx check
(CE0004/CE0005/CE0066), by which point the damage is already committed to the
.mpr file. Confirmed on this project (backup-mode copy; no production impact
here, but would be severe on a live model).

Summary

Three distinct operations in this project (module MiniCompetitie) each
independently trigger a "reconcile access rules" step that destructively
strips inherited-attribute read/write grants from unrelated, pre-existing
entities in the same module — entities never referenced by the triggering
statement. A fourth, unrelated defect: DOWNLOAD FILE produces an empty
action when used to freshly create a microflow.

Bug 1 — reconciliation strips sibling entities' inherited-attribute grants

Triggers (all three reproduced independently, each sufficient on its own)

1. CREATE ASSOCIATION from a new entity to an existing one, anywhere in the module.
2. CREATE ENTITY ... EXTENDS <entity-with-its-own-access-grants> (e.g. extending
   MiniCompetitie.Document, which itself has a GRANT statement).
3. GRANT <roles> ON <entity> (read *) / (read *, write *) — a wildcard
   entity-access grant on ANY entity in the module.

Effect

Every other entity in the module that:

• extends (transitively) an entity with its own inherited attributes
  (e.g. System.FileDocument via an intermediate Document class), and
• has existing GRANT statements referencing those inherited attributes

...loses the inherited-attribute portion of those grants. Own/direct
attributes and associations are preserved; anything inherited (FileID,
Name, Contents, HasContents, Size, DeleteAfterDownload from
System.FileDocument, or UUID/DocumentType/BewerkStatus from the
project's own MiniCompetitie.Document) is silently dropped from the grant.
Entities with no own attributes/associations (e.g. CSVExportFile,
OFormulier) lose their grants entirely (down to zero rules).

Console output during the triggering operation includes a line like:

Reconciled 10 access rule(s) for new association

or

Reconciled 10 access rule(s) in module MiniCompetitie

This is logged as informational, not an error — nothing signals that
destructive changes just happened to unrelated entities.

Reproduction (minimal, isolated)

Starting from a clean project (mxcli docker check → 0 errors):

-- Trigger 3 in isolation (no new entity, no new association):
grant MiniCompetitie.ContractBeheerder, MiniCompetitie.Inkoper, MiniCompetitie.VastgoedRegisseur
  on MiniCompetitie.NotitieBijlage (read *);

(where NotitieBijlage is any pre-existing entity extending System.FileDocument)

Before:

grant MiniCompetitie.FunctioneelBeheerder, MiniCompetitie.ContractBeheerder, MiniCompetitie.Inkoper, MiniCompetitie.VastgoedRegisseur
  on MiniCompetitie.Bijlage (read (DateCreated, IsDeleted, UUID, DocumentType, FileID, Name, DeleteAfterDownload, Contents, HasContents, Size, Bijlage_MiniCompetitie));
grant MiniCompetitie.DocumentGenerator on MiniCompetitie.Bijlage (read (FileID, Name, DeleteAfterDownload, HasContents, Size));
grant MiniCompetitie.Inkoper on MiniCompetitie.Bijlage (read (...8 attrs...), write (Name, Contents)) where '[...]';
grant MiniCompetitie.VastgoedRegisseur on MiniCompetitie.Bijlage (read (...8 attrs...), write (Name, Contents)) where '[...]';

After (same describe entity MiniCompetitie.Bijlage):

grant MiniCompetitie.FunctioneelBeheerder, MiniCompetitie.ContractBeheerder, MiniCompetitie.Inkoper, MiniCompetitie.VastgoedRegisseur
  on MiniCompetitie.Bijlage (read (DateCreated, IsDeleted, Bijlage_MiniCompetitie));
grant MiniCompetitie.Inkoper on MiniCompetitie.Bijlage (read (Bijlage_MiniCompetitie)) where '[...]';
grant MiniCompetitie.VastgoedRegisseur on MiniCompetitie.Bijlage (read (Bijlage_MiniCompetitie)) where '[...]';

— DocumentGenerator's grant is gone entirely, and every inherited attribute
(UUID, DocumentType, FileID, Name, DeleteAfterDownload, Contents,
HasContents, Size) and the write permissions are gone from the remaining
three. MiniCompetitie.CSVExportFile and MiniCompetitie.OFormulier (no own
attributes) end up with zero grant statements at all.

mxcli docker check afterward reports:

[error] [CE0004] "No access rights granted." at Access rule of entity 'MiniCompetitie.Bijlage'
[error] [CE0004] "No access rights granted." at Access rule of entity 'MiniCompetitie.CSVExportFile'
[error] [CE0004] "No access rights granted." at Access rule of entity 'MiniCompetitie.OFormulier'
[error] [CE0005] "Constraint is set even though no read, change or delete access is granted." at Access rule of entity 'MiniCompetitie.CSVExportFile'
[error] [CE0005] "Constraint is set even though no read, change or delete access is granted." at Access rule of entity 'MiniCompetitie.OFormulier'
[error] [CE0066] "Entity access is out of date. Please update security..." at Domain model of module 'MiniCompetitie'

Attempted workaround that made it worse

Re-running GRANT ... (read (FileID, Name, Contents, HasContents, Size, DeleteAfterDownload))
to restore the stripped attributes does not restore them — the command
reports success (Result: read (...) showing only the attributes that were
already present, silently dropping the new ones) but on a second attempt it
cleared the row entirely (Result: (no access), and describe afterward
showed no grant statement at all for that role/entity). Ran REFRESH CATALOG FULL first on a later attempt — no change in behavior. There appears to be
no mxcli-only recovery path once an entity's grants have been stripped this
way; only Studio Pro's domain-model security editor (or restoring from a
backup taken before the triggering statement) recovers the original rule.

Suspected root cause

The reconciliation logic that runs on association-create / entity-create
(when extending an entity that itself has access grants) / wildcard
entity-access grant appears to recompute "all entities in the module with
grants referencing generalized/inherited attributes" and rewrite their rule
attribute-lists from a source that only knows about each entity's own
(non-inherited) attributes — dropping anything resolved through a
generalization chain, and dropping affected role-rows to zero when the entity
has no own attributes at all to fall back to.

Bug 2 — DOWNLOAD FILE produces an empty action on fresh microflow creation

Reproduction

create or modify microflow MiniCompetitie.ZZZTestDownload (
  $Document: MiniCompetitie.Document
)
folder 'Objects/NotitieBijlage'
begin
  download file $Document show in browser on error rollback;
  return;
end;
/

mxcli check --references passes. mxcli exec reports "Created microflow"
with no error. But describe microflow MiniCompetitie.ZZZTestDownload
afterward shows:

create or modify microflow MiniCompetitie.ZZZTestDownload (
  $Document: MiniCompetitie.Document
)
folder 'Objects/NotitieBijlage'
begin
  -- Empty action
  @position(520, 200)
  return;
end;
/

mxcli docker check reports [error] [CE0008] "No action defined." at Action activity 'Activity'.

Reproduced with both a brand-new entity (extends System.FileDocument
directly) and the project's own pre-existing MiniCompetitie.Document type as
the parameter — same empty-action result both times, so this is independent
of entity type. The project's own pre-existing ACT_Document_Download
microflow (originally authored in Studio Pro, not by mxcli) round-trips fine
through describe (shows the real download file $Document show in browser on error rollback; text) — so describe/read of an existing DOWNLOAD FILE action works; exec/write of a new one does not. Matches the
documented syntax in this project's own write-microflows.md skill exactly
(download file $GeneratedReport show in browser;).

Workaround used for both bugs on this project

• Create the new entity, its association, and its entity-access rules
  directly in Studio Pro (unaffected by Bug 1 — Studio Pro's own security
  editor does the generalization-aware recompute correctly).
• Create the microflow (with its Download file activity) in Studio Pro
  instead of via mxcli exec (unaffected by Bug 2).
• Continue using mxcli normally for everything else (nanoflow/microflow
  logic without a DOWNLOAD FILE activity, GRANT EXECUTE ON NANOFLOW/MICROFLOW, page/snippet edits) — confirmed safe in this session.

Diagnostic bundle

Available: mxcli-diag-20260809-175104.tar.gz (in project/, generated via
./mxcli diag --bundle -p "MIC.mpr"). The reconciliation steps are logged as
informational (msg":"execute", no error field), so the log itself doesn't
flag them as failures — the regression is only visible by diffing describe entity output before/after, as shown above.

[ako]

Both of these are already fixed — and in a release that went out the same day this was filed. You're on v0.16.0 (12 Jul); the fixes landed 2 Aug and 7 Aug and shipped in v0.17.0 (10 Aug). Upgrading should clear both.

I verified that rather than inferring it from dates: I built mxcli at the commit before each fix and ran your scenarios against Mendix 10.24.24.119349, so the only variable between runs is the binary.

Bug 1 — access rules stripped

Reproduces exactly as you describe on the pre-fix build. Granting a mix of own and inherited members:

entity	granted	stored (pre-fix)	stored (v0.17.0)
DocA — own attr + inherited	read (Ref, Name, Contents, FileID)	read (Ref)	all four
DocNoAttrs — inherited only	read (Name, Contents, FileID)	(no access)	all three

Both halves of your report: own attributes survive, inherited ones vanish, and an entity with no own attributes loses its rule entirely.

Your suspected cause was right. Reconciliation compared the bare member name against the entity's own attribute list. An inherited member's reference is qualified against the entity that declares it — an ancestor that may live in another module or in System, neither of which is present in the domain-model document being reconciled — so every inherited entry looked stale and was deleted. The fix preserves a reference it cannot validate instead of deleting it.

Fixed in bc8fe24 "security writes stripped inherited members from access rules", which was tracked as #758 / #765 — so this issue is a re-report of those against an older release.

Bug 2 — DOWNLOAD FILE creates an empty action

Also reproduces pre-fix, with your exact statement:

download file $Document show in browser on error rollback;

→ CE0008 "No action defined." The writer had no case for DownloadFileAction, so the action fell through to default: return nil and the enclosing ActionActivity was written with no action at all. That is also why microflows authored in Studio Pro round-tripped fine — the reader was never the problem, only the write path.

Fixed in 37784b5 as #850. On v0.17.0 the same script builds at 0 errors on 10.24.

Worth noting

Your pre-fix run would have shown CE0008 and CE0066 together, which is probably why these got filed as one issue — but they're unrelated causes with separate fixes.

Both bc8fe24 and 37784b5 are ancestors of the v0.17.0 tag, and the fix code is present in that tag's tree (so nothing was reverted between the commit and the release). Neither is in v0.16.0.

If either symptom survives the upgrade, that would be a genuinely new defect and worth reopening with a fresh diagnostic bundle — the reproduction scripts above are the ones I used, so a side-by-side would be quick.

---

Generated by Claude Code