Sign-out and open-link actions: stop dropping them to Forms$NoAction

[ako]

Three client actions MDL could spell and neither engine could store. All three failed the same way — the model stayed valid, mx check reported 0 errors, and the button or menu entry simply did nothing.

CapTrackV2 FINDINGS §10 reported the first of these as "SIGN_OUT needs the legacy engine". The refusal was honest; the advice was not.

1. SIGN_OUT on a button (a54e8b40)

The default engine refused it — client action *pages.SignOutClientAction not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy. The legacy writer had no case for it either and fell through to a quiet default that returns Forms$NoAction, so the recommended escape hatch was the strictly worse path: a button that rendered, said "Sign out", and did nothing.

	before	after
modelsdk	refused	Forms$SignOutClientAction, DisabledDuringExecution: true
legacy	Forms$NoAction	identical document
describe page	actionbutton btnOut (Caption: 'Sign out')	… Action: sign_out
mx check	0 errors	0 errors

The two-key shape is pinned against a Studio Pro-authored button in ako/TestApp — a reference provably Studio Pro's rather than mxcli's, since until this change neither engine could emit the type.

2. OPEN_LINK (3bd242c4)

Same defect, plus two traps a reference settled and reasoning would not:

• The storage name is Forms$OpenLinkClientAction. The semantic type is LinkClientAction and the executor stamped Forms$LinkClientAction — a wrong $Type that never reached disk only because nothing could write the action.
• The address is not a string property but a nested Forms$StaticOrDynamicString.

Pinned against 31 Studio Pro link buttons (ako/TestApp, FeedbackModule) — exactly five keys, LinkType: "Web" in all 31:

{ "$Type": "Forms$OpenLinkClientAction",
  "Address": { "$Type": "Forms$StaticOrDynamicString",
               "AttributeRef": null, "IsDynamic": false,
               "Value": "https://www.mendix.com/" },
  "DisabledDuringExecution": true,
  "LinkType": "Web" }

6 of the 31 are dynamic — the address is read from an attribute at runtime. MDL cannot author that, so DESCRIBE flags such a button rather than printing its address as a literal, which would round-trip into a different link.

gen declares a fourth property on Forms$StaticOrDynamicString, Attribute, that none of the 31 documents carry. It is deliberately left unset — writing a key Mendix does not store is what produces a document mxbuild accepts and Studio Pro cannot open.

3. A sign-out menu item (d4d56271)

Raised separately: a navigation menu can carry a log-out item too. Fixing the button proved nothing here, because a menu item's action reaches storage through four switches that share no code with the button path:

	before
menuActionToGen (menu document, modelsdk)	NoAction default
navMenuAction (navigation profile, raw BSON)	NoAction default
resolveMenuAction (modelsdk read)	raw type name, unmapped
parseNavMenuItem (legacy read)	raw type name, unmapped

The readers are the subtler half. Both had a fallback that stored the unmapped $Type, which looks like it preserves information — ActionType became "Forms$SignOutClientAction" — while breaking the round trip, because DESCRIBE and both writers key on "SignOutAction". A round trip closes only when the reader produces the exact string the writer consumes.

MENU ITEM 'Sign out' SIGN_OUT [ICON …] now works in both a menu document and a navigation profile. SIGN_OUT names no target, so the visitor reads it separately from the PAGE/MICROFLOW switch — folding it in would consume a qualifiedName and mis-assign a trailing ICON. That case is pinned in the example.

Measured on ako/TestApp (Mendix 11.14):

before   show navigation menu Responsive  ->  Item 5
after    show navigation menu Responsive  ->  Item 5 -> sign out

and describe → exec now puts an identical Forms$SignOutClientAction back on disk, mx check 0 errors.

Notes on the controls

Two corrections worth recording, both caught rather than shipped:

• The SIGN_OUT commit's "still unimplemented" controls named LinkClientAction. Implementing OPEN_LINK invalidated them, and the gate run failed on exactly those two tests. They now name ShowHomePageClientAction — no gen type, no metamodel counterpart, no MDL statement that builds one — so the control pins a structural impossibility rather than a feature with a shelf life.
• My first attempt at the menu control was invalid: I broke a file syntactically, make build failed into /dev/null, and I was probing a stale binary that still showed the fix working. Redone properly, neutralising both readers takes Item 5 -> sign out back to Item 5.

Validation

go test ./... clean, make vet clean, make check-mdl clean, mx check 0 errors on every artefact produced (Mendix 11.13 and 11.14), check-findings 907 records OK. New examples: captrack-10-sign-out-action.mdl, captrack-10-open-link-action.mdl, captrack-10-sign-out-menu-item.mdl.

Branch restarted from main after #387 merged, so these three commits carry no already-merged history.

🤖 Generated with Claude Code

https://claude.ai/code/session_018hifgRSawfaRWXS44YKtSJ

---

Generated by Claude Code

[ako]

github-advanced-security is red here and it is not this PR's failure.

The job runs GitHub's Copilot autofix agent (COPILOT_AGENT_MODEL: sweagent-capi:gpt-5.3-codex) and exits 1 inside its own runtime, before touching anything in the diff — the log ends in the agent's own cleanup and orphan-process teardown, with no reference to any file this PR changes. The same failure, with the same signature, occurred on #387, which merged.

The actual code-scanning analysis passes: CodeQL plus all five Analyze jobs (go, actions, java-kotlin, javascript-typescript, python) are green.

There is no fix to port — the failure is in GitHub's own action, not in this repository — so I am standing down on it rather than re-running or working around it. Everything else on the head commit is green except build-and-test, still in progress; I'll follow up on that one.

---

Generated by Claude Code