Problem
src/manifest.json carries 12 occurrences of @resolve:voorzieningen_register (every voorzieningen page, lines 38-180). Today's lib bump (PR #220) brings in @conduction/nextcloud-vue 1.0.0-beta.30 with the manifest-resolve-sentinel feature (REQ-MRS-1..7) that resolves these sentinels via IAppConfig at runtime.
However: useAppManifest only runs sentinel resolution inside the backend-fetch success path. softwarecatalog has no /api/manifest controller, so on the current backend the resolution branch never fires. The 12 @resolve: strings are passed through unresolved → the backend gets a literal @resolve:voorzieningen_register string instead of the real register slug.
Required follow-up
Pick one of:
Option A — Backend manifest controller (preferred)
Add a /index.php/apps/softwarecatalog/api/manifest route that returns the bundled src/manifest.json (or a tenant-merged variant) as JSON. The lib then fetches this on bootstrap, resolves sentinels via IAppConfig, and validates. Future-compatible with manifest-dynamic-menu.
Option B — IInitialState provisioning
Provision the resolved values via OCP\AppFramework\Services\IInitialState::provideInitialState('voorzieningen_register', $slug) from Application::register(). The lib's useAppManifest resolver chain checks @nextcloud/initial-state first and substitutes synchronously — no fetch needed.
Option A scales when more keys are added; Option B is a 5-line patch.
Acceptance
useAppManifest resolves @resolve:voorzieningen_register to the real OR register slug at runtime.
- All 12 voorzieningen pages render without the literal
@resolve: string reaching the data layer.
unresolvedSentinels.value from useAppManifest returns [] for a fresh app load with the key provisioned.
Background
Surfaced during the @conduction/nextcloud-vue lib v2 rollout (PR #220 / lib PR #179 manifest-resolve-sentinel). Without this follow-up, the 12 voorzieningen pages silently misroute / 404 against the data layer.
Problem
src/manifest.jsoncarries 12 occurrences of@resolve:voorzieningen_register(every voorzieningen page, lines 38-180). Today's lib bump (PR #220) brings in@conduction/nextcloud-vue1.0.0-beta.30 with themanifest-resolve-sentinelfeature (REQ-MRS-1..7) that resolves these sentinels via IAppConfig at runtime.However:
useAppManifestonly runs sentinel resolution inside the backend-fetch success path. softwarecatalog has no/api/manifestcontroller, so on the current backend the resolution branch never fires. The 12@resolve:strings are passed through unresolved → the backend gets a literal@resolve:voorzieningen_registerstring instead of the real register slug.Required follow-up
Pick one of:
Option A — Backend manifest controller (preferred)
Add a
/index.php/apps/softwarecatalog/api/manifestroute that returns the bundledsrc/manifest.json(or a tenant-merged variant) as JSON. The lib then fetches this on bootstrap, resolves sentinels via IAppConfig, and validates. Future-compatible withmanifest-dynamic-menu.Option B — IInitialState provisioning
Provision the resolved values via
OCP\AppFramework\Services\IInitialState::provideInitialState('voorzieningen_register', $slug)fromApplication::register(). The lib'suseAppManifestresolver chain checks@nextcloud/initial-statefirst and substitutes synchronously — no fetch needed.Option A scales when more keys are added; Option B is a 5-line patch.
Acceptance
useAppManifestresolves@resolve:voorzieningen_registerto the real OR register slug at runtime.@resolve:string reaching the data layer.unresolvedSentinels.valuefromuseAppManifestreturns[]for a fresh app load with the key provisioned.Background
Surfaced during the
@conduction/nextcloud-vuelib v2 rollout (PR #220 / lib PR #179manifest-resolve-sentinel). Without this follow-up, the 12 voorzieningen pages silently misroute / 404 against the data layer.