Fix/demo user entity - #15
Closed
engalar wants to merge 5 commits into
Closed
Conversation
…oundtrip - Fix String(unlimited) output: Length==0 now displays as String(unlimited) instead of bare String in DESCRIBE ENTITY and SHOW STRUCTURE - Add CALCULATED keyword to MDL grammar for calculated (non-stored) attributes - DESCRIBE ENTITY outputs CALCULATED for CalculatedValue attributes - Writer serializes CalculatedValue as DomainModels$CalculatedValue BSON type - Add visitor test for CALCULATED attribute parsing
…tion - Add optional ENTITY clause to specify which System.User subtype to use - Auto-detect user entity when ENTITY is omitted (single subtype) - Error with helpful message when multiple subtypes exist and no ENTITY given - Pass entity to writer so DemoUserImpl stores the correct Entity value - Update manage-security skill docs with ENTITY clause examples
…ry UUID Mendix stores CalculatedValue.Microflow as a ByNameReferenceProperty (qualified name string like "Module.Microflow"), not a ByIdReferenceProperty (Binary UUID). Writing it as Binary UUID caused CE0026 "No microflow selected" on mx check.
…itor Support `CALCULATED Module.Microflow` syntax in CREATE/ALTER ENTITY attribute definitions. Includes grammar rule, AST field, visitor parsing, LSP completion, and tests.
…tips to docker workflow
engalar
referenced
this pull request
in engalar/mxcli
Mar 20, 2026
# Conflicts: # mdl/grammar/parser/MDLParser.interp # mdl/grammar/parser/mdl_parser.go # sdk/mpr/parser_domainmodel.go
ako
pushed a commit
that referenced
this pull request
Mar 22, 2026
… round-trip safety DESCRIBE WORKFLOW previously output BaseWorkflowActivity.Annotation as a SQL comment (-- text), which the MDL parser ignores and loses on round-trip. Change formatAnnotation() to emit ANNOTATION 'text'; instead — a parseable MDL statement that creates a standalone WorkflowAnnotationActivity. The content is fully preserved across round-trips. Fixes #15 (annotation loss after round-trip).
ako
added a commit
that referenced
this pull request
Jul 26, 2026
ako
pushed a commit
that referenced
this pull request
Jul 26, 2026
…veat, refresh status Two verified doc fixes from the atlas-design proposal's P2 list, plus a status refresh of the proposal itself: - create-page.md: correct the stale chart note — Line/Bubble/Heatmap/TimeSeries ARE MDL-authorable (via the line/scalecolor object-lists; see 34-chart-widget-examples.mdl), not "use Studio Pro for those". Add the Slider/RangeSlider `showTooltip: false` caveat (React findDOMNode removed in MX 11 → "Could not render widget" on drag, a runtime crash mx check misses). - PROPOSAL_atlas_design_system.md: mark the shipped work done in the "mxcli work required" table — CE0148 grant guard (PR #15), Building Blocks READ (PR #16/#17) and INSTANTIATE (PR #19), and the two P2 doc fixes above. Bump status proposed → partial (the skill shipped in PR #18); list related PRs. Refresh the proposals README index. Remaining open proposal items: parameterized fragments, chart theme colourway, CREATE BUILDING BLOCK (author), typed designproperties, lint rules, and USE BUILDING BLOCK v1.1 (inline override + data-context shortcut). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4
ako
pushed a commit
that referenced
this pull request
Jul 26, 2026
Five contained fixes surfaced by an end-to-end app build: - #5 ALTER ENTITY with comma-separated `add attribute` clauses failed to parse ("no viable alternative at input '9'"). Root cause was a missing separator in the grammar (`alterEntityAction+`), not the `default` — now `alterEntityAction (COMMA? alterEntityAction)*`. (MDLParser.g4) - #6 An `autonumber` with no seed passed `mxcli check` then failed the build CE7247 "Value cannot be empty". New MDL023 (error) in ValidateEntity flags a seedless autonumber with an actionable fix (`autonumber default 1`). - #7 An AutoX pseudo-type declared under a non-matching name (`StartedAt: autocreateddate`) is silently renamed to the fixed system member (`CreatedDate`) and can't be bound in a widget (build CE1613). New MDL022 (warning) in ValidateEntity surfaces the rename + the unbindable-member trap. - #17 `mxcli run -p <relative>` failed with MxBuild's raw "should be an absolute path" error. Resolve with filepath.Abs before handing to MxBuild. - #15/#23 A build failure in the `run --watch` loop (incl. SCSS compile errors) printed only the generic "build failed: <message>", swallowing build.Raw (the full serve /build body the cold-build path already prints). Now also print the raw detail so the real file:line surfaces in the watch output. Tests: TestValidateEntityAutonumberNeedsSeed, TestValidateEntityAutoMemberRename; bug-tests f5-alter-entity-comma.mdl (positive) and f6-autonumber-seed.fail.mdl (negative). make check-mdl green. Symptom-table rows added to fix-issue.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4
ako
pushed a commit
that referenced
this pull request
Jul 30, 2026
Mendix requires widget names to be unique per page and rejects duplicates with CE0495 "Duplicate name" — but `mxcli check --references` passed a page with, e.g., a container and a listview both named `ruTop`, and the failure only surfaced at MxBuild. Added checkDuplicateWidgetNames to the page context validator: it walks the widget tree, counts names, and reports each name used more than once (once per name, first-seen order). Runs at check time under --references, before the build. Verified end to end: a page with two `ruTop` widgets now reports the CE0495-class error; unique-named pages pass; full executor suite (no false positives on existing test pages). Unit + parsed-page tests added. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4
ako
pushed a commit
that referenced
this pull request
Aug 6, 2026
…able model (issuetracker #15) `annotation '...'` in a workflow body passed `mxcli check`, executed, and then produced a project Mendix could not LOAD: System.InvalidOperationException: Type Mendix.Modeler.Workflows.Model.Annotation does not contain a constructor with a parameter of type ...Model.Flow Not a build error — Studio Pro would not open the project and `mx check` died before validating anything, so the whole project went down rather than one document. Root cause is placement, not the storage name: mxcli writes the annotation into the workflow's activity flow, and Mendix constructs every child of that list with a Flow parent. Neither Workflows$Annotation (Description only — it attaches to a Flow) nor Workflows$FloatingAnnotation (the canvas sticky note, which has exactly the RelativeMiddlePoint/Size fields already being written) accepts one; swapping the $Type reproduces the identical error with the new name. No struct in the generated workflow model owns a FloatingAnnotation list, so the correct container is not determinable without a Studio Pro reference. Refuse the construct instead of emitting a structurally invalid unit: MDL-WF04 at check time, and a hard error in execCreateWorkflow so skipping `check` cannot corrupt a project either. The workflow skill that documented the statement now warns against it and points at an MDL comment. Verified on Mendix 11.12.1: exec refuses with an actionable message and the project still checks 0 errors, where the pre-fix binary left it unloadable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4
ako
pushed a commit
that referenced
this pull request
Aug 6, 2026
MDL spells the same concept differently per document type — binding a parameter
to a call has three spellings (microflow `(p = expr)`, page `(p: expr)`, workflow
`with (p = 'string')`), and `annotation` means "attach a note" in microflows but
was a separate, project-corrupting statement in workflows.
This violates the project's own rule in design-mdl-syntax.md ("never create a
second syntax for the same concept") and has a measurable quality cost: every
workflow defect from the two external test projects — issuetracker #15/#16/#17
and ledger #39/#41 — sits in a workflow-only construct or its bespoke write
path, i.e. code with no second consumer keeping it honest.
The proposal argues for aligning only where the syntactic difference does not
track a semantic one:
in scope — call-argument binding, activity notes/decorators, boolean
decisions (all route into write paths that already exist, so no
new BSON and no change to any stored shape)
out of scope — outcomes (first-class named model objects), boundary events,
targeting, due dates, and `{}` vs begin/end (cosmetic churn)
Guiding rule: same spelling for the same concept; keep distinct spellings where
the semantics differ. Notably a workflow body has no variables or assignment, so
making it look like imperative microflow code would mislead — which is the case
against over-unifying.
All proposed changes are additive with permanent aliases; the standalone
`annotation` statement stays refused (MDL-WF04) because its container is still
unknown. Records the rejected SQL-shaped alternative (unify on `comment`) and
four open questions, including the canonical DESCRIBE spelling.
Status: draft — open questions remain and the direction is not yet signed off.
The README index is regenerated via scripts/gen_proposals_readme.py, which also
picks up three proposals that had drifted out of it (microflow_debugger,
hub_authentication, marketplace_module_upgrade); 84 -> 88 active.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4
ako
pushed a commit
that referenced
this pull request
Aug 6, 2026
Three -tags integration round-trip tests asserted that a standalone `annotation` in a workflow body survives write → read → describe → re-execute, and went red on the MDL-WF04 guard from issuetracker #15. It does survive that loop — mxcli's own reader is tolerant — but the loop never loaded the project in Mendix, so it proved nothing about validity. Re-settled against real mxbuild 11.12.1 by stubbing the guard and writing the construct: `mx check` dies at "Loading the mpr file" with System.InvalidOperationException: Type ...Workflows.Model.Annotation does not contain a constructor with a parameter of type ...Workflows.Model.Flow so the guard is right and the tests were pinning the defect in place. TestRoundtripWorkflow_AnnotationActivity and _AnnotationBeforeActivity are replaced by TestCreateWorkflow_StandaloneAnnotationRefused, which locks in the refusal for both shapes. _Comprehensive keeps all its other coverage with the two annotations removed. This is the second time in this branch that a green test was codifying a real bug (the first was the phantom `jump to` comment), so the symptom-table row now carries that as a generalisable warning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4
ako
pushed a commit
that referenced
this pull request
Aug 6, 2026
…ck, dark topbar unreadable
Three defects reported from the RssReader test build (MXCLI-FINDINGS 15-17),
each fixed with a regression test proven to fail against the old behaviour.
15. `mxcli theme remove -p app.mpr` — the invocation the docs show — targeted
the built-in default rather than the theme actually installed. On a project
themed with ledger or console it reported every file as unchanged, exited 0,
and left the theme fully in place: a silent no-op on the documented command.
Both apply and remove now resolve the target from the mxcli:theme markers.
Remove has no fallback — an unthemed project is an error, not a no-op.
Apply keeps one, since a project with no theme is exactly when installing
the default is right; a bare apply on a themed project now refreshes that
theme instead of silently switching it to signal.
16. Switching themes left the outgoing theme's block in _mxcli-atlas-map.scss
and appended the incoming one beside it, doubling the file. Mine: the
protected-path branch in remove() returned without ever writing the
truncation it described. Harmless while the three Atlas maps are identical,
but it broke the "only one theme at a time" invariant that exists precisely
so two maps cannot fight in the cascade.
17. The topbar language selector measured 1.13:1 contrast in every dark palette
— invisible, not merely low. Two mistakes stacked. The guard was a bare
.current-language-text at (0,1,0) against Atlas's
.navbar-brand .widget-language-selector .current-language-text at (0,3,0),
so it never won. And `color: inherit` was the wrong value anyway: it
inherits body ink, which is dark, while the rail is dark in both palettes.
Now re-declared at matching specificity and resolved through the rail token.
Measured in a browser: 17.79:1 light, 19.47:1 dark.
The command-level bug in #15 needed a command-level test. cmd_theme_test.go
drives the real cobra command, because a test calling theme.Resolve directly
would keep passing while the CLI stayed broken — the same shape as the
"grep the call sites, not the helper" lesson already in fix-issue.md.
My own verification of #17 was too shallow to catch it: it read
getComputedStyle(el).color once, saw white and stopped. The probe now computes
the WCAG ratio against the first non-transparent ancestor background, which is
what turns "looks fine" into a number. Recorded in fix-issue.md.
Also documents a behaviour the report flagged but which is not a defect: apply
appends its block to the end of main.scss, after any @import the project already
had there, which matters to a project relying on import order rather than on
specificity.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JEZmExJUvn2nWTWE9mrd4i
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.