Repository navigation
Sync ako/mxcli: activities edited in place, finds in nested fragments, user tasks below Mendix 11.2, hidden Timeline enums, error-handler rows - #1677
Merged
Conversation
…fig hide rules A pluggable widget's enumeration that its editorConfig hides must hold its default, or mx check reports CE0463. mxcli refused that for the one Timeline rule it read (`groupEvents: false`), but `widget describe timeline` showed "2 of 6 editor hide-rules recognized". So `customVisualization: true, groupByDayOptions: 'dayMonth'` and `groupByKey: 'day', groupByMonthOptions: 'monthYear'` passed check and exec and failed mx check (#1762, mendixlabs#1668). Two shapes were unread: - terser folds the statements before a `switch` into its head, `switch(A ? hide : hide, B || hide, e.groupByKey)`, so the THEN branch's guard is bounded by the `switch(` paren, which parseGuard took for a conditional group. A `switch(`/`if(` head directly in a function body is now statement-level; a call's paren still is not. - a hide in a `case`/`default` arm had no reading. switchArmCondition now states the arm's values as eq/in, or ne/notin over the other cases for a default arm, following fall-through and grouped labels. Anything it cannot state exactly (a guarded hide inside the arm, a non-literal label, an arm whose exit is unclear, a switch under an `if`) yields no rule, as before. Timeline is 6 of 6 (3.1.1, 3.2.2, 3.2.3), so each hidden enumeration now gets MDL-WIDGET10's existing verdict: an error for a non-default value, which exec's preflight refuses before writing; a warning at the default; written at the default when left out. Across every installed package dumped before and after, only Timeline and HeatMap gained rules (HeatMap folds an `if(` head the same way). MDL-WIDGET10 names an in/notin set instead of "matches". WidgetDefGeneratorVersion goes to 20 so cached definitions regenerate. The custom-mode warning on title/description/timeIndication came from the hand-written fallback table, whose comment claimed only TextTemplates can cause CE0463. That comment, and the writer's, are corrected. File Uploader's ternary-wrapped hidePropertiesIn (#258 item 1) was already lifted by the else-if chain support of mendixlabs#1583. It is pinned by a test against File Uploader 2.5.0. Measured on Mendix 11.13.0 with Timeline 3.2.2, one widget per variant: the six hidden variants were CE0463 and the three controls 0 errors before the fix; check now refuses exactly those six. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
…default Once the Timeline's hide rules are read (#1762), one of its two format enumerations is always hidden: by customVisualization, or by the groupByKey switch. The generic pluggable-widget describe printed every stored primitive, so each Timeline came back with a hidden property at its default and drew an MDL-WIDGET10 warning on mxcli's own output (11 warnings on six measured pages). The same happened before for any widget hiding an enumeration by a rule the extractor already read, such as a Timeline with `groupEvents: false`. Such a property carries nothing: exec writes a hidden property the script leaves out at that same default. extractExplicitProperties now drops a top-level property that the widget's own rules hide in the stored configuration while it equals the stored schema's default. The rules are the registry's, the ones `check` evaluates, so the two agree about what is hidden. A hidden property holding a non-default value is still printed, because that widget fails mx check with CE0463, and printing it lets `check` say so. describe -> check -> exec on three Timeline configurations: no MDL-WIDGET10, and the stored page is byte-identical afterwards. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
… place Re-running `create or modify microflow|nanoflow` with only a filter's expression changed replaced the activity: the activity, its action and its operation all got new $IDs, while a decision whose condition changed the same way kept its own, and exec reported both as `spliced: 1 replaced`. Studio Pro compares and merges by $ID, so it showed the edit as one activity removed and another added (#1761, mendixlabs#1667). A splice Replace by one activity of the same activity and action $Type now edits the stored activity: the replacement is written into the stored slot, at the stored size, and its elements are paired structurally with the stored ones (same $Type at the same key; list entries by the member, parameter or language they name; unnamed entries by position only for equal $Type sequences). The stored $IDs go on at Bytes, rewriting every reference in the same pass, so the executor can still name the fragment's activity until then. This applies at top level, in a loop body and to an activity with a custom error handler, for create or modify and for alter ... replace. A run of adjacent statements each changed in its own place, pairwise of one plain kind, is diffed one-for-one instead of as a replace-and-drop of the whole run, so each is edited in place. The report tells the two outcomes apart: `edited in place` for a node that kept its $ID (an activity of the same kind, a decision's condition, a return's value, a node's notes) and `replaced with new element IDs` for one that did not. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
The alter syntax help, the alter-microflow reference page and the microflow and nanoflow skills now say that an activity replaced by one of the same kind is the stored activity edited, keeping its $ID and those of its action and the parts that pair up, and how exec reports it (`edited in place` against `replaced with new element IDs`) (#1761). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
…w Mendix 10.21 Symptom (#1163): on Mendix 9.x and 10.0-10.20 a workflow with a `parallel split` made the project unloadable. exec reported "Created workflow", then mx check died with "TypeCacheUnknownTypeException: The type cache does not contain a type with qualified name Workflows$EndOfParallelSplitPathActivity". Cause: the builder and the ALTER mutator end every path with that marker, because from 10.21 the engine runs a path only up to it. The type itself was introduced in 10.21.0 (mendixmodelsdk 4.117.0). The generated version data holds property floors only, so nothing compared a written $Type with the project's version. Older shape, measured: Studio Pro 9.4.0 (the Marketplace's "Example project workflow extension" 2.0.0) stores a split whose ParallelSplitOutcome is {$ID,$Type,Flow} and whose paths hold their activities and nothing more. Lowering produces exactly that key set. Fix: canon.LowerToProjectShape drops the marker from every Workflows$Flow below 10.21, for every writer at once (create, create or modify, and a path alter workflow inserts). Measured on fresh apps, the bug-test exec'd then mx check: - 9.24.30.51827: before TypeCacheUnknownTypeException, after 0 errors; mx convert 9.24.30 changes no key; describe -> exec "Unchanged". - 10.12.19.81612: before TypeCacheUnknownTypeException, after 0 errors; mx convert 10.12.19 changes no key. - 10.24.24 and 11.13.0: 4 markers, 0 errors, key sets identical to the unfixed build. Control: stubbing the lowering fails TestNormalize_ParallelSplitPathsBelowMendix10_21 on 9.24 and 10.20 with the marker still in each path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
…Mode their floors Symptom (#1163): on Mendix 9.0-9.19 every pluggable widget's schema lost the Type of its return types and kept an AssignableTo that version does not have (49 return types across the embedded templates). A return type reaching the floor there was refused with "this Mendix 9.18.0 project cannot store CustomWidgets$WidgetReturnType.Type (Mendix 9.20.0+)". Cause: the vendored generator gave a property the row of the next property in the SDK's versionInfo and left that one out, as it did AggregateFunction. mendixmodelsdk 4.117.0 has WidgetReturnType `type: {}`, `assignableTo: {introduced 9.20.0}`, and pages.GroupBox `caption: {}`, `headerMode: {introduced 8.10.0}`. widgetTypeForVersion drops undeclared keys from the widget schema by the same data, so it dropped the right key. Evidence: Studio Pro stores {EntityProperty, IsList, Type} on 208 of 208 return types in a 9.1.1 app and 326 of 326 in a 9.4.0 app (Marketplace samples), and adds AssignableTo on 57 of 57 in a 9.24.3 one. The group box row changes nothing mxcli writes: the caption is stored as CaptionTemplate, which the table never keyed, and 8.10 is below every supported version. Workflows$CallMicroflowTask.boundaryEvents was already 10.14.0, as in the SDK, and stays. Measured on 10.12.19 with that floor removed: mxcli writes BoundaryEvents [2] on every call and mx convert strips it, so the floor's drop-empty is right. A test now pins it; removing the row fails it. Fix: correct both rows by hand and regenerate modelsdk/version. Only those two rows change in the copy. Measured: the bug-test on fresh 10.24.24 and 11.13.0 apps checks at 0 errors before and after, with identical key sets. 9.24.30 stores Studio Pro 9.24.3's return type keys both times (its mx check stops on a separate pre-existing NullReferenceException in WidgetValue.IsDefault). Control: the new tests fail on the old rows (49 wrong key sets at 9.18; the Type refusal). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
Fix Timeline hidden enumerations, in-place activity edits, and the parallel split below Mendix 10.21
The pattern `.mxcli/unit-types.idx` has a slash in the middle, so git anchors it to the repository root: the index mxcli writes next to a fixture a test opens in place (testdata/testapp-views/.mxcli/) showed up as untracked, though the comment above the line says it is meant to be ignored there. `**/` matches it at any depth: `git check-ignore` did not match the nested copy before, and matches it and the root one after. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
Without @position a custom error handler is a row 130px under its activity, and the main line carries on one spacing after the activity however long the row is. When the next activity had a handler too, its row started at its own x, inside the first: the first handler's end event and the second handler's first activity were both stored at 680;330 (#1768, mendixlabs#1672). The lane model from #1154 already made an activity with a handler wait for a reserved lane; the handler row was the occupant that never reserved it. addErrorHandlerFlow now reserves the lane to the row's measured right edge plus the activity gap, and measureStatements does the same and counts the row in its extent, so a branch or loop holding handler rows is measured as built. Without the measurer half, 12 of the new shapes put a merge on an activity. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
The start event goes one spacing left of the first statement when that statement carries @position. The pre-scan took the first statement that had one, wherever it was, and every unplaced statement before it follows the start: `declare $A …; @position(840, 200) declare $B …` stored both at 840;200 (#1768 case 2, mendixlabs#1672). Only the first statement moves the start now, as alter's patch (patchDiff.startEvent, declared[0]) and the syntax help already assumed. The help and the language reference now say that statements before a placed one keep their derived places. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
The overlap rule built its canvas from activities, loops, decisions and merges only, so an activity lying on an error handler's end event was never reported — the shape #1768 reported, two handler rows on top of each other, passed MPR008 until an activity happened to land on an activity. Start, end, error, break and continue events and inheritance splits are on the canvas too, each judged with its stored size; an event that stores none is taken as Studio Pro's 20x20 rather than as an activity. On the 292 Studio Pro-authored flows of PedApp and ako/TestApp the wider set adds no finding. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
Symptom (#1769, mendixlabs#1673, Mendix 11.12.4): `alter microflow … { replace loop … with begin … end; }` wrote `$X = find $List by Code = …` in the loop's body as Microflows$FindByExpression with the bare text `Code = …` when the fragment did not know $List's entity. check --references and exec reported nothing; mx check failed CE0117. The same find inserted on the main line was refused (#891). Cause: confirmed. #891's qualifiedMembersOnly is set on the fragment's builder, but the loop body, the while body and the error-handler body are each built by a fresh flowBuilder whose fields the site listed by hand, and none listed the flag. So every member-bearing statement nested in a fragment (find, filter, sort, aggregate, change, at any depth) was written bare. `replace body of loop` went through the same loop builder and had the same hole. Fix: one construction helper, flowBuilder.nestedBuilder, for all three sites; it inherits the flag with the rest of the shared state. The error handler still sets its return type and label table itself, as before. TestNestedBuilder_InheritsSharedState classifies every flowBuilder field as inherited or the body's own and checks the helper against it by reflection, so the next field cannot be left out silently. With this alone the reported alter is refused, with nothing written, because the fragment does not type a list retrieved over an association; the next commit types it. Control: with the flag left out of nestedBuilder, the nested-guard test reports every statement in every nested shape written instead of refused, the PedApp test reports exec writing the replaced loop and replace body, and the structural test names the missing field. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
Symptom (#1769, mendixlabs#1673): after the previous commit, the reported alter — a replaced loop finding by member in $Lines, retrieved over an association before the loop — is refused with "cannot qualify member \"Code\"" where `create microflow` writes Microflows$Find on MyModule.OrderLine.Code. Cause: alterFlowContext.storedVariables, the variables a fragment starts from, typed parameters, declares, creates, database retrieves and calls, and left a retrieve over an association "Unknown": which end it yields depends on the end it starts from. A stored loop's iterator was not typed either, so a member of it in a fragment inserted in the loop body was refused too. Fix: storedVariables types both from the variable they start from, to a fixed point, so the order the stored flow lists them in does not matter. The retrieve's type is flowBuilder.associationRetrieveType: lookupAssociation, entityIsSubtypeOf and associationRetrieveYieldsList, the answer the full build and check --references already take. The parent is the FROM end and the child the TO end, so from the TO end (Order) a reference yields the list of FROM objects (OrderLine), from the FROM end the one TO object; a reference set is a list either way, an owner-Both reference one object either way. A self-reference, an unknown association, or a name two loops or retrieves give different origins stays untyped, and its member is refused rather than guessed. Controls: with storedVariables reverted, the association-typing tests and the PedApp by-attribute tests fail with the refusal; with the ambiguity guard off, the shared iterator name and the retrieve from it are typed. Measured on Mendix 11.13.0 (scratch app, real mx): before, FindByExpression "Code = $Lookup/Code" and CE0117; the previous commit alone, refused with exit 1 and the stored flow byte-identical; with both, Microflows$Find on MyModule.OrderLine.Code, mx check 0 errors, describe → exec "Unchanged microflow". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
…11.2 Symptom (#1771): on Mendix 10.12 to 11.1 every user task mxcli wrote failed mx check with CE1859 "XPath constraint is required". That included tasks targeted by a microflow, and multi-user tasks. exec and mxcli check were clean. `mx convert -p` 10.24.24 then stored an empty XPathBasedUserSource in place of each targeting, so the targeting was silently lost. Cause: userTaskToGen writes UserTargeting, which Mendix introduced in 11.2.0 (mendixmodelsdk: UserTaskActivity.userSource deleted and userTargeting introduced in 11.2.0). It is declared on the abstract UserTaskActivity, and the property floor looks up the concrete type only, so the key went into every version. 10.24 ignores it and fills the required UserSource with its default. Older shape, measured: two Studio Pro-authored Marketplace samples, Employee Onboarding (9.1.1, XPath) and Multilevel Dynamic Workflow (9.24.3, microflow), converted 9.24.30 -> 10.24.24 -> 11.13.0. The targeting keeps its $ID and value byte for byte. Only its $Type and the key holding it change: XPathBasedUserSource <-> XPathUserTargeting, MicroflowBasedUserSource <-> MicroflowUserTargeting, and EmptyUserSource -> NoUserTargeting (this fix's 10.24 output converted up). Fix: canon.LowerToProjectShape renames the targeting to the user source below 11.2, in its place, for every writer. Group targeting is 11.2 and has no older form, so it is refused, naming the task. Measured on fresh apps, exec of the bug-test then mx check: - 10.24.24.119653: before CE1859 x3, after 0 errors. mx convert 10.24.24 changes no key and no value. describe -> exec "Unchanged workflow". - 11.13.0: 0 errors, and the key sets match the unfixed build. Control: stubbing the lowering fails TestNormalize_UserTaskTargetingBelowMendix11_2 24 times, with UserTargeting still on the task. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
Symptom (#1771): on Mendix 9.x a workflow with a user task made the project unloadable. exec reported "Created workflow", then mx check 9.24.30 died with "TypeCacheUnknownTypeException: The type cache does not contain a type with qualified name Workflows$SingleUserTaskActivity". Cause: mxcli writes Workflows$SingleUserTaskActivity and MultiUserTaskActivity. Mendix introduced both types in 10.12.0 and deleted Workflows$UserTask there (mendixmodelsdk 4.117.0). The generated version data holds property floors only, so nothing compared a written $Type with the project's version. Older shape, measured: Studio Pro 9.24.3 (the Marketplace's Multilevel Dynamic Workflow) stores {$ID, $Type, Annotation, AutoAssignSingleTargetUser, Caption, DueDate, Name, OnCreatedEvent, Outcomes, TaskDescription, TaskName, TaskPage, UserSource, UserTaskCompletion}. The completion (9.22) says which kind of task it is. A single-user task has a bare SingleInputCompletion. A multi-user task has a MultiInputCompletion holding its CompletionCriteria, its TargetUserInput and, from 10.2, AwaitAllUsers. Fix: canon.LowerToProjectShape rewrites the task as that UserTask below 10.12. The multi-user settings move into the completion, and the outcomes stay on the task, so the rule's outcome pointers still resolve. The completion's $ID is derived from the task's. What the older type cannot hold is refused, naming the task: a multi-user task below 9.22, majority and threshold below 10.0, a microflow rule below 10.3, `await all users` below 10.2, and a boundary event on a user task below 10.14. An empty BoundaryEvents list is dropped below 10.14; it is declared on the abstract UserTaskActivity, which the floor never saw. describe reads a 9.x multi-user task's completion, and the create-or-modify guard now sees its rule and participants too, so a rewrite no longer resets them silently. Measured on fresh apps, exec of the bug-test then mx check: - 9.24.30.51827: before TypeCacheUnknownTypeException, after 0 errors. mx convert 9.24.30 changes no key and no value. describe -> exec "Unchanged workflow". After mx convert 10.24.24, the user tasks are identical in keys and values to mxcli's direct 10.24 output. - 10.24.24 and 11.13.0: 0 errors. Control: stubbing lowerUserTaskType fails the three normalize tests on 9.24 with the 10.12 types in place. The read test and the guard test failed before their fixes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
Symptom (#1771): on Mendix 9.x to 11.1, `alter workflow M.W { set (Targeting: xpath [...]) on Task; }`, and the deprecated `set activity 'Task' targeting ...` form, reported "Altered workflow" and changed nothing. describe still showed the old targeting, and mx check stayed clean. Cause: SetActivityProperty set UserTargeting with bsonnav.DSet, which only replaces a key that already exists. Below 11.2 a stored user task holds its targeting as UserSource, so no key matched and nothing changed. Fix: setUserTargeting replaces UserTargeting or UserSource in place, or adds the targeting when the task has neither. It writes the current shape; canon.LowerToProjectShape stores it as the project's version does, as it does for every other writer. Measured on fresh apps, the bug-test exec'd then described and checked: - 9.24.30.51827 and 10.24.24.119653: with the committed mutator (a scratch build), "Altered workflow" x2 and `[Name = 'admin']` kept. With the fix, `[Name = 'reviewer']` and ACT_GetReviewers, 0 errors, and the version's key set (Workflows$UserTask with UserSource on 9.24). - 11.13.0: the new targeting both ways, 0 errors. Control: TestWorkflowMutator_SetTargetingReplacesAStoredUserSource and ...AddsAMissingTargeting failed before the fix. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
Symptom (#1771): `mxcli check -p` passed scripts with user-task features the project's version cannot store, and exec wrote them. Group targeting on 10.24 failed mx check with CE1859, and mx convert emptied it. Once the user task is lowered to its pre-10.12 shape, a multi-user task's later rules were refused only at write time, part-way through a script. Cause: no version gate looked inside a workflow user task. The generated version data floors properties, never types, and these are type-level introductions (mendixmodelsdk 4.117.0 StructureVersionInfo): the multi-user task's UserTaskCompletion 9.22, Majority and ThresholdCompletionCriteria 10.0, MultiInputCompletion.awaitAllUsers 10.2, MicroflowCompletionCriteria 10.3, and XPath/MicroflowGroupTargeting 11.2. Fix: userTaskGates walks the activities a create workflow states, and the ones alter workflow inserts. It adds an MDL-VERSION01 gate for each clause the version lacks. A consensus or veto multi-user task with user targeting passes from 9.22. The floors are new sdk/versions entries: workflows.multi_user_task, multi_user_task_majority_threshold, multi_user_task_await_all, multi_user_task_microflow_rule and group_targeting. Measured with the bug-test (check -p, then exec, then mx check): - 9.24.30.51827: WF_Majority, WF_Await, WF_Microflow and WF_Groups reported; exec "Refusing to execute: 4 error(s) above. Nothing was written." - 10.24.24.119653: WF_Groups only. - 11.13.0: none; exec writes all five, mx check 0 errors. Control: TestCheckVersionGates_UserTaskFeatures failed for every case before the gates. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
24-workflow-examples.mdl, the only doctype script with user tasks, is gated 11.0+ as a whole. CI's 10.24 leg therefore never wrote a user task. That hid #1771: every user task mxcli wrote on 10.12 to 11.1 failed mx check with CE1859. 24b-workflow-mendix10-examples.mdl (10.0+) now writes user tasks by XPath, by a microflow and with no targeting. It also writes multi-user tasks with the consensus, veto, majority and threshold rules and participants, which 10.0 has. Then it inserts a task with alter workflow and changes a task's targeting. Measured with TestMxCheck_DoctypeScripts/24b: - 10.24.24.119653: PASS, mx check 0 errors. Control: with the targeting lowering stubbed, it FAILS with CE1859 on all 8 user tasks. - 11.13.0: PASS (24, 24b and 25 all pass, on both versions). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
The 10.0-10.11 claims rested on mendixmodelsdk's version data and on the 9.24 measurements. They are now measured on 10.11.0.37074, the last version before the 10.12 type boundary (mxbuild downloaded for this, then deleted): - With the user-task lowering stubbed, a user task makes the project unloadable (TypeCacheUnknownTypeException ... Workflows$SingleUserTaskActivity). - With the fix, the 1771 bug-tests give 0 errors. The multi-user tasks' MultiInputCompletion holds AwaitAllUsers (10.2+). mx convert 10.11 changes nothing, and describe -> exec reports "Unchanged workflow". Majority, await all users and a microflow rule check clean, and alter workflow's targeting edit lands. 1771-user-task-features-by-version.mdl's group-targeted task used a microflow returning System.WorkflowGroup, an entity Mendix introduced in 11.2. Written on 10.11 it was CE1613, unrelated to the user task. The task now targets groups by XPath. Re-measured: check -p reports the expected gates on 9.24.30, 10.11.0 and 10.24.24. On 11.13.0 exec writes all five workflows with 0 errors. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82sUVQEB3K5W5vh85wM
Mendix 11.16.0 is published on the CDN (mxbuild-11.16.0.tar.gz, 27 Oct 2026) but was not exercised by CI. Added as a seventh entry rather than replacing an older one: 11.13.0 is the measured floor for timer-started workflow event sub-processes, and 11.15.0 is the first version with the MessageDefinition2 document shape (#987), so each keeps a job running at its own gate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011oK82teqHJLFTo5pLuHMt1
Fix finds in nested fragment bodies, user tasks below Mendix 11.2, and overlapping error-handler rows
ci: add Mendix 11.16.0 to the nightly test matrix
engalar
pushed a commit
to engalar/mxcli
that referenced
this pull request
Oct 30, 2026
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
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.
Syncs
ako/mxcli:maininto upstream: 18 commits from fork PRs ako#1770 and ako#1772.Fixes #1667, #1668, #1672 and #1673.
Microflows: activities edited in place (#1667)
create or modifykeeps an activity's$IDs when it is replaced by one of the same kind, meaning the activity's and the action's$Typeboth match.create or modifyandalter … replace, at top level, in a loop body, and on an activity with an error handler. Several neighbouring edited statements are diffed one for one.execnow saysedited in placeorreplaced with new element IDs.mx checkerror set is identical to an unedited copy.Microflows: finds and layout (#1673, #1672)
findinside a loop written byalter microflowbuilds (alter microflow … replace loop: afind … by Member = valueinside the new loop is stored as a find by an invalid expression (CE0117), because the loop body's builder does not inheritqualifiedMembersOnly#1673). It was stored as aFindByExpression, which gave CE0117.nestedBuilderconstructor.flowBuilderfield to be classified, so a new field can't silently drop out.layout flowscalls the flow already laid out #1672). Two consecutive activities with handlers had their rows drawn on top of each other. A handler's row now reserves the lane under its activity. MPR008 compares events and type splits too, so it catches that shape.@positionno longer moves the statements before it.Pluggable widgets: hidden enumerations (#1668)
switcharms and statement-head guards, so Timeline reads 6 of 6 hide rules instead of 2.WidgetDefGeneratorVersionis bumped to 20, so cached definitions regenerate.Workflows below Mendix 11.2
User tasks are now written in the shape the project's version stores. The shapes were taken from Marketplace samples converted 9.24 → 10.24 → 11.13.
Single/MultiUserTaskActivity+UserTargeting(unchanged)UserSourceWorkflows$UserTask+UserSource+UserTaskCompletionawait all usersbelow 10.2;alter workflow … set (Targeting: …)used to print "Altered" and change nothing below 11.2. It now writes the targeting.Metamodel floors
WidgetReturnType.assignableToandGroupBox.headerModeget their correct version floors. On 9.0–9.19, every widget return type used to loseType.Also
.gitignoreignores the unit-type index undertestdatafixtures too.make ci-localpasses. Every fix has a failing-first test and a control, a bug-test script, a finding and a CHANGELOG entry