release: merge development into beta - #3071
Closed
rubenvdlinde wants to merge 45 commits into
Closed
Conversation
… one openregister ships a flows surface (the `flows` index at /flows, in the main menu) and its tour never mentioned it, so the automation was discoverable only to someone who already knew it was there. Found by widening gate 70's flows-page predicate, which matched only `type: "flows"` — a type exactly one fleet app declares. openregister ships its surface as an ordinary `type: "index"` page, so the gate reported NOT APPLICABLE: it read as covered while covering nothing. The step is `optional` with `allowManualNext`: showing where flows are edited must not become "author an automation before you may finish the tour". It targets `flows` — the ROUTE, lowercase, as the menu entry declares it. `data-cn-route` carries `item.route`, and that is what CnWalkthrough.resolveTarget() looks up. The menu entry's ID here is `Flows` with a capital F; targeting that would look right in review and resolve to nothing at runtime, and an optional step whose target is absent is SKIPPED silently. (The neighbouring `open-tables` step has exactly that shape — it targets the menu id `Tables` while advancing on route `tables` — which is worth a separate look.) All 36 required locales are translated, not just en/nl: this repo enforces full parity, and `test:l10n` fails on any missing or empty value. Verified: gate-70 0 findings, gate-96 rc=0, l10n parity OK across 36 locales, check:l10n-js rc=0.
feat(walkthrough): show where flows live, without making anyone build one
… page) (#2978) * docs: add a local demo environment Adds `openregister-compose.yaml` and a setup page describing it. The compose brings up Postgres and Nextcloud, installs openregister (required), thematiq and integriq (optional) and openregister from release tarballs, and enables them in dependency order. Nothing is bind-mounted: Nextcloud installs an app by deleting its directory and extracting an archive over it, so pointing that at a checkout deletes the working tree — measured on a development machine on 2026-08-27, where an app-store update fired on a container restart and removed every top-level file including .git. Release tarballs rather than a clone for a second reason: a tarball is a complete app carrying vendor/ and the built js/, and an app with no vendor/ does not fail loudly — it warns once and keeps loading, so it looks installed while every service needing a dependency is absent. The openregister dependency is not declared in appinfo/info.xml — no app in the fleet declares an <app> dependency — so the compose encodes what the manifest does not. Verified: docker compose config parses and interpolates; the same generated file was booted end to end for portaliq, which produced 17 registers, 86 schemas and 13 magic tables for its own register, with the portal content API returning a real site rather than an empty shell. * docs: make the demo verification command actually pass The verification curl was unauthenticated, and a Nextcloud app page requires a login, so it printed 401 on a healthy demo while the page described it as a pass. Measured on two booted demos: 401 without credentials, 200 with them. The command now carries them and says a bare 401 is expected. * test(e2e): check a demo environment the way its docs say to Validates a booted demo against the steps its own documentation tells the reader to run. Lives outside tests/e2e/ because the root config sets testDir: './tests/e2e' and this suite needs an already-booted demo that CI does not have -- collected there it would fail, and gated with a skip it would look identical in CI to a suite that ran and found nothing. None of the assertions is a status code, because two measurements taken while writing it show why: - the Nextcloud LOGIN page is served with HTTP 200, and basic auth does not authenticate a browser navigation (only API routes), so a status-only test passes while sitting on the login screen; - an unauthenticated app URL answers 401 on a healthy demo -- the request the demo documentation used to describe as a pass. Shown to fail, not just to pass: pointed at an app that is not installed, the two reachability tests fail; portal assertions forced on against a demo with no portal fail both. Green against two independently booted demos, portaliq (6 passed) and shillinq (4 passed, 2 correctly skipped). * fix(test): keep the demo e2e suite out of jest, and format it Adding tests/demo-e2e/ broke two frontend jobs, both my doing. jest collected the Playwright spec. Its ignore list named <rootDir>/tests/e2e/ specifically -- the Playwright suite -- and the demo suite deliberately sits OUTSIDE that directory, because playwright.config.ts sets testDir: './tests/e2e' and a spec placed there is collected by CI, which has no booted demo to point at. Solving the one collector walked straight into the other: two runners with opposite exclusions, so the file has to be named in both. Verified by listing tests rather than by reading the pattern: with the ignore jest collects 0 files under tests/demo-e2e/, without it 1. The two .ts files were also not in the repo's prettier style, which `prettier --check "**/*.{js,ts,vue,css,scss}"` covers. Formatted with the repo's own config; prettier --check is now clean on both. * style: format the demo e2e files with the repo's own prettier config The first attempt formatted copies in /tmp, which resolves a different prettier config and a different .prettierignore than the repo does -- so it reported the files clean while `prettier --check` at the repo root, which is what CI runs, still rejected them. It also made the repo's own jest.config.js look unclean, which it is not. Formatted in place. `prettier --check "**/*.{js,ts,vue,css,scss}"` -- CI's exact command, run from the repository root -- is now clean across the whole tree. --------- Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
… step (#2979) * feat(flow): attribute every write in a run to the run, node and step A flow run recorded exactly one object — `FlowRun.subjectUuid`, the thing that TRIGGERED it. Everything the run went on to touch was attributable to nothing, so neither "which node last touched this case" nor "what did this run change" could be answered. `FlowRunStep` already said what happened; it did not say what it happened to. The engine now establishes an ambient frame around each hop and the audit builder stamps it onto every row. Ambient rather than a parameter because the point is to catch writes made by code that has never heard of flows — a leaf app a node calls into, a cascade, a lifecycle hook. A node cannot report what it did not know it did. The pop is in a `finally`, and that is the whole safety property: every other exit from a hop is a `return` inside a catch — a stop, a suspension, a terminally-failed step. A frame left standing attributes LATER writes to a finished run, across runs, since one worker advances several. It produces no error and no wrong-looking row. FlowEngineAttributionTest asserts the leak direction; deleting the `finally` turns 5 of its 8 tests red. Step numbers are `base + index-in-log`, not a dispatch counter: a PINNED step logs an entry without ever reaching the dispatcher, so a counter would silently desynchronise from the FlowRunStep rows it has to line up with. ADR-003 Rule 4 — the three fields join the canonical JSON, so re-pointing a row at a different run breaks verification instead of going unnoticed. That makes it a seed migration (v1 → v2) rather than a column addition. The repair step verifies the OLD chain against a FROZEN v1 canonicaliser and records that verdict before re-sealing: verifying with the current canonicaliser would include the new keys, report every pre-existing row broken whether tampered with or not, and the re-chain would bless it either way — a check that cannot tell an intact chain from a compromised one is not a check. It refuses to start if it cannot store the verdict, because a re-chain with no account of what it replaced has no remedy. Also closes a pre-existing gap found on the way: `FlowRunController::show()` was unscoped while `index()` has been scoped since shared-credentials-and-flows D7 — and a run's serialisation carries its log, which records the subject data the flow touched. Both now resolve through one predicate in the mapper rather than two copies that drift. Refs: openspec/changes/flow-object-attribution * refactor(flow): one assignee rule, reachable from outside the controller `refuseUnlessAssignee()` guarded the HTTP resume endpoint, which was the whole story while HTTP was the only way to answer a step. It is not: a leaf app whose own object completes a task resumes the run IN-PROCESS through `FlowRunService::signal()`, which never passes the controller. Left where it was, every such caller re-implements the rule. Re-implementing it is the failure mode. Two copies of one access rule do not stay identical, and a divergence here does not throw — it lets the wrong person answer somebody else's question, correctly formatted, HTTP 200. The GROUP branch is the half a hand-written copy forgets, and forgetting it refuses the step's own intended audience while still reading as "the guard works". So the rule moves to FlowRunAssignee and the controller delegates. Its 24 existing tests pass unchanged, which is the point — behaviour is identical, only its reachability changed. The old private copy is deleted rather than left beside the new one. The new tests cover the three directions that pass while broken: the group branch, the deliberately-OPEN unassigned case (webhook and child-run signals record no assignee and must keep working), and the fail-closed anonymous case. Mutating `mayAnswer()` to return true kills 8 tests across both suites. Also adds `FlowNodeResumeState::nodeId()`. A node is handed its own slot but was never told its own name, which is fine until it must hand its identity to something outside the run — a task record that has to resume this exact node. A run holds one awaiting slot per node, so "resume this run" is not an answer. * refactor(audit): flow attribution gets its own home, and the gates pass phpmd caught a real regression rather than a style nit: adding the stamp and the query took AuditTrailMapper from clean to 27 non-accessor methods against a threshold of 25. Checked against origin/development rather than assumed — the base was clean, so this was mine. Both halves now live on AuditFlowAttribution. They belong together because they are one fact read from two ends: the stamp decides what a row claims, the query trusts that claim, and keeping them apart is how the column set they agree on drifts. The mapper is back under its ceiling and no longer has to know what a flow is. Other gate findings, each fixed at the cause: - FlowEngine::run() NPath 226/200. The 26 came from the `finally` that makes the attribution pop unconditional, and that is a correctness guarantee, not a convenience: every other exit from a hop is a `return` inside a catch, so a pop on the success path leaks the frame into a LATER run advanced by the same worker. Suppressed with that reasoning written down, rather than restructuring a walk to win a number. - AuditCanonicalV1's static access is suppressed with its reason: it is deliberately frozen, and presenting it as an injectable collaborator would imply it can be swapped or updated — the one thing it must never be. - `array_values()` after `usort()` was a no-op that read as a safeguard. - `@template-extends QBMapper<AuditTrail>`, matching FlowRunMapper's convention, rather than casting the return type. - Three phpcs errors of mine (two missing @PARAM, one comment), and the @SPEC tags I had put on member variables, which that standard does not allow there. Gates now clean on every changed file: phpcs, phpmd, psalm, phpstan. 725 flow, controller and audit tests pass. * fix(ci): cover the new code, and stop tipping FlowRunService over its ceilings CI caught three things. **phpmd, twice, and both were mine.** An inline FQN in Application.php that wanted a `use`; and FlowRunService at 1047 lines / complexity 51 against thresholds of 1000 / 50. The base was at ~998 lines, so any addition trips it — my eight lines were simply the ones that did. Rather than trim a comment until the number passed, the step-history concern moved out whole. `FlowStepHistory` now owns both the NUMBERING and the RECORDING of a run's steps, and they belong together for a reason: attribution has to PREDICT a step's number before the walk, while the step row is written after it, and the two must arrive at the same value or an attributed audit row and its step row describe different steps. One class, one arithmetic — and `testRecordedSequencesContinueFromTheSameBaseAttributionUsed` asserts both ends in a single test, because checking either alone passes while they disagree. **The coverage ratchet was right too** (-2.49%). FlowStepHistory (10 tests) and AuditFlowAttribution (6) are now covered. The stamper's tests are all about the abnormal paths, because the normal one is a single line: a row written outside any run must carry NO attribution, an unresolvable context must still let the row be written, and something that is not a run context must not be trusted to be one. While writing them, `TestCase::run()` is final — the same trap the existing FlowEngineTest documents in a comment. Helper renamed. Gates: phpcs, phpmd, psalm, phpstan clean on every changed file. * test(repair): cover the one step in this change that cannot be undone The v1 → v2 migration had no tests, and it is the riskiest thing here: a re-chain recomputes every hash from current content, so afterwards an intact chain and a tampered one look identical, and the v1 hashes that could have told them apart are gone. So these test the ORDER and the REFUSALS rather than the happy path: - the verdict is stored BEFORE anything is re-sealed, and names the seed it moved from and to; - a verdict that cannot be stored means NO re-chain at all — the one refusal worth blocking an upgrade over, since a re-chain with no account of what it replaced has no remedy; - a second run is a no-op, because a v2 chain checked against the v1 form would report a false break and overwrite the real verdict with a meaningless one; - a re-seal that throws does not leave the step marked done, or the next `occ maintenance:repair` skips a half-sealed table. Worth noting how the first run failed: my IAppConfig double used an arrow function, which captures by VALUE, so the read-back always saw an empty store — and the step refused, exactly as designed. The double was wrong; the refusal it tripped was right, which is a reasonable way to learn the guard works.
… invisibility (#3005) * feat(flow): attribute every write in a run to the run, node and step A flow run recorded exactly one object — `FlowRun.subjectUuid`, the thing that TRIGGERED it. Everything the run went on to touch was attributable to nothing, so neither "which node last touched this case" nor "what did this run change" could be answered. `FlowRunStep` already said what happened; it did not say what it happened to. The engine now establishes an ambient frame around each hop and the audit builder stamps it onto every row. Ambient rather than a parameter because the point is to catch writes made by code that has never heard of flows — a leaf app a node calls into, a cascade, a lifecycle hook. A node cannot report what it did not know it did. The pop is in a `finally`, and that is the whole safety property: every other exit from a hop is a `return` inside a catch — a stop, a suspension, a terminally-failed step. A frame left standing attributes LATER writes to a finished run, across runs, since one worker advances several. It produces no error and no wrong-looking row. FlowEngineAttributionTest asserts the leak direction; deleting the `finally` turns 5 of its 8 tests red. Step numbers are `base + index-in-log`, not a dispatch counter: a PINNED step logs an entry without ever reaching the dispatcher, so a counter would silently desynchronise from the FlowRunStep rows it has to line up with. ADR-003 Rule 4 — the three fields join the canonical JSON, so re-pointing a row at a different run breaks verification instead of going unnoticed. That makes it a seed migration (v1 → v2) rather than a column addition. The repair step verifies the OLD chain against a FROZEN v1 canonicaliser and records that verdict before re-sealing: verifying with the current canonicaliser would include the new keys, report every pre-existing row broken whether tampered with or not, and the re-chain would bless it either way — a check that cannot tell an intact chain from a compromised one is not a check. It refuses to start if it cannot store the verdict, because a re-chain with no account of what it replaced has no remedy. Also closes a pre-existing gap found on the way: `FlowRunController::show()` was unscoped while `index()` has been scoped since shared-credentials-and-flows D7 — and a run's serialisation carries its log, which records the subject data the flow touched. Both now resolve through one predicate in the mapper rather than two copies that drift. Refs: openspec/changes/flow-object-attribution * refactor(flow): one assignee rule, reachable from outside the controller `refuseUnlessAssignee()` guarded the HTTP resume endpoint, which was the whole story while HTTP was the only way to answer a step. It is not: a leaf app whose own object completes a task resumes the run IN-PROCESS through `FlowRunService::signal()`, which never passes the controller. Left where it was, every such caller re-implements the rule. Re-implementing it is the failure mode. Two copies of one access rule do not stay identical, and a divergence here does not throw — it lets the wrong person answer somebody else's question, correctly formatted, HTTP 200. The GROUP branch is the half a hand-written copy forgets, and forgetting it refuses the step's own intended audience while still reading as "the guard works". So the rule moves to FlowRunAssignee and the controller delegates. Its 24 existing tests pass unchanged, which is the point — behaviour is identical, only its reachability changed. The old private copy is deleted rather than left beside the new one. The new tests cover the three directions that pass while broken: the group branch, the deliberately-OPEN unassigned case (webhook and child-run signals record no assignee and must keep working), and the fail-closed anonymous case. Mutating `mayAnswer()` to return true kills 8 tests across both suites. Also adds `FlowNodeResumeState::nodeId()`. A node is handed its own slot but was never told its own name, which is fine until it must hand its identity to something outside the run — a task record that has to resume this exact node. A run holds one awaiting slot per node, so "resume this run" is not an answer. * refactor(audit): flow attribution gets its own home, and the gates pass phpmd caught a real regression rather than a style nit: adding the stamp and the query took AuditTrailMapper from clean to 27 non-accessor methods against a threshold of 25. Checked against origin/development rather than assumed — the base was clean, so this was mine. Both halves now live on AuditFlowAttribution. They belong together because they are one fact read from two ends: the stamp decides what a row claims, the query trusts that claim, and keeping them apart is how the column set they agree on drifts. The mapper is back under its ceiling and no longer has to know what a flow is. Other gate findings, each fixed at the cause: - FlowEngine::run() NPath 226/200. The 26 came from the `finally` that makes the attribution pop unconditional, and that is a correctness guarantee, not a convenience: every other exit from a hop is a `return` inside a catch, so a pop on the success path leaks the frame into a LATER run advanced by the same worker. Suppressed with that reasoning written down, rather than restructuring a walk to win a number. - AuditCanonicalV1's static access is suppressed with its reason: it is deliberately frozen, and presenting it as an injectable collaborator would imply it can be swapped or updated — the one thing it must never be. - `array_values()` after `usort()` was a no-op that read as a safeguard. - `@template-extends QBMapper<AuditTrail>`, matching FlowRunMapper's convention, rather than casting the return type. - Three phpcs errors of mine (two missing @PARAM, one comment), and the @SPEC tags I had put on member variables, which that standard does not allow there. Gates now clean on every changed file: phpcs, phpmd, psalm, phpstan. 725 flow, controller and audit tests pass. * fix(ci): cover the new code, and stop tipping FlowRunService over its ceilings CI caught three things. **phpmd, twice, and both were mine.** An inline FQN in Application.php that wanted a `use`; and FlowRunService at 1047 lines / complexity 51 against thresholds of 1000 / 50. The base was at ~998 lines, so any addition trips it — my eight lines were simply the ones that did. Rather than trim a comment until the number passed, the step-history concern moved out whole. `FlowStepHistory` now owns both the NUMBERING and the RECORDING of a run's steps, and they belong together for a reason: attribution has to PREDICT a step's number before the walk, while the step row is written after it, and the two must arrive at the same value or an attributed audit row and its step row describe different steps. One class, one arithmetic — and `testRecordedSequencesContinueFromTheSameBaseAttributionUsed` asserts both ends in a single test, because checking either alone passes while they disagree. **The coverage ratchet was right too** (-2.49%). FlowStepHistory (10 tests) and AuditFlowAttribution (6) are now covered. The stamper's tests are all about the abnormal paths, because the normal one is a single line: a row written outside any run must carry NO attribution, an unresolvable context must still let the row be written, and something that is not a run context must not be trusted to be one. While writing them, `TestCase::run()` is final — the same trap the existing FlowEngineTest documents in a comment. Helper renamed. Gates: phpcs, phpmd, psalm, phpstan clean on every changed file. * test(repair): cover the one step in this change that cannot be undone The v1 → v2 migration had no tests, and it is the riskiest thing here: a re-chain recomputes every hash from current content, so afterwards an intact chain and a tampered one look identical, and the v1 hashes that could have told them apart are gone. So these test the ORDER and the REFUSALS rather than the happy path: - the verdict is stored BEFORE anything is re-sealed, and names the seed it moved from and to; - a verdict that cannot be stored means NO re-chain at all — the one refusal worth blocking an upgrade over, since a re-chain with no account of what it replaced has no remedy; - a second run is a no-op, because a v2 chain checked against the v1 form would report a false break and overwrite the real verdict with a meaningless one; - a re-seal that throws does not leave the step marked done, or the next `occ maintenance:repair` skips a half-sealed table. Worth noting how the first run failed: my IAppConfig double used an arrow function, which captures by VALUE, so the read-back always saw an empty store — and the step refused, exactly as designed. The double was wrong; the refusal it tripped was right, which is a reasonable way to learn the guard works. * fix(flow): a shipped flow must belong to a tenant, or it imports into invisibility Found by running the e2e for the first time, against a real instance. Every flow READ is organisation-scoped (`FlowService::findAll()` refuses outright when no tenant resolves). `SchemaFlowImportListener` never set one, so a flow declared through `x-openregister-flows` was stored with `organisation` NULL and returned by NOTHING: absent from the flows list, therefore impossible to open, therefore impossible to ADOPT — while sitting perfectly intact in the table. Measured on a clean instance: the declared `Case behandeling` flow was present in `oc_openregister_flows` with 18 nodes and invisible to `/api/flows`, next to two seeded flows that carried an organisation and listed fine. Backfilling the column made it appear immediately, with `enabled=false` and `owner=NULL` intact. Pre-existing: the importer has always done this. Nothing had noticed because this is the first shipped flow declaration in the fleet — the two example flows are seeded through a different path that sets the tenant. The resolver is container-based and returns null rather than throwing, so a declared flow still imports where OrganisationService is unavailable; it just stays unlisted, and now says so in a warning instead of silently. * fix(phpcs): document the container parameter I added phpcs caught what my local run had not: I ran the file through phpmd, psalm and phpstan but not phpcs before pushing. One missing @PARAM. * test(flow): cover the organisation stamp on an imported flow The coverage ratchet was right to fail #3005: the fix added fifteen statements and no test, so the code that decides whether a shipped flow is ever VISIBLE was the only part of the change nothing exercised. Six tests, one per branch of activeOrganisation() plus the re-import case. The last one is the one worth keeping: the stamp sits in the CREATE branch beside enabled/owner, so an upgrade running as a different tenant cannot move an already-adopted flow out from under the organisation using it. Mutation-checked: removing the setOrganisation() call turns testAnImportedFlowIsStampedWithTheActiveOrganisation red.
…sation (#3007) My own fix for the invisible-flow defect was half a fix, and its e2e proved it — in CI, where the previous run could not. A schema import runs during install and during `occ maintenance:repair`. There is no user session there, so `getActiveOrganisation()` returns null, the flow is stored with organisation NULL, and every flow read being organisation-scoped it is invisible in /api/flows all over again. The dev stack I verified on happened to HAVE an active organisation, so it went green; the CI runner does not, and dossiq's case-flow e2e failed on exactly the assertion written to catch this. `getOrganisationForNewEntity()` is the call every ordinary object save already makes, and it exists precisely to fall back to the default organisation for callers with no session. The test double now answers NULL from `getActiveOrganisation()`, so the regression cannot pass: reverting the call turns two tests red.
#2982) * feat(setup): a wizard that offers the demo data this app already ships This app ships lib/Settings/*_mock_register.json - a dataset generated from its own schemas, conformant by construction, validated by the generator's --check - and had no way for an operator to reach it. There was no setup wizard at all. welcome -> demo-data -> done. Nothing app-specific is invented: the only action is the demo-data import the descriptor already supports. A wizard that asked questions the app does not act on would be worse than none, which is why there are no configuration steps here yet. completed is TRUE and the demo-data step is optional, so setup never gates the app. skip-demo-data records its outcome just as installing does: since nextcloud-vue 2.21 an OUTSTANDING OPTIONAL step opens the wizard over every page (nextcloud-vue#806), so a step that can never be marked done is a dialog that never closes - the defect buildiq was failing 37 E2E specs on. Verified: manifest validates against schema 2.26.0, gate-100 PASS, routes.php and both PHP files parse. The template was checked on launchpad against phpcs, phpstan, psalm and phpmd - all clean. * fix(setup): declare the endpoints' auth, and translate the wizard's strings Two gate findings on the previous push. gate-5 route-auth — status() and runAction() carried no auth attribute. The docblock said 'admin-only by Nextcloud's default for an un-attributed method', which is true and is not a declaration: the gate exists because a missing attribute silently makes an endpoint unreachable, and a comment cannot be checked by middleware. Both now carry #[AuthorizedAdminSetting(Application::APP_ID)], placed DIRECTLY above the declaration - gate-5 walks upward from the method and a long docblock between attribute and declaration costs the attribute its visibility, which the gate documents as a false FAIL it had to repair. gate-102 manifest-l10n-coverage — the wizard's title and body strings had no l10n/nl.json key, so a Dutch user would read them in English. Added, and the browser catalogue rebuilt where the app ships one: nl.json alone is not enough, because the browser reads nl.js. The catalogue edit is insertions only, proven against the same change applied structurally - an earlier attempt on another app re-serialised the whole file (410 lines) before being reverted. * fix(setup): authorize against the admin settings class, and test what it guards `AuthorizedAdminSetting` takes a `class-string<IDelegatedSettings>`, not an app id. Passing `Application::APP_ID` is a plain string, so phpstan rejected it — and the apps where this shipped green (larpinq, shillinq) already pass their admin settings class. Match them: `OpenRegisterAdmin::class`, which implements `IDelegatedSettings`. gate-47 was right to fail this too. The change adds an admin-authorized endpoint pair with no test alongside it, and a mocked unit test cannot show that middleware admitting a real session. The e2e spec issues both calls from inside the logged-in admin page, and asserts the install response NAMES how much landed — the one assertion that separates a real import from one that wrote nothing, which is the defect this programme already shipped once. * test(setup): cover the demo-data controller and service The coverage ratchet was right: this change adds ~364 lines of PHP with no unit test behind them, so the coverage of the files it touches fell 46.48%. The two assertions worth naming: - a FAILED install must leave the step UNDECIDED. Recording the decision in the catch block would close the step for an operator who asked for demo data and received none — the wizard would never offer it again and nothing would have been imported. - the object count comes from the FILE, not the importer's reply, so the number reported is the number ASKED FOR. An object whose schema does not resolve is skipped rather than errored, and that discrepancy must stay visible. Both were verified by mutation: reversing each behaviour fails exactly the test that claims to guard it. --------- Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
…licks (#3011) The ADR-111 setup step is OPTIONAL, and CnAppRoot opens the non-gating wizard as a full modal mask while any optional non-info step is reported not-done — in every fresh browser context, so once per spec. Merging the setup wizard therefore turned this app's whole E2E suite red without touching a single spec: the call log reads "locator resolved to <button ...> - attempting click action" with <ol class="cn-wizard-dialog__progress"> named as the interceptor. The element was found; the click never landed. SKIPPED rather than installed, because recording the DECISION is what closes the wizard. Installing would push the app's demo dataset into every list the suite asserts on, which changes what the other specs measure. `demo-data-setup-step.spec.ts` exercises the install deliberately, in isolation. Uses the workflow's own exported credentials rather than this script's internals, and is tolerant of a non-200: an app whose wizard has no demo-data step answers 400, and that is not a seeding failure. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
) * perf(ci): pilot the changed-path filter and the reduced PR matrix * style(phpmd): drop the else in parseExpression `PHP Quality (phpmd)` was red on one violation: lib/Service/Aggregation/MetricExpressionEvaluator.php:180 ElseExpression The method parseExpression uses an else expression. Else clauses are basically not necessary and you can simplify the code by not using them. The if/else assigned $value on both arms, so a ternary says the same thing with no branch to object to. Arithmetic is unchanged — the two arms are the same expressions in the same order. php -l clean; no other else clause remains in the file. --------- Co-authored-by: Ruben van der Linde <juan.claude@conduction.nl>
…ts panel (#3014) The panel that shows which objects a run touched has existed in nc-vue since #834 and reached nobody: openregister was locked to 2.21.0, and the LOCKFILE is what decides, not the range. The range moves to ^2.22.0 as well, deliberately. Leaving the floor at ^2.21.0 would keep resolving a version WITHOUT the panel perfectly happily — the app would build, boot and render an empty sidebar, which is the failure mode this whole change exists to remove. The floor should encode what the code actually needs. Resolved with npm 11, which the repo requires for a reason: .npmrc sets min-release-age=2 and npm 10 does not implement it. 2.22.0 published today, so the cooldown would be in scope — it resolved forward anyway because min-release-age-exclude[] covers @conduction/*, which is exactly what that exclusion is for. Verified rather than assumed: npm ci -> exit 0, so lock and manifest agree node_modules/.../package.json -> 2.22.0 on disk npm run build -> exit 0 grep in js/ -> the built vendor bundle contains loadRunObjects, runObjects, AND the path flow-runs/${f}/objects, which is the endpoint #2979 added on the server That last one is the point: the two halves now name the same route. Exactly one package changed in the lockfile.
$data['schemas'] is built purely from schemasMap, which holds only the
schemas the current run processed — the schema pass does
`if ($schema === null) { continue; }` before populating it, so an existing
schema that was skipped or rejected never enters the map. The id list then
arriving at updateFromArray() is missing it, and the update REPLACES the
register's list, unlinking a schema the register still owns.
Nothing fails. The schema keeps its table and rows; the register stops
listing it. Register-scoped reads then return empty collections for data
that is present — indistinguishable from a working-but-empty install.
Measured on a live instance (#2935): 60 of dossiq's schemas were unlinked,
11 of them holding rows. `relink-schemas` recovered them with no
re-import and no data change, which is what identifies the linkage rather
than the objects as the defect.
Union rather than replace. A link this run can prove stays; a link it
merely cannot see is left alone. The failure direction becomes a stale
link, which relink-schemas already reports and repairs; the opposite
direction loses reachable data silently.
…ot-unlink-schemas fix(import): a register import must not unlink schemas it cannot see
This spec shipped to development with the ADR-111 setup wizard and has never executed once. The CI job runs `tests/e2e/ci/playwright.config.ts`, an explicit allow-list where nothing runs unless it is named — and this file was not. Measured on the merge run: `Running 65 tests`, none of them these three. It could not simply be added, because it WRITES: the install is a real import that creates this app's eight demo registers. Left behind they would land in the lists the already-admitted specs assert on — which is exactly why the CI seed settles the demo-data decision as *skipped* rather than installing it. So it now takes criterion 2's second branch: an `afterAll` deletes those registers, resolved by SLUG rather than an id captured mid-run, so an aborted run still tears its fixtures down. `_limit` and not `limit`, because a bare control param is read as a property filter by this API and returns zero rows with HTTP 200 — a teardown that would silently delete nothing. Verified by discovery rather than by assumption: the CI config lists 65 tests before this change and 68 after, with the three arms named. 65 is the same number the failing run reported, so this is the config CI actually uses. Also fixes the lint this file carried in unmeasured (its import order and a useless initialiser), and keeps the SPDX header first — `eslint --fix` hoists the type import above it, which would break REUSE compliance. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
2.22.1 carries the theme app-id fix (nextcloud-vue#840). CnAppRoot calls useScopedTheme() with no slug, so this app resolved theme tokens, the token-set catalogue and the contrast check through a hardcoded 'nldesign' app id. thematiq is renaming to 'thematiq', and every path in that composable degrades to default styling by design — so once a renamed build is installed this app would render unthemed with nothing in any log. The LOCK is what moves here. A caret range alone changes nothing, because npm ci installs what package-lock.json pins. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
The release workflow could only be triggered by a push. The shared workflow already expects a dispatch -- its skip guard is written `github.event_name != 'push' || ...` precisely so that a dispatch is "deliberately never skipped ... including of a commit this guard would refuse" -- and 18 of the 21 fleet apps already declare it. This repo was one of the three that did not. The per-branch job conditions are unchanged: `github.ref` is the branch the dispatch runs on, so dispatching on development still selects the unstable job, on beta the beta job, on main the stable one.
…s own (#3020) `scripts/l10n/` — 21 register detectors, the gated writer, the status/worklist reader, the 16-assertion selfcheck, the harvest and audit aids — plus `docs/l10n-workflow.md` and `docs/l10n-ui-translation.md`. WHY IT IS SPLIT OUT. This tooling was written inside #2634 alongside a large translation effort, and it cannot merge until that effort finishes. But the tooling is what makes the effort possible, and right now it exists on NO branch of NO app — measured 2026-08-29 across the fleet, `scripts/l10n/apply.js` is present on zero of decidiq's 458 remote heads and on no other app at all. Four agents were sent to translate with it and all four correctly stopped: the method was unsatisfiable because the instruments were not there. So the instruments land first, and the data follows. Additive only: 60 new files, no bundle is touched, no CI leg is added or changed, nothing behaves differently until someone runs a script by hand. WHAT IT MEASURES, on evidence from using it this week: register detectors found 229 values in Estonian and 62 in Romanian addressing the user in the wrong register — pre-existing, invisible to every other check selfcheck caught 276 Serbian translations written in Cyrillic into a bundle that is 96% Latin apply.js's gates refused patches whose "translations" equalled their key, and refused a plural array with three forms where the locale declares two — which renders BLANK at the counts that select the missing index None of those are findable by reading a diff. One limitation worth recording for whoever uses it next: `apply.js`'s model is "key absent -> translate". It has no path for a key that is PRESENT and holds another language's text, because gate 7 refuses to overwrite a non-identical value unless every key is named in `--allow-replace`. De-contaminating a copied bundle needs a reset mode this tool does not have. Verified on `development`'s own bundles: batch.js, selfcheck.js (15 assertions), apply.js and all 21 detectors execute; 22 locale configs load. Co-authored-by: Ruben van der Linde <juan.claude@conduction.nl>
Bumps [phpstan/phpstan](https://github.com/phpstan/phpstan-phar-composer-source) from 2.2.8 to 2.2.9. - [Commits](https://github.com/phpstan/phpstan-phar-composer-source/commits) --- updated-dependencies: - dependency-name: phpstan/phpstan dependency-version: 2.2.9 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [nextcloud/ocp](https://github.com/nextcloud-deps/ocp) from 34.0.2 to 34.0.3. - [Commits](nextcloud-deps/ocp@v34.0.2...v34.0.3) --- updated-dependencies: - dependency-name: nextcloud/ocp dependency-version: 34.0.3 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [eslint](https://github.com/eslint/eslint) from 10.8.1 to 10.9.1. - [Release notes](https://github.com/eslint/eslint/releases) - [Commits](eslint/eslint@v10.8.1...v10.9.1) --- updated-dependencies: - dependency-name: eslint dependency-version: 10.9.1 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [phpmetrics/phpmetrics](https://github.com/phpmetrics/PhpMetrics) from 2.9.1 to 2.11.0. - [Release notes](https://github.com/phpmetrics/PhpMetrics/releases) - [Changelog](https://github.com/phpmetrics/PhpMetrics/blob/master/CHANGELOG.md) - [Commits](phpmetrics/PhpMetrics@v2.9.1...v2.11.0) --- updated-dependencies: - dependency-name: phpmetrics/phpmetrics dependency-version: 2.11.0 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [twig/twig](https://github.com/twigphp/Twig) from 3.27.1 to 3.28.0. - [Release notes](https://github.com/twigphp/Twig/releases) - [Changelog](https://github.com/twigphp/Twig/blob/3.x/CHANGELOG) - [Commits](twigphp/Twig@v3.27.1...v3.28.0) --- updated-dependencies: - dependency-name: twig/twig dependency-version: 3.28.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [webonyx/graphql-php](https://github.com/webonyx/graphql-php) from 15.32.3 to 15.37.2. - [Release notes](https://github.com/webonyx/graphql-php/releases) - [Changelog](https://github.com/webonyx/graphql-php/blob/master/CHANGELOG.md) - [Commits](webonyx/graphql-php@v15.32.3...v15.37.2) --- updated-dependencies: - dependency-name: webonyx/graphql-php dependency-version: 15.37.2 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [dompurify](https://github.com/cure53/DOMPurify) from 3.4.13 to 3.4.14. - [Release notes](https://github.com/cure53/DOMPurify/releases) - [Commits](cure53/DOMPurify@3.4.13...3.4.14) --- updated-dependencies: - dependency-name: dompurify dependency-version: 3.4.14 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…1.2 (#3002) Bumps [@nextcloud/browserslist-config](https://github.com/nextcloud-libraries/browserslist-config) from 2.3.0 to 3.1.2. - [Release notes](https://github.com/nextcloud-libraries/browserslist-config/releases) - [Changelog](https://github.com/nextcloud-libraries/browserslist-config/blob/main/CHANGELOG.md) - [Commits](nextcloud-libraries/browserslist-config@v2.3.0...v3.1.2) --- updated-dependencies: - dependency-name: "@nextcloud/browserslist-config" dependency-version: 3.1.2 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [apexcharts](https://github.com/apexcharts/apexcharts.js) from 4.7.0 to 7.0.0. - [Release notes](https://github.com/apexcharts/apexcharts.js/releases) - [Commits](apexcharts/apexcharts.js@v4.7.0...v7.0.0) --- updated-dependencies: - dependency-name: apexcharts dependency-version: 7.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [web-token/jwt-library](https://github.com/web-token/jwt-library) from 3.4.10 to 4.1.9. - [Commits](web-token/jwt-library@3.4.10...4.1.9) --- updated-dependencies: - dependency-name: web-token/jwt-library dependency-version: 4.1.9 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…licks (#3039) @conduction/nextcloud-vue 2.22.x made the product walkthrough actually open. A `placement: "center"` welcome step used to be parked in `_pendingAutoTour` and never shown; the library now correctly starts it on any route. Its `cn-walkthrough__dim--full` layer is a `role="dialog" aria-modal="true"` overlay, so every spec that clicks behind it times out, and `getByRole('dialog').first()` resolves to the dim layer rather than the modal under test. The marker is per USER, not per test, so leaving it unseeded also makes the suite order-dependent: whichever spec runs first wears the tour. Seeds the same marker dossiq's global-setup already seeds, with a sentinel above any real app version so the tour composes to an empty step set. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
#3026) Every browser catalogue in this app has been telling the runtime that its language pluralises like English. scripts/build-l10n-js.js ends each generated bundle with doc.pluralForm || DEFAULT_PLURAL_FORM where DEFAULT_PLURAL_FORM is 'nplurals=2; plural=(n != 1);'. Only lb and rm declared a pluralForm, and both happened to declare that same two-form rule, so 36 of 38 catalogues silently inherited English's rule. Czech, Polish, Russian, Ukrainian, Belarusian, Slovak and Slovenian need four forms; Irish needs five; Croatian, Bosnian, Serbian, Lithuanian, Latvian and Romanian need three; Spanish, French and Italian need the CLDR "many" category. All of them declared two, so the runtime picked form 0 or 1 for counts that need another form. The rules come from Nextcloud core (core/l10n/<locale>.js), which is the authority for the runtime that evaluates them. Core ships no catalogue for bs, et, lb, lt, mt, pt, rm or sq; those carry the standard CLDR rule for the language. Declaring the right rule is only half of it: a rule is a promise about how many forms every plural array holds, so the arrays had to be filled to match. Two separate sets needed it, and the second nearly escaped: the "plurals" object in each catalogue, and a plural that lives in "translations" as an array under a _singular_::_plural_ key. Verifying only the first reported success while nine generated bundles still disagreed with their own header. Belarusian's forms were partly Russian wording in a Belarusian catalogue; they are consistent Belarusian now. The pre-existing cross-locale duplication between bs, hr and sr is a different defect and is deliberately untouched here. Verified on the generated artifacts, not the sources: every plural array in every l10n/*.js now has exactly as many forms as that file's own nplurals declares. check-l10n-parity, check-l10n, check:l10n-js and check:schema-l10n all exit 0. Co-authored-by: Ruben van der Linde <juan.claude@conduction.nl>
…2994) Bumps [elasticsearch/elasticsearch](https://github.com/elastic/elasticsearch-php) from 8.19.0 to 9.5.0. - [Release notes](https://github.com/elastic/elasticsearch-php/releases) - [Changelog](https://github.com/elastic/elasticsearch-php/blob/main/CHANGELOG.md) - [Commits](elastic/elasticsearch-php@v8.19.0...v9.5.0) --- updated-dependencies: - dependency-name: elasticsearch/elasticsearch dependency-version: 9.5.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [gridstack](https://github.com/gridstack/gridstack.js) from 12.6.0 to 13.2.0. - [Release notes](https://github.com/gridstack/gridstack.js/releases) - [Changelog](https://github.com/gridstack/gridstack.js/blob/master/doc/CHANGES.md) - [Commits](gridstack/gridstack.js@v12.6.0...v13.2.0) --- updated-dependencies: - dependency-name: gridstack dependency-version: 13.2.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Two independent faults, either of which alone stops the docs site updating. TRIGGER. This listened on a branch called `documentation`. Nobody has pushed to one since 2026-05-25, so every docs change merged to `development` passed review and published nothing. SECRETS. A reusable workflow receives no secrets by default. With none mapped, the callee's publish step finds CF_API_TOKEN empty and skips itself on its own guard, and the run finishes GREEN having changed nothing. Fixing only the trigger would have produced exactly that. The worker name is now pinned. Deriving it is the documented way to get a green run that reaches nobody: wrangler creates the derived worker and publishes there while the custom domains keep routing to the real one. Where the app was renamed, `canonical-host` turns the retired hostname from a second live copy of every page into a 301 to the same path on the current one. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
`prettier --check` failed on the walkthrough marker seeded earlier today. Purely a line-width wrap; the marker and its behaviour are unchanged. Length-dependent, which is why the identical insertion passed in shorter-named apps: 'cn-walkthrough-seen:openregister' pushes the call past the print width where a shorter app id does not. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
seed.sh creates e2e-owner and e2e-other fresh on every run, and a fresh Nextcloud account meets the firstrunwizard modal on its first page load -- the "A collaboration platform that puts you in control" panel. Its mask covers the app, so every click the specs make is swallowed. It reads as two unrelated defects. object-shares-tab fails with "a modal is still covering the page after three Escapes"; flow-controls fails with "the connection did not reach the canvas", because the drag never lands. Neither message mentions a wizard, and the spec's own Escape-based dismissal does not close this one -- it is not the app's setup wizard, which the seed already handles via skip-demo-data. Measured on a local instance against development, same build, same seeded accounts, only this variable changed: firstrunwizard enabled flow-controls FAILED firstrunwizard disabled flow-controls PASSED Disabled instance-wide rather than per-user: occ exposes no per-user "mark seen", and a test instance has no use for the wizard. The block is idempotent and tolerates the app being absent, matching the style of the user and group seeding above it. Co-authored-by: Ruben van der Linde <juan.claude@conduction.nl>
…3051) Supersedes #2987, which bumped the dependency alone and left the frontend unit suite red. Migration: - `SafeParseReturnType<T, unknown>` is gone in zod 4; the replacement is `ZodSafeParseResult<T>`. All ten entity `validate()` signatures now return `ZodSafeParseResult<unknown>`, which keeps `data` typed `unknown` exactly as the zod 3 declaration did. - `z.record()` no longer accepts a single argument: the key schema is now mandatory. `schema.ts` and `view.ts` pass `z.string()` explicitly, which is what zod 3 inferred. - `object.spec.ts` asserted zod 3's wording for the `too_small` issue. zod 4 reworded it; the assertion now pins `code: 'too_small'` as well so it is anchored on the rule rather than on the message text. No schema was loosened. A differential run of all ten validators over 4325 mutated inputs shows zero accept/reject disagreements between zod 3.25.76 and zod 4.4.3; the only deltas are zod 4's renamed issue codes (invalid_string -> invalid_format, invalid_enum_value -> invalid_value) and an extra companion too_small issue where zod 3 short-circuited after invalid_type. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
…egister (#3016) * feat(organisation): consolidate the leaf apps organisation onto OpenRegister ADR-002 makes the organisation UUID the only tenant key, but OR never owned the rest of what an organisation IS, so leaf apps grew their own copies -- OpenCatalogi a publisher record (oin/tooi/rsin/pki/image), Stackiq a vendor record. ADR-022 section 3 makes those copies the defect; this gives OR the columns that make reuse possible. Repairs two silent live defects along the way: - `groups` has no column on any instance. Version1Date20250102000000 adds it guarded by hasTable(openregister_organisations), but that class sorts five months BEFORE the one that creates the table, so the guard is false and the step succeeds having done nothing. TenantLifecycleService ::provision() calls setGroups(), so provisioning could never succeed. - storage_quota / bandwidth_quota / request_quota have no column anywhere; the only migration creating them targets openregister_applications. They were copy-pasted from Db/Application. QBMapper::update() builds SET from getUpdatedFields(), so a marked field with no column is an SQL error at write time, not a no-op -- every PUT /api/organisations/{uuid} touching those fields was a guaranteed 500. * fix(organisation): make the consolidation PR's own checks pass Three failures, all this change's own. phpmd: changeSchema() was a 20-branch, NPath-524288 method built from 17 identically shaped `if (hasColumn)` blocks. The list is pure description, so it is now data — split by the three facets the class docblock already reasons in (tenancy repairs, identity, relationship) — and the method is a guard plus two loops. Every column name, type and option is unchanged; verified by diffing the extracted name and Types:: constant per column. phpunit: OrganisationTest asserted the field-type keys under COLUMN names (`storage_quota`), which is what this branch deliberately changed. The entity is right and the test was pinning a latent bug: Entity::__call() resolves a setter to lcfirst(substr($method, 3)) and Entity::fromRow() maps a column to its property BEFORE looking the type up, so a snake_case key matches nothing and the declared cast never runs. For the ?DateTime properties that was a live 500 — fromRow() assigned the raw string onto a typed property and raised "Cannot assign string to property $provisionedAt of type ?DateTime". The test is updated to the intended behaviour and gains testFromRowCastsDatetimeColumnsToDateTimeObjects, which A/B-fails with exactly that TypeError against the old registration. hydra gate-46: the @SPEC tags pointed at openspec/changes/consolidate-organisation-on-or/, which was never written. Adds the change (proposal, delta spec, tasks) rather than dropping the tags, per the gate's "fix the TARGET" guidance. Also corrects two docblock claims that referenced things that do not exist: Organisation::$mergedInto said the tenant-resolution path calls resolveMergeTarget() (it has no caller), and the migration pointed {@see} at a Repair\ConsolidateLeafOrganisations class that was never written. Both gaps are now recorded as open tasks 3.3 and 5.1.
* feat(flow): pin every run to the flow version it started on
A run resumed against the LIVE definition: the advancer re-resolved the flow
by id on every pass, so a case parked for a week on a human step came back to
whatever the graph had become. ADR-098 Decision 6 calls that the programme's
highest-risk defect and forbids shipping human task nodes without versioning
first — dossiq already ships two.
Storage is two layers. openregister_flow_defs is a content store addressed by
the sha256 of the canonical graph, so an unedited flow stores ONE row no
matter how many runs it backs, and immutability is structural rather than
promised. openregister_flow_versions NAMES those graphs: (flow, version)
unique, with a draft/published/deprecated lifecycle and at most one published
version per flow.
A run records flow_version at queue time, and the graph it walks is a function
of that number alone. FlowRunService::execute() enforces that for all four
call sites that hand it a document — three of them resolved it LIVE, so a
pinned run reached the engine and then walked the current graph anyway. When a
pinned version cannot be resolved the run FAILS naming the version; it is
never re-pointed at a newer one, because its marking, its taken decisions and
its log all belong to the version it started on.
Authorization is deliberately NOT pinned. owner and organisation keep coming
from the live document, so a revoked grant stops the next hop of a run queued
while it was still valid. Pin the shape of the work, never the right to do it.
The trigger set is derived from the published version inside FlowTriggerIndex,
so a draft's trigger nodes match nothing by construction rather than by a
filter on the read path somebody has to remember. The dead-end preflight now
judges the graph being pinned rather than the editable head, so a broken draft
cannot refuse runs of a sound published version and a repaired draft cannot
mask a dead end in the version actually going live.
BackfillFlowVersions publishes version 1 of every existing flow and pins every
still-movable run to it. Without that step the upgrade is a fleet outage:
queue() refuses any flow with no published version and the advancer fails any
run with no pin, and nothing that exists today has either. It is idempotent by
query — already-versioned flows are skipped, runs are pinned only where
flow_version IS NULL — and terminal runs keep their null, because telling a
run that finished last year that it executed version 1 would invent history.
Tests are mutation-checked: reverting the pin, falling back to live on a
missing version, substituting a newer version, and sorting list members during
canonicalisation each turn the naming test red.
* feat(flow): the version lifecycle API — publish, draft, deprecate, read
Five routes and a refusal shape. `PUT /api/flows/{id}` now answers 409 when the
definition changes against a published head, and only then: renaming a flow,
editing its description or switching it off are not changes to the process, and
refusing those would make a published flow unmanageable rather than merely
uneditable. FlowService compares a signature of the four graph keys taken
BEFORE applyEditableFields() mutates the entity, because reading it afterwards
compares the incoming graph with itself and the refusal never fires.
409, not 400: the request is well-formed and it is the flow's STATE that
refuses it — a state the author can change, after which the identical request
succeeds. The body carries `reason`, `lifecycleStatus` and `flowId` as fields
rather than prose, because "this version is published, create a draft" and
"this flow has no published version, publish one" want opposite buttons from
the editor, and picking between them by parsing an English sentence is how a UI
offers the wrong one.
The version number in the route is \d+, not [^/]+. Without that,
/versions/publish would match the version route with the literal string
"publish" and return 404 for a route that exists.
A shipped flow now publishes version 1 on import. An app declaring a flow in
x-openregister-flows ships a finished process, and since versioning a flow with
no published version backs no run — so leaving it a draft would mean adopting
it still ran nothing, with no error to explain why. Published but still
disabled and unowned: publishing answers which graph would run, adoption
answers whether it may run at all.
The controller takes ONE new collaborator rather than four; the version reads
moved onto FlowVersionService and it resolves the publishing user from the
session itself, so an install-time import with no session and a request with
one both work without either caller remembering.
* test(e2e): the flow version lifecycle, end to end
Nine specs over the API a browser actually talks to. The headline one is the
defect: queue a run against version 1, publish a rewritten version 2, and
assert the queued run still names version 1. Asserting only that "the run
completed" would pass against an engine that silently adopted version 2, which
is exactly the failure being removed.
`createFlow()` now publishes by default, because a DRAFT BACKS NO RUN — every
fixture that runs a flow needs a published version, and getting that wrong
surfaces as a 409 on the run rather than as anything about the graph.
The refusal specs assert the stored graph is UNTOUCHED as well as the status
code: a refusal that still wrote would be the worst of both, an error the
author acts on over a change that happened anyway. And renaming a published
flow is asserted to SUCCEED, because metadata is not the definition and
refusing it would make a live flow unmanageable.
One spec exists only to catch a routing trap: `/versions/publish` must 404
rather than match the single-version route with the literal string "publish"
as a version number.
* docs(openspec): record what flow-definition-versioning actually shipped
3.3 was solved by a different mechanism than the task assumed: the pinned graph
is laid over the live document per run inside execute(), so the resolver memo
never needed a version dimension and two runs on different versions in one
worker batch still each get their own graph.
3.5 is explicitly NOT done. The hook exists — an unpinned run passes its own
document straight through — but nothing queues a draft test run or marks one in
the run list, so a draft cannot yet be tried from the editor.
* fix(flow): let an author still test-run a draft
Versioning made `queue()` refuse any flow with no published version, and the
editor's "test this flow" goes through `queue()` — so I had made every NEW flow
untestable until it was published. That is backwards: publishing is what you do
AFTER testing, and it broke a capability that worked before this change.
`trigger: 'test'` is now the one dispatch exempt from "a draft backs no run",
which is what the spec always said. Such a run is left UNPINNED, and
`overlayOnto()` passes an unpinned run's document through untouched — so a test
run is pinned in the sense that matters: it walks the exact graph it was started
with and nothing can substitute another one mid-run. It is distinguishable in
the run list by `trigger: test` and a null `flowVersion`.
The exemption is narrow in both directions, and both are tested: every other
trigger of an unpublished flow is still refused with `no-published-version`,
and a test run of a PUBLISHED flow still pins to it — this is about drafts, not
about test runs skipping versioning. Widening the condition to all triggers
turns the naming test red.
* test(flow): the trigger index must follow the published version
The published-only rule had no unit test at all — nothing constructs
FlowTriggerIndex by hand, so no existing suite reached it, and the rule could
have regressed to deriving from the head without a single cell going red.
Both directions of that failure are silent. Deriving from the head while a
draft is open subscribes the draft's trigger nodes — a half-authored flow
firing on real object writes — AND unsubscribes the published version's, so the
process that IS live quietly stops running. Neither raises anything.
Four tests: the head's draft trigger must not be subscribed while the published
one must be, a flow with no published version subscribes to nothing, `enabled`
still comes from the LIVE flow (switching a flow off must take effect at once,
whatever is published), and the rows stay keyed on the flow's own uuid rather
than the detached carrier's. Reverting the resolver to the head turns two of
them red.
* refactor(flow): keep the versioning work inside the quality thresholds
Running phpmd on the CHANGED FILES reported clean while running it over `lib`
— which is what CI does — reported three violations. A per-file invocation is
not the gate; the directory one is.
- `changeSchema()` had grown to 189 lines. Split into definitionStore(),
versionStore() and pinColumns(). The three calls are assigned to separate
variables before being OR'd, deliberately: written `$changed || $this->x()`
the short-circuit would SKIP later steps as soon as one reported a change —
creating the definition store and silently never adding the columns that
point at it.
- `FlowVersionService` had a coupling of 13. It no longer takes IUserSession;
the controller names the publisher from the FlowAccess it already holds,
which avoids a second session dependency there for one string.
- `FlowRunService` passed 1000 lines again. `buildRun()` and `newUuid()` — both
added by this change — move to `FlowRunRow`, which performs no checks at all:
every guard runs in `queue()` before it is reached, so a check there would be
a second copy of a rule that already exists, and the two would drift.
phpcs, phpmd (both passes), psalm and phpstan now all exit 0 in their CI form.
730 flow unit tests green.
* test(e2e): the version badge and the Publish button
Two UI specs, gated behind OR_UI_E2E like the rest of the page describe. They
need @conduction/nextcloud-vue 2.23.0, which carries the sidebar half.
The draft spec asserts the BADGE after clicking Publish, not the click. A
button that posts and silently fails looks exactly like one that worked; the
badge only reads 'Published' once the store has re-read the flow from the
server. It then re-reads the flow over the API too, so the test cannot pass on
an optimistic client-side state the server never accepted.
The published spec asserts Publish is ABSENT as well as Create draft being
present — offering to publish something already published is how an author
ends up meeting a 409 that the UI should have prevented.
* test(e2e): match the data-testid convention for the lifecycle hooks
* test(newman): publish each flow the engine collection then runs
All 14 cases in this collection create a flow and immediately run it, and both
setup sub-flows are invoked by SubFlowNode. Under versioning every one of those
would now answer 409 no-published-version, because a flow is created as a DRAFT
and a draft backs no run.
The collection is not in api-test-coverage's default set, so CI would not have
caught it — it would simply have rotted until somebody ran it by hand and found
sixteen red cases with no obvious cause.
Publishing in the create step is what an author actually does in the editor, so
each case still describes the same journey. The sub-flows need it for their own
reason: SubFlowNode QUEUES the child, and a queue resolves the CHILD's published
version at call time, so an unpublished child fails the step rather than the
parent's graph.
Written as a surgical text patch rather than by re-serialising the JSON: a
round-trip through json.dumps reformatted all 7,700 lines and buried the actual
change. Request count is unchanged at 65 and the file still carries zero \u
escapes, matching the 96 lines of raw UTF-8 it already had.
* style(e2e): run prettier over the flow-engine spec
quality / Frontend Check (format) runs prettier over **/*.{js,ts,vue,css,scss},
and tests/e2e/flow-engine.spec.ts was the only file it rejected on this branch.
* fix(e2e): the flow-engine fixtures were in the pre-inversion shape
Two specs in this suite have been failing on development, and not for any
reason to do with versioning: their fixtures hang the step type off the EDGE.
The engine inverted that — "an edge is sequence and a NODE is the action" — and
now refuses such a flow outright:
Flow edge "first" carries "type", which the engine no longer reads ...
This flow is in the pre-inversion shape and has not been migrated.
So the run failed before any node executed, and every assertion after it never
ran. This suite exists to be the POSITIVE CONTROL against an engine that
reports success while executing nothing — and it was not controlling anything.
Both fixtures now put the action on the node and leave the edge as pure
sequence, verified against a live instance before being written down:
A two set-fields nodes, last marked exit:true
-> status completed, 2 steps, types [openregister.set-fields, ...]
B a BARE `set-fields` node type, terminated by openregister.end
-> 1 step, failed, "No app provides the flow node type \"set-fields\""
`exit: true` rather than a terminal end node on A, deliberately: an end node
stops the run and lands it in `stopped`, while that test asserts the
`completed` path.
Found by running this suite against development BEFORE merging versioning, to
establish which reds were already there. Two were.
---------
Co-authored-by: Ruben van der Linde <juan.claude@conduction.nl>
…3057) The curl sweep that drove the docs rollout asserts status codes and redirect targets. Necessary, not sufficient: a Docusaurus site answers 200 for a 404 route, a blank shell and a build-error page alike -- the exact shape this repository's own demo suite exists to catch. So this renders every one of the 21 sites and asserts the page carries its own heading and its own compose filename, and follows all 13 retired hostnames in a real browser to assert where they LAND rather than trusting the 301. The deep-link case is checked through the request context, where the Location header can be compared exactly, query string included. 47 tests, all passing against production. One caution for whoever runs this next: a first attempt reported 5 failures and a second reported 13, and none of them were real. The machine had 21 orphaned Chrome processes and was answering ERR_INSUFFICIENT_RESOURCES before the request left the box, while curl returned a correct 301 for the same URL throughout. Check the local machine before believing a browser test about someone else's infrastructure. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
) `flow-controls.spec.ts` went red with "Run now was refused — the server answered 500", and the server log says: This flow has no published version, so it cannot back a run. Versioning (#3047) made every dispatch require a published version, which is the point of it — but it carves out one case, in FlowPublishedGraph: An unpinned run is the interactive draft test run — the one documented exception to "a draft cannot back a run". `FlowRunVersionPin::requirePublishedAndSound()` implements that exemption for `trigger === 'test'`. The editor's Run button posts to `flow#run`, which went through `FlowService::run()` and queued as MANUAL — so the exception could not be reached from the only screen that needs it. `FlowService::run()` now takes the trigger, and the editor endpoint names itself as the interactive run. Second defect, same path: `FlowLifecycleRefused` was uncaught in `FlowController::run()`, so a refusal that carries `reason` and `lifecycleStatus` — exactly so the editor can offer the right button — escaped as an HTML 500 and threw all of that away. It now returns the 409 the exception was designed to produce, via the existing `refusal()` helper the other three call sites already use. Verified: both new tests ERROR with the source change reverted. Flow suite 1218 tests green; phpcs and phpstan clean on the changed files. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
…ngeSchema (#3063) Every fresh install ends up with a table that cannot be written to. The symptom, 238 times in one dossiq CI run: ERROR: null value in column "naam" of relation "oc_openregister_verwerkingsactiviteiten" violates not-null constraint STATEMENT: INSERT INTO ... ("code", "name", "purpose", "legal_basis", ...) Version1Date20260818230000 renames the 13 Dutch columns by adding the English ones in changeSchema() and copying + dropping the old ones in postSchemaChange(). postSchemaChange NEVER RUNS ON A FIRST-TIME INSTALL: Installer::installApp() calls $ms->migrate('latest', $previousVersion === ''), whose second argument is $schemaOnly, and MigrationService::migrateSchemaOnly() invokes changeSchema() on every step and nothing else -- then marks every step EXECUTED, so it never retries. naam, doelbinding and rechtsgrond are notnull => true from Version1Date20260430160000, while every current write names only the English columns. So the table keeps 33 columns and rejects every insert, forever. Drops the leftovers from changeSchema(), the one hook both paths run. A dropColumn() through the schema object is honoured there because the diff is applied by migrateToSchema() -- unlike in postSchemaChange, whose schema is never applied, an asymmetry 20260818230000 already documents. Data-safe in both paths: on an upgrade the copy+drop has already happened and this finds nothing; on a schema-only install there is by definition no prior data, since $schemaOnly is only true when the app had no version. Verified on a live install: 13 Dutch columns -> 0, the 13 English columns untouched, and the exact failing INSERT now returns INSERT 0 1.
…ue 2.24.0 (#3056) * fix(flow): version EVERY flow, not the first hundred `FlowMapper::findAllFlows()` defaults to `limit: 100`. Both flow repair steps called it bare, so each silently processed one page and reported success. Measured on a dev instance immediately after upgrading: **219 flows, 100 versioned, 119 left with no published version** — and a flow with no published version backs no run. The repair step that exists to stop versioning being a fleet outage was itself producing one, on 54% of the flows, while printing a cheerful summary. The trigger back-fill had the identical bug and it is worse there, because the symptom is pure silence: a flow past the first page is simply never subscribed and never fires. Both now page to exhaustion. Paged rather than passed a large limit on purpose: a limit big enough to look obviously safe today truncates silently once an instance grows past it, and the failure would look exactly the same. Verified by re-running `occ maintenance:repair` against the half-versioned instance the bug produced: Flow versions: published version 1 for 119 flow(s), 100 already versioned flows 219 · flow_versions 219 · still unversioned 0 which also demonstrates the idempotency guard doing its job on the 100 that were already done, and the content store deduplicating 219 flows down to 24 distinct graphs. * chore(deps): take @conduction/nextcloud-vue 2.24.0 for the flow version lifecycle 2.24.0 carries the editor half of flow definition versioning: the read-only canvas on a published version, the version badge, and Publish / Create draft / Deprecate. Without it an author has no way to publish a flow — and since a draft backs no run, a newly created flow could not be run from the interface at all. Exactly one package changed: 2.22.1 -> 2.24.0. Resolved with npm 11 deliberately: local npm 10.8.2 does not implement min-release-age, so a lockfile written by it does not reflect the cooldown policy this repo's .npmrc configures. * fix(flow): a refusal must reach the client as 409, not 500 Running a flow with no published version escaped `FlowController::run()` as an unhandled exception and reached the caller as an HTML error page. A 500 reads as "the server is broken" for what is actually "publish this flow first" — it sends the author to exactly the wrong place. `FlowRunController::test()` leaked the same way, and additionally leaked `FlowDeadEnd`, so pressing Run in the editor on a half-wired graph produced a stack trace instead of the sentence the engine had carefully written. **Every unit test passed through both defects**, because they all assert on the EXCEPTION rather than on the response a caller receives. The e2e caught them. There is now a controller test for the 409 path, and removing the handler turns it red. `FlowService::run()` also gained the `@throws FlowLifecycleRefused` it was missing — without it PHPStan called the new catch dead, having no way to know what the method actually throws. Test fixtures: several single-node flows had no outgoing edge, which is a dead end, so publishing them was correctly refused. They now mark `exit: true` — stopping there is deliberate in those fixtures, which is exactly what the flag is for. * fix(e2e): publish before running — a draft backs no run The spec that turned development red asserts the author journey build → save → run, and asserts 201 on the run. Versioning changed that journey: a flow is CREATED as a draft, and `flow-definition-versioning` says plainly that "a run SHALL be queued against the flow's published version. A draft or deprecated version SHALL NOT back a newly queued run." So from #3047 onward the journey is build → save → PUBLISH → run, and this spec was asserting a contract the app deliberately no longer offers. It surfaced as a 500 because `FlowLifecycleRefused` escaped `FlowController::run()` unhandled. That half is a real defect and is fixed in 7ed9ab7 — the refusal is now a 409 naming `no-published-version`. But 409 is not 201 either, so the status-code fix alone leaves this spec red, and nothing on the PR would have said so, because PRs into development SKIP the E2E job. The opposite shortcut was considered and rejected. Letting `POST /api/flows/{id}/run` quietly fall back to an unpinned draft test run makes this spec pass, and `tests/e2e/flow-engine.spec.ts` then asserts the opposite in two places: that this exact endpoint refuses a draft, and that it refuses a DEPRECATED flow, both with `no-published-version`. Two checks over one endpoint that cannot both hold. Silently running a retired process is a worse defect than the one being fixed, so the endpoint keeps its rule and the spec gains the step. Nothing is weakened: every existing assertion stands, including 201 on the run. Publishing goes through the editor's own control, so the new lifecycle UI is on the CI path too, and it asserts the BADGE rather than the click — a button that posts and silently fails looks exactly like one that worked. Also annotates the header's 1-node/0-node table as HISTORY. It records the dead-end 500 that step 2 fixed, and has already been read once as if it explained this later, unrelated 500 — sending the reader hunting for something the run path does per NODE. Node count had nothing to do with it. * test(flow): cover the paging fix and the refusals it now returns Nine unit tests over the code this PR changed, each with a positive control verified by reverting the fix and watching the named test go red. `BackfillFlowPagingTest` is the one that matters. The mapper double is a REAL pager — it honours `limit` and `offset` exactly as `FlowMapper::findAllFlows()` does — because a double that ignored them would let the unpaged implementation pass too, and the test would be asserting the double rather than the step. Over a 1,003-flow instance the unpaged version versions 100 and reports success, which is the defect as measured. Both steps are asserted on their OUTCOME (the version rows inserted; the flows handed to `rebuild()`), not on the call count: "it paged" is not the claim, "no flow was left unrunnable" is. A second test pins the mechanism, so a later implementation that reached the same total with one enormous page — which truncates silently once an instance outgrows it — is still visible. Also covered: the per-flow catch, because an aborted walk turns one broken flow into a broken instance; the trigger back-fill's refusal to throw, because an exception there aborts the upgrade carrying the fix; and idempotency, because `occ maintenance:repair` is expected to be re-runnable. `FlowRunControllerTest` gains the two refusals `test()` now catches. Both were escaping as HTML 500s, and every existing unit test passed through that, because they all assert on the EXCEPTION rather than on the response a caller receives — the same blind spot the 409 commit describes for `FlowController::run()`. These assert the response. Controls: reverting `everyFlow()` to a bare `findAllFlows()` fails 4 of the 7 paging tests at "100 of 1003"; removing the per-flow catch errors the resilience test; removing either catch in `test()` errors both controller tests with the exception escaping. * fix(flow): realign with development's test-run route, and drop the duplicate catch development independently fixed the 500-on-refusal and went further: the manual run endpoint now queues as TRIGGER_TEST, so pressing Run in the editor works on a flow that has never been published. That is the right call — requiring publication before you may TRY a flow makes publishing a precondition of testing, which is backwards. Git merged my catch alongside theirs and produced a duplicate; PHPStan caught it as an already-caught catch. Theirs stays, because it also carries the trigger change. Two e2e specs asserted the OLD behaviour and merged cleanly while becoming untrue — a textual merge over a semantic conflict: - 'a draft cannot be run' now asserts the opposite, that a draft CAN be run from the editor and that the run is UNPINNED, which is the property that actually matters: it walked the draft it was started with. - 'a deprecated flow backs no new run' asserted a 409 that no longer happens on that endpoint. It now asserts the invariant that does still hold — deprecating leaves the flow with NO published version, which is what stops a TRIGGERED run — rather than asserting something the product does not do. --------- Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
…rejection (#3068) `handleValidationException()` formats `$exception->getErrors()` unconditionally. That getter is typed `?ValidationError` and IS null for every ValidationException thrown with a message alone — `enforceReadOnlyOnUpdate()` is one such path and says so in a comment where it throws. `ErrorFormatter::format(null)` is a TypeError, so the 400 this method exists to return became a 500 whose body carried none of the reason. Observed on dossiq's development, in the server log for every case edit: Opis\JsonSchema\Errors\ErrorFormatter::format(): Argument #1 ($error) must be of type Opis\JsonSchema\Errors\ValidationError, null given, called in .../ValidateObject.php on line 2233 The caller saw "server error" where the server had a precise sentence for it — "Cannot modify readOnly property: X" — which is exactly what an operator, and an e2e failure, needs to see. Guarded: format only a real ValidationError, and let the message carry the rest. Mutation-verified — removing the guard reproduces that TypeError verbatim in the new test, which otherwise asserts a 400 whose message still names the violated property. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
Resolves the only two conflicts, both of which are the version string that beta and development each bumped independently: appinfo/info.xml 1.1.6-beta.20260820205738 -> 1.1.8-unstable.20260829125656 openapi.json (same) Development's value is taken because it is the higher of the two. The release workflow then folds in what the App Store already serves (1.1.8 stable) when it computes the beta number, so the published version outranks the store rather than silently landing below it. Merged with a real merge commit, not a squash: beta is 21 commits ahead of the merge base, and squashing a promotion rewrites those as a revert of the target's own history.
Contributor
Author
|
Superseded by the branch-protection-compliant route: promotions to beta must come from |
Contributor
Quality Report — ConductionNL/openregister @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-specs | ✅ | ||||
| test-l10n | ✅ | ||||
| format | ✅ | ||||
| check-schema-l10n | ✅ | ||||
| check-l10n-js | ✅ | ||||
| composer | ✅ | ✅ 172/172 | |||
| npm | ✅ | ✅ 547/547 | |||
| app:check-code | ⏭️ | ||||
| info.xml | ✅ | ||||
| REUSE | ❌ | ||||
| PHPUnit | ✅ | ||||
| Newman | ✅ | ||||
| Playwright | ✅ | ||||
| Hydra gates | ✅ |
Quality workflow — 2026-08-29 20:32 UTC
Download the full PDF report from the workflow artifacts.
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.
Promotes development to beta so a version newer than the store's
1.1.8can be published. Replaces #2976, which isdirtyand cannot merge.Conflicts: 2, both the version string — beta and development each bumped it independently:
appinfo/info.xml1.1.6-beta.202608202057381.1.8-unstable.20260829125656openapi.jsonDevelopment's is the higher of the two. The release workflow then folds in what the App Store already serves (
1.1.8stable) when computing the beta number, so the result outranks the store instead of landing below it — the failure mode that started this whole thread.Merge, do not squash. beta is 21 commits ahead of the merge base; squashing a promotion rewrites those as a revert of the target's own history.
Verified: 255 files changed and 0 deletions, which matches
compare/beta...developmentexactly; both resolved files parse (xml.etree,json.load) and carry the intended version; no conflict markers remain.