b2f77b45e5
Fixes AUT-8 (TRU-12).
## Problem
The Selvvask (XLVask) usage pagination in `XLVaskUsagePagination.vue`
calls `/modules/xlvask/services/usage/orders`, an endpoint that ships in
the frontend ahead of the backend implementation. While the backend is
still being built, the route responds with HTTP 404 — which
`paginatedList` was treating identically to any other error and
surfacing through the generic `ShowErrorField` popper. Operators hitting
the Selvvask tab during that window saw an alarming failure message
instead of an honest "not implemented yet" notice.
## Fix
- **`src/components/pagination/paginatedList.vue`**: introduce a
reactive `lastError` ref on the composable that captures `{ status,
endpoint, message }` from the most recent failed `paginatedGetRequest`
call. The ref is reset on success, left untouched for cancelled
requests, and exposed both on the composable's return and on the global
instance so other surfaces can opt into status-aware error handling.
Non-cancelled failures continue to populate the existing global error
store via `parseError`.
-
**`src/components/displays/pagination/models/DepartmentPos/XLVaskUsagePagination.vue`**:
derive an `apiEndpointNotImplemented` computed that is `true` only when
`lastError.status === 404` *and* the failing endpoint matches this
component's own `/modules/xlvask/services/usage/orders`. A watcher on
that computed clears the matching `paginatedGetRequest` entry from the
global error store, and the template renders a friendly, info-styled
Bulma notice between `PaginationDisplay` and `ShowErrorField`. Non-404
errors (500, network failures, etc.) still fall through to the generic
popper unchanged.
## i18n
New `errors.api_endpoint_not_implemented` key under
`invoicing_period.xlvask_review`, added to all five source locales (en,
da, de, no, sv) plus the global shared template alias, then regenerated
into the i18n v2 runtime files via `npm run i18n:v2:compile`. Each
locale now reads as a real translation rather than a raw key in the UI.
## Tests
- `tests/unit/superuser-invoices-view.spec.js`: two new contract
assertions verify that `XLVaskUsagePagination.vue` references
`apiEndpointNotImplemented`, `lastError`, the `404` literal, the new
i18n key path, the `xlvask-api-not-implemented` test id, and the
`removeError("paginatedGetRequest")` call; the locale assertion confirms
the key resolves in every supported locale.
- `tests/unit/xlvask-usage-pagination-404.spec.js` (new): four runtime
cases against `usePaginatedList` cover the success path, 404 capture,
reset on the next request, and skip-on-cancel.
- Full unit suite: **1768/1768 pass across 255 files**.
- ESLint clean on all four modified files plus the new spec.
- `npm run i18n:v2:check` (source check, global-template audit, template
dedupe, word audit) all green.
- No new dependencies; uses existing `vue` (`ref`, `computed`, `watch`),
`axios` response shape, and `vue-i18n`.
## Files changed (16 files, +176 / -16)
- `src/components/pagination/paginatedList.vue` (+14 / -3)
-
`src/components/displays/pagination/models/DepartmentPos/XLVaskUsagePagination.vue`
(+23 / -3)
-
`src/i18n/source/{en,da,de,no,sv}/phrases/compat/invoicing_period/xlvask_review.json`
(+3 each / -2 each, net +1 per locale)
- `src/i18n/source/global/shared/invoicing_period/xlvask_review.json`
(+1)
- `src/i18n/generated/{en,da,de,no,sv}-v2.json`, `global-v2.json`
(regenerated)
- `tests/unit/superuser-invoices-view.spec.js` (+24)
- `tests/unit/xlvask-usage-pagination-404.spec.js` (new, +90)
Logic-only frontend change; no visual diff beyond a single info notice
(which is the entire point of the fix). No backend API endpoint touched.
_This PR was created by an AI agent (OpenHands) on behalf of the
OpenSymphony autonomous workflow._
Co-authored-by: Jeppe <jeppe@copenhagentruckwash.io>
Co-authored-by: openhands <openhands@all-hands.dev>
truckwashdashboardsfrontend
This template should help get you started developing with Vue 3 in Vite.
Recommended IDE Setup
VSCode + Volar (and disable Vetur).
Customize configuration
See Vite Configuration Reference.
Project Setup
npm install
Contributing Changes
Create a scoped feature branch, push it, and open a pull request targeting
master. Do not push directly to master. Merge only after the Required CI
check succeeds, all review conversations are resolved, and the branch is up to
date. Use squash merge so master retains linear history.
See .github/BRANCH_PROTECTION.md for the
repository policy, rollout checks, and emergency bypass procedure.
Compile and Hot-Reload for Development
npm run dev
By default, the Vite dev server proxies /api/* to the remote stable API at
https://api-v2.truckwash.io/master/api. This lets the Vue app run locally
without a local PHP API container.
To develop against a local PHP API instead:
$env:VITE_API_PROXY_TARGET="http://localhost"; npm run dev
To use another remote API route:
$env:VITE_API_PROXY_BASE_PATH="/canary/api"; npm run dev
TLS certificate validation is enabled for proxied HTTPS APIs by default. If you are using a trusted local HTTPS API with a self-signed certificate, you can opt out explicitly:
$env:VITE_API_PROXY_TARGET="https://local-api.test"; $env:VITE_API_PROXY_SECURE="false"; npm run dev
For compatible local gateways that expect the /api prefix to be preserved:
$env:VITE_API_PROXY_TARGET="http://localhost"; $env:VITE_API_PROXY_STRIP_PREFIX="false"; npm run dev
Compile and Minify for Production
npm run build
Playwright Batched Chromium Runs
Run default e2e tests in deterministic 25-test shards across chromium-desktop and chromium-mobile:
npm run test:e2e:batched:chromium
Run the same flow and automatically re-run failed shards with PLAYWRIGHT_WORKERS=1:
npm run test:e2e:batched:chromium:rerun-failed
Optional overrides:
PLAYWRIGHT_BATCH_SIZE=25
PLAYWRIGHT_BATCH_WORKERS=2
PLAYWRIGHT_BATCH_DEV_PORT=5193
You can also forward Playwright args:
npm run test:e2e:batched:chromium -- --grep @smoke
Artifacts and summaries:
output/playwright/batched-chromium/last-run.jsonoutput/playwright/batched-chromium/failed-shards.jsonoutput/playwright/batched-chromium/report-index.htmloutput/playwright/batched-chromium-shard-<i>-of-<n>/report/index.htmloutput/playwright/batched-chromium-rerun-shard-<i>-of-<n>/report/index.html
Playwright Full E2E
Run the permanent grouped full-suite entrypoint with a hard max of 5 total workers across the browser-engine groups:
- Chromium
- WebKit
- Firefox
npm run test:e2e:ci
The full CI matrix is ordered by browser engine, then device class, then user role:
- browsers:
chromium,webkit,firefox - devices:
mobile,desktop,tablet - roles:
superuser,admin,customer,subuser
Run a single full-suite slice for one role and one Playwright project:
npm run test:e2e:full:slice -- --role=admin --project=webkit-tablet
Default worker allocation:
PLAYWRIGHT_PARALLEL_WORKERS_CHROMIUM=2
PLAYWRIGHT_PARALLEL_WORKERS_FIREFOX=1
PLAYWRIGHT_PARALLEL_WORKERS_WEBKIT=1
Optional overrides:
PLAYWRIGHT_PARALLEL_BASE_PORT=5191
PLAYWRIGHT_PARALLEL_WORKERS_CHROMIUM=2
PLAYWRIGHT_PARALLEL_WORKERS_FIREFOX=1
PLAYWRIGHT_PARALLEL_WORKERS_WEBKIT=1
The runner fails fast if the combined worker count exceeds 5.
GitHub Actions keeps the full browser/device/role matrix stable by capping full-suite
matrix parallelism at 2 jobs, running each full slice with PLAYWRIGHT_WORKERS=1,
wrapping Docker Playwright runs with systemd-inhibit when available, and setting
PLAYWRIGHT_VIDEO_MODE=off for the full matrix. The E2E network harness serves
Font Awesome from local fixtures so WebKit page loads and visual snapshots do not
depend on CDN/TLS availability. Traces and screenshots are still retained on
failure.
Artifacts and summaries:
output/playwright/ci-parallel-report/index.htmloutput/playwright/ci-parallel-chromium/report/index.htmloutput/playwright/ci-parallel-firefox/report/index.htmloutput/playwright/ci-parallel-webkit/report/index.htmloutput/playwright/test-lists/<project>-<role>.txtoutput/playwright/test-lists/<role>-<project>.txt(legacy compatibility copy)
Android App Icon
The Play Store Android package is built from the Capacitor project in android/.
The legacy Bubblewrap/TWA project at the repository root is not used by
npm run mobile:android:bundle.
The native launcher and store icons use the opaque iOS marketing icon as their shared master so Android and iOS keep the same white background:
ios/App/App/Assets.xcassets/AppIcon.appiconset/AppIcon-1024.png
Regenerate the checked-in launcher assets after changing that source image:
npm run mobile:android:icons
Check that the generated Android launcher assets are current:
npm run mobile:android:icons:check
npm run mobile:android:sync runs the icon generator before building and syncing
the Capacitor Android project. The generator updates android/app/src/main/res
launcher assets, public/icons/icon-192x192.png, public/icons/icon-512x512.png,
and store_icon.png.
Mobile Store Releases
Signed Android and iOS store artifacts are built through the GitHub Actions
Mobile Store Artifacts workflow. By default, current master after green
Automated Tests uploads Android to Google Play production and uploads iOS to
App Store Connect.
See docs/mobile-artifacts.md for workflow triggers, required secrets, and
local mobile checks. See docs/app-store-release.md for App Store Connect
release preparation and review notes. For a separate development-signed IPA
that can be installed on an approved iPhone from Ubuntu over USB, see
docs/ios-device-debug.md.
Bubblewrap (TWA) Build and Install
To build and install the Trusted Web Activity (TWA) using Bubblewrap, use the following commands:
Build the TWA
bubblewrap build
Install the TWA on a connected device
bubblewrap install