Release: merge development into beta#18
Open
github-actions[bot] wants to merge 1157 commits into
Open
Conversation
This was referenced Apr 18, 2026
…e-7 no-admin-idor) The /api/manifest endpoint is authenticated-user scoped (never takes an object id; returns only the case types the current user may see, RBAC-filtered by ObjectService). Return an explicit 401 for a null user instead of an empty 200 so the endpoint carries a recognised authorization guard.
…ging (VNG Logging Verwerkingen / AVG art. 30) - catalogue lib/Settings/verwerkingsactiviteiten.json (7 zaakgericht-werken activities, AVG art. 6 rechtsgronden within OR vocabulary) + SeedVerwerkingsactiviteiten repair step (upsert-by-code as draft via OR VerwerkingsactiviteitMapper; FG-published status preserved) - x-openregister-processing (logReads + attribution + subjectIdFields) on case/role/ customerContact (monolith in-place) and contactmoment (fragment); schema versions bumped - FG view src/views/admin/VerwerkingenOverview.vue + InzageExportModal (src/modals, ADR-004) wired via registry + manifest /verwerkingen + settings menu; EN keys extracted, NL added - docs/admin/verwerkingenlogging.md: VNG API consumption via OR endpoints + known limitations (per-case-type attribution and ZGW client identity are OR-side gaps, recorded not filed) - tests: PHPUnit SeedVerwerkingsactiviteitenTest (7) + OR stubs, vitest verwerkingenApi (5), Playwright avg-verwerkingenlogging.spec.ts (gate-19), reason-bearing @e2e excludes - openspec: sync avg-verwerkingenlogging spec, archive 2026-07-06-avg-verwerkingenlogging - info.xml 0.2.36 (cache-bust; new repair step registered)
Baseline png is captured by the visual lane's first --update-snapshots run on a deployed instance (cannot be generated from the worktree).
Manifest fleet audit 2026-07-06, item 18: 15/22 manifest apps already wire check:manifest locally; this adds the missing wiring. The validator and vendored v2.11.0 schema were already in the repo — only the npm script was missing.
…24, audit item 18)' (#165) from chore/add-check-manifest-script into development
…a aiCompanion prop' (#161) from feat/ai-companion-opt-in into development
…tion/display - ADR-037 fragment lib/Settings/register.d/25-brp-kvk.json: brpPerson (Haal Centraal naming, format: bsn via OR's validator) + kvkCompany (KvK Zoeken naming); seeds are the OFFICIAL fixtures — 10 personen-mock personas (verbatim from test-data.json, all 11-proef valid; non-11-proef mock personas excluded since OR would reject them) and 10 KvK test companies fetched from api.kvk.nl/test incl pinned 69599084/68750110/69599068/55344526; every row marked as fictitious test data - case schema: additive optional initiatorType/initiatorSourceId/initiatorDisplayName (projection of semantic-case-intake's canonical requester reference; one write path via initiatorProjection()); version 1.3.0 -> 1.4.0 - UI: InitiatorPicker (Person/Company/Contact tabs; register-tier search via object store; contacts via core contactsmenu, graceful empty state) + InitiatorPickerModal (ADR-004, optional/skippable) wired into StartCaseWidget; InitiatorSection on CaseDetail overview via page slots (widget-initiator), deep-links source record to OR #/objects; EN keys extracted + NL translations - tests: PHPUnit BrpKvkRegisterSetsTest (6/214), vitest initiatorSearch (7), Playwright brp-kvk-initiator.spec.ts (6 @e2e scenarios); register-side scenarios carry reason-bearing @e2e excludes - openspec: sync brp-register/kvk-register/initiator-selection/initiator-display, archive 2026-07-06-brp-kvk-register-sets; info.xml 0.2.37
…behind config tiers - IntegrationMode config-tier resolver (integration.<name>.mode; default log, fail-closed to no external call; unknown mode -> log). Application.php factory bindings replace hardcoded Log/Mock aliases for BRP, KvK, DigiD, eHerkenning - HaalCentraalBrpAdapter (BRP Personen bevragen; mock=ghcr.io/brp-api/personen-mock offline, test=proefomgeving; X-API-KEY; BSN never logged; fail-soft) + KvkApiAdapter (KvK Zoeken; test=api.kvk.nl/test, documented public test key; fail-soft) - SimulatorDigidSamlAdapter + SimulatorEHerkenningSamlAdapter (maykinmedia pattern, no real SAML, simulator-flagged assertions) via integration.digid.mode=simulator; capped at beta - DSO config-ready seam: DsoLvAuthService::getBaseUrl() reads integration.dso.baseUrl - offline contract lane BrpKvkContractTest against REAL recorded mock/test-API responses (tests/fixtures/contracts/, aligned with brp-kvk seeds) + IntegrationTierTest - features.overlay: brp-integration/kvk-integration/digid-eherkenning -> beta with reasons, dso reason added; docs/admin/integrations.md (config tiers, key docs, access-request register) - DEVIATIONS (out of session scope, recorded honestly, no stubs): formal aansluittrajecten (BRP proefomgeving key, DSO pre-prod + PKIoverheid cert, Logius DigiD preprod real SAML, NA e-Depot) blocked-pending-grant; e-Depot MDTO/Preservica deferred to migrate-archival-to-or - openspec: sync external-integration-test-wiring spec, archive change; info.xml 0.2.38
…d (backs Pipelinq Bridge) - case schema declares implements: [ns#Case] + a COMPLETE handoffContract binding validated field-by-field against the REAL OR HandoffKindContracts (mandatory title/summary/channel/ source; optional requester/priority). DC02 correction: landed contract names provenance 'source' (mandatory) -> bound to handoffSource, not the brief's 'provenance' - new ADR-048 semantic-reference properties: requester (canonical; initiator* fields are its projection, one write path) + handoffSource (provenance back-link); ADR-011 titles - declarative caseHandoffIntake notification (x-openregister-notifications, created + notIn filter on handoffSource) — no imperative dispatch - Werkvoorraad handoff provenance badge + CaseDetail InitiatorSection handoff origin/received-at/ source-link (OR URN resolver); EN keys extracted + NL translations - README Pipelinq Bridge claim graduated from roadmap pointer to shipped - tests: PHPUnit SemanticCaseIntakeTest (5/48, binding vs real contract), Playwright semantic-case-intake.spec.ts (2 @e2e UI scenarios); backend/cross-app scenarios carry reason-bearing @e2e excludes - openspec: sync semantic-case-intake spec, archive change; case v1.5.0; info.xml 0.2.39
…atus (DC01-03 verified) OR archival-transfer-hardening is PROPOSED only (0/15) on openregister origin/development; the three OR-side deltas it must consume are absent (BagIt/durable-retry/proof-of-transfer — 0 hits each). OR's BASE archival engine is present, but the config migration (T01/T02) cannot activate without the retirement (T07/T08), which is gated on those deltas (would else double-process retention / lose functionality OR cannot replace). No procest code changed; change left ACTIVE, not archived — re-run when OR archival-transfer-hardening lands.
…header-sw-and-status-aggregation # Conflicts: # appinfo/info.xml # lib/Controller/ManifestController.php # src/main.js # src/manifest.json
… object-table/chart config (ADR-049) The manifest Dashboard page's 6 signal widgets and 2 charts no longer resolve through the app component registry via a per-page `slots` map. They are now declared inline on the page as library built-ins that CnDashboardPage resolves from the shared dashboard-widget catalog: - open/overdue/stalled cases + my tasks/task reminders/deadline alerts → built-in `object-table` widgets. Overdue/stalled/tasks/reminders/deadline carry `source.extend:["calculations"]` so the OpenRegister virtual calc columns (daysOverdue / daysSinceActivity / daysUntilDue / daysUntilDeadline) ride the fetch and render via the `conditionalPhrase` formatter. Server-side filters use the materialised booleans isFinalStatus/isTerminalStatus (=false = open) plus stored deadline/dueDate ranges; @me for the current user's tasks. - cases-by-status / cases-by-type → built-in `chart` widgets with an aggregate { groupBy, metric:count, labelResolve } over open cases + a drilldown to the Cases index. - DashboardHeaderActions custom component → declarative `config.headerActions[]` (New Case open-form + refresh); actionsComponent removed. - audit-trail registry adapter (AuditTrailWidget) replaced by the library built-in CnAuditTrailWidget (identical detail-context resolution); the app override in main.js is dropped so the built-in resolves everywhere. DUAL-BINDING PRESERVED: the 6 signal widgets are ALSO native OCA.Dashboard entries (src/*Widget.js → src/views/widgets/*Widget.vue). Only their app-registry entries are removed; the .vue components and native entry points stay UNCHANGED for the native Nextcloud Dashboard (which has no manifest). The two chart wrappers and the header-actions component were registry-only (not native) so their now- orphaned files are removed. kind:"widget" registry entries: 11 → 1 (only InitiatorSection, a case-detail overview widget outside this dissolution, remains).
…red manifest schema to v2.15.0 The ADR-049 dashboard dissolution consumes W3 (Wave-3) library features: object-table `source.extend`, chart aggregate+drilldown, and the open-form / refresh header-action types. Bump @conduction/nextcloud-vue to ^1.0.0-beta.157 and refresh the vendored gate schema (tests/schemas/app-manifest-v2.schema.json) to the authoritative v2.15.0 so `check:manifest` validates the new action types. NOTE: beta.157 is not published to npm yet (publish stuck), so this bump is install-deferred — the actual merge waits on the publish. The change was built and verified against the Wave-3 source via the ../nextcloud-vue symlink (USE_LOCAL_LIB=false webpack localLib alias); package-lock.json is intentionally left untouched and will regenerate once beta.157 lands.
…ults on case schema (T01/T02) Retention terms per zaaktype (VNG selectielijst 2020) and TMLO archival defaults move from the app-local BewaarTermijnRegel data + trigger daemon onto OpenRegister's declarative x-openregister-archival annotation and Schema.configuration.tmloDefaults, consumed by OR RetentionEvaluator and TmloService. Part of migrate-archival-to-or (ADR-022).
…to OR (T03/T04) T03: BezwaarLegalHoldListener places an OpenRegister legal hold on a case when an Awb objection is registered and releases it on the final bezwaarDecision/appealDecision — hold storage + enforcement are OR's (LegalHoldService), replacing ArchivalTriggerService's opgeschort-juridische-procedure trigger status. T04: OpenRegisterArchivalAdapter replaces the app-local MockArchivalAdapter; beschikking archival is governed by OR's declarative x-openregister-archival pipeline, with retention duration validated via OR TmloService. Part of migrate-archival-to-or (ADR-022).
MigrateArchivalToOpenRegister (idempotent, fail-closed) enables TMLO on the register, places OR legal holds for cases suspended for a running Awb procedure, and exports completed proof-of-transfer records as zaakdossier documents before the app-local schemas retire. Replaces the SeedArchiefEdepotData repair step. Admin doc rewritten for the OR-owned pipeline (e-Depot config now in OpenRegister settings). Part of migrate-archival-to-or (ADR-022).
… + UI (T07/T08/T09) Removes procest's app-local archival pipeline now owned by OpenRegister (migrate-archival-to-or, ADR-022): - services: ArchivalTriggerService, ArchivalBatchService, BagItBundlerService, ArchivalSubmissionRetryService, ArchiefEdepotSeedDataService, ProofOfTransferService, RollbackManager, MetadataBundlerService - External/Tmlo submission + TMLO-builder adapter seams (6 files) - ArchiefController + archief#* routes; ArchiefDetectReady/RetrySubmissions commands; ArchivalJob/ArchivalTriggerScanJob/ArchivalSubmissionRetryJob; SeedArchiefEdepotData repair step - 6 archief schemas (register.d/62-archief-edepot.json) + seed data - Archief dashboard/settings Vue views + menu/manifest/AdminRoot wiring - corresponding unit tests + newman collection Beschikking archival keeps a pluggable interface bound to the OR-backed adapter. Every route still resolves; no dangling references to removed classes remain.
Reduce cyclomatic complexity in the legal-hold listener and repair step (extract resolveCaseObject / placeHoldOnCase), guard setConfiguration, and drop the unused ObjectUpdatedEvent path. Mark migrate-archival-to-or tasks T01-T09 + V01-V05 done with an honest verification record.
Change implemented + verified; archief-edepot-handover main spec now declares the OR-owned model (retention declared not executed, legal-hold suspension, OR e-Depot pipeline), retiring the 22 app-local pipeline requirements.
…depot-handover The archival pipeline is OR-owned (ADR-022); its scenarios have no procest-only browser surface, so they carry a reason-bearing @e2e exclude. Main spec Purpose rewritten to the declarative/legal-hold model.
…) from wip/archive-compliance-and-tenant-fixes into development
…240) from wip/spec-anchor-archive into development
InitializeSettings called loadConfiguration(force: true). OpenRegister's app-level import fast-skip is gated on $force === false, so forcing re-parsed the register descriptor + register.d fragments and walked every register/schema on EVERY upgrade, even when nothing changed. Measured on a sibling app (shillinq): the same trap cost 711s (~70% of the whole repair); procest's descriptor cost ~39s. Safe to drop: the version passed to OR is already content-addressed (+frag.<md5>), so a content change re-imports; OpenRegister#426 additionally makes the gate content-aware; and reconcileSchemaConfig()/reconcileSchemaDeclarativeConfig() run unconditionally, so schema config keys are still provisioned when the import is a no-op. Refs: openregister#426
Vue 3 migration prep for procest (ADR-066). Ran the compile sweep from @conduction/nextcloud-vue over procest's 230 components under @vue/compat MODE 2. Result: 229/230 clean on the first pass. The one failure was a REAL Vue 3 breakage, not cosmetic: DsoCaseDetail.vue had three sub-dialogs + a transition form as loose children of <NcDialog> OUTSIDE its explicit <template #default>. Vue 2 renders those; Vue 3 IGNORES children when a default slot is explicitly declared — so on Vue 3 the Beschikking/Samenwerk/Doorstuur dialogs would silently never render. Fixed by moving them inside #default (behaviour-preserving on Vue 2). Re-sweep: 230/230 clean. Added scripts/vue3-compile-sweep.cjs + check:vue3-compile so compile-readiness is a repeatable ratchet, matching the lib. Note: compile-clean is not runtime-ready, and procest CANNOT build on Vue 3 until @conduction/nextcloud-vue ships its Vue 3 major (the hard gate, ADR-066) — this branch is preparation. procest's remaining own-code burn-down: 36 .sync, 8 .native, 3 filters (all mechanical).
…pRoot compat crash
Real per-app v9 churn (the 'churn the apps' step, live-verified on 8080):
Toolchain (webpack.config.js + package.json):
- vue 2.7 -> 3.5 + @vue/compat 3.5 (aliased vue$ -> @vue/compat)
- @nextcloud/vue 8 -> 9 (aliased @nextcloud/vue$ -> dist/index.mjs; v9 is
ESM-only, exports './components/*' with no main/module)
- vue-loader 15 -> 17 with compilerOptions.compatConfig {MODE:2, COMPILER_FILTERS}
- @vue/compiler-sfc 3.5; dropped vue-template-compiler
- vue-demi-fix (pinia 2.3 + @vueuse still import set/del from vue-demi; the fix
points vue-demi at its Vue-3 shim that defines set/del)
Source (26 files, all v9 API):
- 35 deep-import paths '@nextcloud/vue/dist/Components/X.js' -> '/components/X'
- 15 '{ t }' -> '{ translate as t }' from @nextcloud/l10n (v9 dropped the t alias)
Build result: 0 errors, 35 chunks (was 1153 -> 368 -> 20 -> 10 -> 0 across the
dep-alignment passes). Bundle confirmed Vue-3 (createApp + configureCompat).
LIVE on 8080 (bind-mounted procest, js/ hot-swapped, backend untouched):
- Vue-3 bundle BOOTS; NC shell + procest nav render.
- But CnAppRoot CRASHES at render: 'Cannot read properties of null (reading ce)'.
Sourcemap -> @vue/compat renderSlot reads currentRenderingInstance.ce when the
instance is NULL, triggered from CnAppRoot.vue:543 (<NcContent> root) slot
handling. This is the openspec task 3.1/3.2 area (Vue.extend/_Ctor renderer
workarounds + the 2700-line Options/Composition hybrid) — now with an exact repro.
- A/B PROOF it's a Vue-3 regression, not backend: the ORIGINAL Vue-2 bundle renders
the full procest Dashboard on the SAME instance with 0 console errors (the
/api/manifest 500 is pre-existing OR-drift: ObjectService::searchObjects() undefined,
and Vue-2 procest tolerates it).
Recipe is reusable for the app churn; CnAppRoot fix (task 3.2) is the blocker to a
fully-rendering app on Vue 3.
…ive-verified 8080)
The compat straddle needs FIVE fixes beyond the build (all live-verified on 8080,
prod bundle, 0 console errors; vue-router 4 nav works):
1. DUAL @vue/compat -> pin vue$ to ONE absolute file (dist/vue.esm-bundler.js).
The aliased lib worktree + procest each had their own @vue/compat, so a bare
alias gave two copies => two currentRenderingInstance states => CnAppRoot
rendered with a null instance (renderSlot/resolveComponent crash on every child).
2. DUAL vue-router -> pin vue-router$ absolute (lib worktree shipped a different
MAJOR). RouterLink got a different router than app.use(router) => NcAppNavigationItem
<router-link> v-slot {href} undefined.
3. configureCompat({ RENDER_FUNCTION: false }) GLOBALLY. Every render here is a
compiled Vue-3 render; left on, compat wraps pure-v9 @nextcloud/vue renders in
compatRender and drops scoped-slot props.
4. Entry point -> createApp + vue-router 4 (createRouter/createWebHistory, catch-all
'/:pathMatch(.*)*'), pinia via app.use, t/n/$mapFormatters via
app.config.globalProperties. App.vue Vue.observable -> reactive.
5. package.json vue-router ^3 -> ^4 (so --no-save installs stop reverting it).
Dashboard: heading, 4 stat tiles, BOTH apexcharts, 6 data tables, AI chat, tour —
all render; tour close + Cases nav click work. Remaining: Cases page needs
NcTextField :value -> :model-value (task 4.3 v-model).
…put pages The one-line fix for v9 defineModel components under @vue/compat. MODE 2 defaults COMPONENT_V_MODEL ON, rewriting v-model to the Vue-2 value/@input convention, so v9 components built with defineModel()/useModel (NcTextField -> NcInputField via useModel(props,'modelValue')) never receive modelValue -> modelValue.value undefined -> crash at value: modelValue.value.toString() on EVERY input page. Disabling it = v-model uses the Vue-3 modelValue convention. Live-verified on PROD bundle, 0 console errors: procest Cases INDEX page (search + 11 filters + data table + folder sidebar) fully renders AND the search box accepts typing; Dashboard still clean. Corrects the earlier 'must remove @vue/compat' conclusion — the migration STAYS on compat; compat removal returns to being the eventual finale, not a prerequisite. Pairs with the lib task-4.3 v-model codemod (nc-vue e784d7a6).
Same per-tag-scoped codemod as the lib (task 4.3): NcTextField/NcTextArea/NcSelect/ NcColorPicker/NcDateTimePicker :value->:model-value, @update:value/@input-> @update:model-value; NcCheckboxRadioSwitch :checked->:model-value. Ratchets: 0-collateral diff (68 files, 422 ins / 422 del, every line only a value/checked-> model-value flip) + webpack build clean.⚠️ codemod reads/writes with newline='' to PRESERVE line endings — procest .vue files are mixed CRLF/LF; a first text-mode run normalized CRLF files to LF (whole-file diffs) and was reverted. Live-verified on Vue 3 (dev + about to confirm prod), 0 console errors: Dashboard, Cases index (search/filters/table w/ 10 rows), Settings, and the CREATE CASE FORM DIALOG — 16 inputs (NcSelect comboboxes showing wired model values 'manual'/'normal', NcTextField textboxes); typed into Title field and it bound correctly. Pairs with COMPONENT_V_MODEL:false (main.js) + lib codemod (nc-vue e784d7a6).
Toward @vue/compat removal (matches the lib work): $set(o,k,v)->o[k]=v (15); .sync->v-model — checked/value.sync->v-model= (34, v9 modelValue), named->v-model:prop (2); .native removed (8). Pure-Vue-3 equivalents that also work under compat — procest still builds+renders on compat (verified). REMAINING for full compat removal: WorkflowBoard Vue.set (4) + ~9 dashboard-widget/settings entry points still use Vue.extend/new View().$mount() (need createApp), then flip webpack vue$->vue + drop vue-loader compatConfig + configureCompat.
…or procest)
- WorkflowBoard Vue.set (4) -> assignment; dropped import Vue.
- 7 dashboard-widget entries: Vue.extend(X)+new View({pinia,propsData}).$mount(el)
-> createApp(X, props)+app.use(pinia)+globalProperties.t/n+app.mount(el); dropped
Vue.use(PiniaVuePlugin)/Vue.mixin.
- settings.js + emailSettings.js: new Vue({render}).$mount -> createApp.
- webpack: vue$ -> real vue/dist/vue.runtime.esm-bundler.js (ONE absolute copy);
REMOVED vue-loader compatConfig (MODE 2/COMPILER_FILTERS).
- main.js: removed configureCompat().
Live-verified on PURE Vue 3 (NO @vue/compat runtime or compiler), 0 console errors:
Dashboard, Cases index, Create Case form (16 inputs) + typed Title. v-model works
with no COMPONENT_V_MODEL compat because the bindings are genuine Vue-3 :model-value
(task 4.3). Builds 'compiled successfully'.
- global-setup: seed cn-walkthrough-seen:<appId> into storageState so the ADR-043 product tour (a full-viewport modal dim that intercepts pointer events) never blocks sidebar navigation on a fresh context. - nav.ts navToRoute: Vue 3 dropped the per-element __vue__ instance; read the router from #content.__vue_app__.config.globalProperties.$router instead (the old __vue__ scan matched Nextcloud's OWN Vue-2 chrome, not procest's, so client-side pushes silently no-op'd under Vue 3). - nav.ts GROUP_LEAF_ALIAS: drop the stale Cases->'All cases' alias; the shipped manifest renders 'Cases' as a flat navigating leaf, so the alias matched zero links and left navTo(page,'Cases') stranded on the Dashboard.
- cases-crud + deelzaak: assert the ASSIGNED zaaknummer (from the create
response), not the supplied identifier — procest's case schema auto-numbers
(x-openregister-processing) and ignores any supplied identifier, so the seed
value never reaches the row/detail.
- complaints-bezwaar: reach the bezwaar list via a bare deep-link
(/apps/procest/bezwaren) instead of navTo('Bezwaren') — the nav-dedup pass
retired that sidebar entry (menu-layout.json removals) while keeping the page
routable, so the label matched no link and stranded on the Dashboard.
Note: case-lifecycle still red on a pre-existing OR RBAC issue (admin denied
'read' on the Case schema via the internal objectService->find() path, though
the public list API allows it) — same root as the dashboard-widget 403s;
tracked separately, not a Vue-3 concern.
…tail sidebar
- case-lifecycle openBoard: the 'Workflow board' leaf was relocated UNDER the
'Work queue' group (menu-layout.json relocations), so navTo('Workflow Board')
matches no top-level link and strands on the Dashboard — reach it by a bare
deep-link (/apps/procest/workflow-board).
- deelzaak Email-tab: the CaseDetail object sidebar (NcAppSidebar) is collapsed
by default; click the 'Open sidebar' toggle before asserting the hosted tab
strip mounts (it does not render while the aside is closed).
…r (procest#674) CaseEmailTab.vue was imported + registered in registry.js but referenced by NO manifest tab, so the email correspondence surface never rendered (the CaseDetail sidebar shipped only audit/version-history/notes/sharing). Add the `email` tab to `pages[CaseDetail].config.sidebar.tabs`. Live-verified on pure Vue 3: the tab mounts CaseEmailTab (Email Communication / Compose Email / empty state). Also park the complaints-bezwaar specs as test.describe.fixme tracked to procest#675 — the Bezwaren page filters cases by a RETIRED bezwaar caseType (b3c1a000-…-be2a, now _caseTypes_disabled), so it can't pass until the unified-case complaint model is reconciled.
…243) from perf/drop-forced-register-import into development
…stance relaxes)
Previously the workflow specs only passed with the case schema's
x-openregister-archival and x-openregister-lifecycle stripped. Make them assert
procest's ACTUAL behaviour on the production schema:
- cases-crud 'delete a case' now asserts Archiefwet immutability — a user-driven
delete of an archival case is a 403 ArchivalImmutableException and the record
persists (removal is reserved for the retention-sweep cron). Adds
tryDeleteObject() returning the response status.
- case-lifecycle 'advancing a case status' advances through the GUARDED
transition engine (executeTransition t1 → POST /api/case/{id}/transition),
not a direct case.status write the lifecycle guard rejects (422).
Green on the real schema with OpenRegister#2040 (initial-only lifecycle no longer
fail-closes every status change): 13 passed / 3 skipped / 0 failed on a live
NC-32 matched instance, archival+lifecycle intact.
… (Vue-3 lib) Point procest at the promoted Vue-3 library (2.0.1 under the vue3 dist-tag) instead of the Vue-2 ^1.0.0-beta.213, completing the migration at the dependency level. Add apexcharts ^4.7.0 explicitly: it is a transitive dependency of the lib (vue3-apexcharts → apexcharts), but declaring it guards against npm not hoisting it. Verified: procest compiles cleanly against the published dist (0 errors), and the lib's leaflet images now resolve (fixed in nextcloud-vue 2.0.1).
feat(vue3): migrate procest to Vue 3 (pure, @vue/compat removed) on @conduction/nextcloud-vue@2.0.1
rubenvdlinde
requested review from
Rem-Dam,
SudoThijn,
WilcoLouwerse,
bbrands02,
remko48,
rjzondervan and
rubenvdlinde
as code owners
July 22, 2026 23:34
Rewrote 46 Dutch `title` values across lib/Settings/procest_register.json to English (complaint/complaintDisposition/hearing, bezwaar/beroep/ bacAdviceRequest, voorstel/parafeerroute/parafeeractie/paraferingAuditEntry, plus caseType/documentType/decisionType/case/location) so manifest-driven UI labels are English-authored and translatable via l10n. Property keys, enum values, and descriptions are unchanged (verified: identical property key sets and enum values vs. merge-base). Register info.version bumped 0.13.0 -> 0.13.1. Added 39 new EN/NL l10n key pairs (l10n/en.json, l10n/nl.json, l10n/en.js, l10n/nl.js) so Dutch users still see Dutch labels; 3 titles (Category, Handler, Participants) already had matching l10n entries. appinfo/info.xml bumped 0.3.3 -> 0.3.4; CHANGELOG.md updated.
i18n(schema): author procest property titles in English + NL l10n
…-label translation 2.0.6 (vue3 tag) carries the cnTranslate display-layer translation. procest's schema property titles are English + EN/NL l10n (#679), so index/table labels resolve per user language. js/ is gitignored (CI builds); local build verified via direct webpack (procest's prebuild vue-demi-switch 2.7 sabotages npm run build — a known procest toolchain quirk, not this bump). info.xml 0.3.4→0.3.5.
chore(deps): nc-vue 2.0.6 (vue3) — activate schema-label translation
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
3 participants
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.
Automated PR to sync development changes to beta for beta release.
Merging this PR will trigger the beta release workflow.