From 8e0f18aa99e2ea745132851b507d35c757e87680 Mon Sep 17 00:00:00 2001 From: Conduction Release Bot Date: Wed, 2 Sep 2026 08:58:19 +0200 Subject: [PATCH 1/2] chore(deps): bump @conduction/nextcloud-vue to 2.30.0 for the Reports page MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The four `tests/e2e/rapportage.spec.ts` failures on development are the last of that suite's red, and they are not a test problem: the Reports page has rendered EMPTY since #1691 shipped it. Root cause, in the library rather than here. `CnReportsPage` declared two props — `page` and `translate` — and read its cards from `this.page.config.cards`. `CnPageRenderer.resolvedProps()` returns `{ ...topLevel, ...normalizedConfig, ...params }`: it spreads the page's CONFIG KEYS as top-level props and never passes a `page` object. So `page` was always `{}`, `cards` was always `[]`, and the component rendered its empty state for every consumer. The contrast makes the contract obvious — CnIndexPage declares 96 props precisely because it reads the spread. Confirmed at runtime rather than inferred: the page MOUNTS (its `cn-reports-empty` marker is present) with zero `cn-report-card` elements, which is exactly the 0 CI reported against an expected 4. nextcloud-vue#920 fixed it by declaring `cards`, `categories`, `description`, `title` and the label props, with 82 lines of new unit tests, and 2.30.0 published it. This bump is all that is needed here. Verified against a build of this branch: /apps/pipelinq/reports renders 4 `cn-report-card` elements and the "Channel analytics" card is visible. ⚠️ The rest of rapportage.spec.ts cannot be judged on this machine — every `page.goto` in it exceeds the spec's 30s budget because a page load takes ~13s against the shared dev container. In CI those same navigations complete and the failure was the card assertion, which is what this fixes. CI is the instrument for the remainder. eslint 0 errors, prettier --check on the FULL glob clean, 59 vitest tests pass. ⚠️ Two corrections to earlier reports of mine, both from measuring the wrong world. The export-pages family was already fixed by #1706 and #1711 while I was working, so development's E2E is 4 failed / 328 passed rather than the 44 I quoted from a stale branch. And my first reading said the `reports` page type was unimplemented — that was a stale local node_modules (2.27.2 against a lockfile pinning 2.29.0) plus a bundle-override that did not match `?v=` query strings. Both instruments were wrong; the CI log settled it. --- package-lock.json | 8 ++++---- package.json | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/package-lock.json b/package-lock.json index 789218d7b..623adafb3 100644 --- a/package-lock.json +++ b/package-lock.json @@ -9,7 +9,7 @@ "version": "0.1.0", "license": "EUPL-1.2", "dependencies": { - "@conduction/nextcloud-vue": "^2.29.0", + "@conduction/nextcloud-vue": "^2.30.0", "@nextcloud/axios": "~2.5.2", "@nextcloud/capabilities": "^1.2.1", "@nextcloud/dialogs": "^7.4.1", @@ -1848,9 +1848,9 @@ } }, "node_modules/@conduction/nextcloud-vue": { - "version": "2.29.0", - "resolved": "https://registry.npmjs.org/@conduction/nextcloud-vue/-/nextcloud-vue-2.29.0.tgz", - "integrity": "sha512-C7TbVrDNz43mto2sQioyF1ghAnAL/C9tUlBzcPNJMWLoLGJFxRjvYJxqrTbV1jbH9oOOQILYvWDVKPdBfBAg5Q==", + "version": "2.30.0", + "resolved": "https://registry.npmjs.org/@conduction/nextcloud-vue/-/nextcloud-vue-2.30.0.tgz", + "integrity": "sha512-Nztc3DlrEeXUwlAkT3MY1wWmyXSuh3T4kTgVdK2ejIrnBO0oFM7AimrFnRY/0YvXJWJE3uV/uM7cmte58TqnLw==", "license": "EUPL-1.2", "dependencies": { "@ckpack/vue-color": "^1.6.0", diff --git a/package.json b/package.json index 560f2690b..05fe1ea21 100644 --- a/package.json +++ b/package.json @@ -35,7 +35,7 @@ "extends @nextcloud/browserslist-config" ], "dependencies": { - "@conduction/nextcloud-vue": "^2.29.0", + "@conduction/nextcloud-vue": "^2.30.0", "@nextcloud/axios": "~2.5.2", "@nextcloud/capabilities": "^1.2.1", "@nextcloud/dialogs": "^7.4.1", From 4f8ee55a564f0854da99dce22abfd8b26269cecb Mon Sep 17 00:00:00 2001 From: Conduction Release Bot Date: Wed, 2 Sep 2026 10:37:33 +0200 Subject: [PATCH 2/2] fix(e2e): give the rapportage specs the budget the Reports page now needs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Follow-up in the same PR. The nc-vue 2.30.0 bump fixed the defect these four tests were reporting, and it changed their failure MODE rather than clearing them: before the bump Error: toHaveCount failed — cn-report-card, expected 4, received 0 after the bump Test timeout of 60000ms exceeded, with NO assertion error at all That second shape is the tell. No assertion failed, so the cards render now; the tests simply ran out of budget. Each one calls openApp() — which boots the shell and dismisses the walkthrough and support dialogs — then does a full navigation, and `type:"reports"` is mapped through defineAsyncComponent, so the first of them also pays for fetching that chunk. A bare timeout reads as "the page is broken" when it means "this test is too slow", which is exactly how the openregister route sweep misreported itself earlier today. 180s, with the reasoning written where the next reader will hit it. Also corrected two comments that survived #1684 and now say the opposite of what the code does: both told the reader that a path-form goto boots the shell at the Dashboard and the route must travel in the hash. The shell has been on createWebHistory(routerBase()) since #1684, and the code beneath those comments already uses paths. ⚠️ Verified in CI rather than locally, deliberately. Every `page.goto` in this spec exceeds even the old 30s budget on this machine — a page load against the shared dev container takes ~13s — and a full local run of the file was OOM-killed. The targeted check that mattered did pass here: /apps/pipelinq/reports renders 4 cn-report-card elements with 2.30.0 built from this branch. --- tests/e2e/rapportage.spec.ts | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/tests/e2e/rapportage.spec.ts b/tests/e2e/rapportage.spec.ts index 5d55efd31..a51205942 100644 --- a/tests/e2e/rapportage.spec.ts +++ b/tests/e2e/rapportage.spec.ts @@ -7,14 +7,32 @@ import { expect, test } from '@playwright/test' import { openApp } from './helpers/pipelinq.ts' test.describe('Rapportage (Reporting)', () => { + // ⚠️ 60s is not enough for these four. Each one runs openApp() — which boots + // the shell and dismisses the walkthrough and support dialogs — then a full + // navigation, and the Reports page is a lazy chunk + // (CnPageRenderer maps `type:"reports"` through defineAsyncComponent), so + // the first of them also pays for fetching it. + // + // They were failing on `cn-report-card` resolving to 0, which was a real + // defect: CnReportsPage read `page.config.cards` while CnPageRenderer + // spreads config keys as top-level props, so the page rendered its empty + // state for every consumer. nextcloud-vue#920 fixed that and 2.30.0 ships + // it. With the cards actually rendering, what is left is that the tests run + // out of budget — the failure carries no assertion error at all, just the + // timeout, which reads as "the page is broken" rather than "this test is + // too slow". + test.setTimeout(180_000) + test.beforeEach(async ({ page }) => { // The contactmomenten Reporting Dashboard (KPI cards) lives at the // `/rapportage/contactmomenten` page (manifest id RapportageContactmomenten // → RapportageDashboard.vue). The "Reporting" sidebar link now points at // the Lead-analytics page (`/rapportage`), so deep-link the dashboard - // route directly via the SPA hash. A path-form goto boots the shell at the - // Dashboard; a hash goto mounts the target view. Reload once so the view - // re-queries its KPI data after the same-document hash change. + // route directly by PATH. This said the opposite until #1684 — that a + // path goto boots the shell at the Dashboard and only a hash goto mounts + // the target view — which stopped being true when the shell moved to + // createWebHistory(routerBase()). The reload stays: it makes the view + // re-query its KPI data after the navigation. await page.goto('/apps/pipelinq/rapportage/contactmomenten') await expect(page.locator('body')).not.toContainText('Internal Server Error') await page.reload() @@ -138,8 +156,10 @@ test.describe('Rapportage (Reporting)', () => { }) test('channel analytics page loads', async ({ page }) => { - // Deep-link via the SPA hash; a path-form goto boots the shell at the - // Dashboard instead of the target view. + // Deep-link by PATH. This comment used to say the opposite — that a + // path-form goto boots the shell at the Dashboard and the route has to + // travel in the hash — which was true until #1684 moved the shell to + // createWebHistory(routerBase()). await page.goto('/apps/pipelinq/rapportage/channels') await page.reload() await expect(