a345d91ae4
## Summary
Closes (heuristic for) **TRU-99 / SENERE 7**: warn operators in the
customer portal wash flow when a customer is flagged as a red car.
## Detection rule — heuristic, Mads to refine
The canonical rule (plate scan vs. red-car tag) is still TBD by Mads. As
a sensible default that fits the existing data model, this PR uses a
**manual customer-attribute flag**:
- If a customer has one of the configurable attribute keys set, the
warning fires. Default keys: `isRedCar`, `is_red_car`, `redCar`,
`red_car`.
- Detection is **case-insensitive** and the key list is **configurable**
(callers can override) so the rule can be tightened later without
touching the UI.
- Detection lives in `src/composables/redCarDetector.js`; reactive
loading lives in `src/composables/useRedCarWarning.js`.
- The composable reuses the existing `/customer/attributes` endpoint via
`customerAttributeService.js` — no backend change needed.
## UI
- New `RedCarWarning.vue` component renders a dismissable Buefy warning
in the vehicle step of the self-serve flow, with title + reason + care
suggestion.
- Wired into `MyWashStart.vue` via the existing `VehicleInputSection` /
`SelfServeVehicleStep` props. The composable is called with the
effective customer number (authenticated subuser or typed-in).
- Translations added in all 5 locales: `da`, `en`, `sv`, `de`, `no`
(source + regenerated runtime files).
## Tests
- 22 detector unit tests (positive, negative, case-insensitive, custom
keys, dedupe, normalisation).
- 5 i18n key presence tests across all 5 locales.
- 4 `RedCarWarning` component tests (conditional render, dismiss
wiring).
All new + existing related tests pass: `vitest run` on
`red-car-detector`, `red-car-warning-i18n`, `red-car-warning`,
`my-wash-start`, `customer-rule-registry`, `customer-rule-tooltip` →
**84/84 green**.
## Out of scope / not touched
- Backend / API: reused existing `/customer/attributes` endpoint.
- `openclaw.json`, deployment, merge — not touched (per task
constraints).
- Customer-rule registry: not added to `CUSTOMER_RULE_DEFINITIONS`
because the red-car flag is a soft warning, not a product-restriction
rule. If Mads wants it surfaced in the customer rule manager UI, that is
a follow-up.
## Files
- `src/composables/redCarDetector.js` (new)
- `src/composables/useRedCarWarning.js` (new)
- `src/components/displays/selfServe/RedCarWarning.vue` (new)
- `src/components/displays/selfServe/SelfServeVehicleStep.vue` (prop +
render)
-
`src/views/dashboards/userDashboard/wash/components/VehicleInputSection.vue`
(prop pass-through)
- `src/views/dashboards/userDashboard/wash/MyWashStart.vue` (composable
+ prop binding)
- `src/i18n/source/{da,en,sv,de,no}/phrases/compat/self_wash/index.json`
(new keys)
- `src/i18n/generated/{da,en,sv,de,no}-v2.json` (regenerated)
- `tests/unit/red-car-detector.spec.js` (new)
- `tests/unit/red-car-warning-i18n.spec.js` (new)
- `tests/unit/red-car-warning.spec.js` (new)
Refs: TRU-99
---------
Co-authored-by: Jeppe B <jeppe@copenhagentruckwash.io>
Co-authored-by: Frontend Subagent <frontend-agent@openclaw.local>
Co-authored-by: Pleno Bugfix Bot <bugfix-bot@pleno.local>
52 lines
2.4 KiB
JavaScript
52 lines
2.4 KiB
JavaScript
// @vitest-environment node
|
|
|
|
import { readFileSync } from "node:fs";
|
|
import { join } from "node:path";
|
|
import { describe, expect, it } from "vitest";
|
|
|
|
const readSource = (relativePath) => readFileSync(join(process.cwd(), relativePath), "utf8");
|
|
|
|
describe("XLVaskUsagePagination department (HallId) propagation", () => {
|
|
const source = readSource("src/components/displays/pagination/models/DepartmentPos/XLVaskUsagePagination.vue");
|
|
|
|
it("reacts to department changes via a computed effectiveDepartmentId", () => {
|
|
// The department must be derived reactively from the prop and the
|
|
// route param, not captured once at setup time.
|
|
expect(source).toMatch(
|
|
/const\s+effectiveDepartmentId\s*=\s*computed\(\s*\(\)\s*=>\s*[\s\S]*?props\.departmentId[\s\S]*?routeDepartmentId\.value[\s\S]*?\)\s*\)/
|
|
);
|
|
});
|
|
|
|
it("watches the effective department and re-applies the HallId filter", () => {
|
|
// The component must watch the computed effective department so
|
|
// changing the department selector re-issues the query with the
|
|
// new department in the filter.
|
|
expect(source).toMatch(/watch\(\s*effectiveDepartmentId\s*,/);
|
|
expect(source).toMatch(/setFilter\(\s*["']HallId["']\s*,\s*nextDepartmentId\s*,\s*false\s*\)/);
|
|
});
|
|
|
|
it("re-issues the usage query when the department changes", () => {
|
|
// The watch handler must trigger both loadList and loadSummary so
|
|
// the visible orders and the summary cards both reflect the new
|
|
// department.
|
|
const watchBlockMatch = source.match(/watch\(\s*effectiveDepartmentId\s*,[\s\S]*?\n\)\s*;/);
|
|
expect(watchBlockMatch).not.toBeNull();
|
|
const watchBlock = watchBlockMatch?.[0] ?? "";
|
|
expect(watchBlock).toMatch(/loadList\s*\(\s*\)/);
|
|
expect(watchBlock).toMatch(/loadSummary\s*\(\s*\)/);
|
|
});
|
|
|
|
it("clears the HallId filter when the department is unset", () => {
|
|
// When the new department is 0 / unset, the filter must be cleared
|
|
// (setFilter with '*' removes the key) so the query is not bound
|
|
// to a stale department.
|
|
expect(source).toMatch(/setFilter\(\s*["']HallId["']\s*,\s*["']\*["']\s*,\s*false\s*\)/);
|
|
});
|
|
|
|
it("includes the active department in the summary query params", () => {
|
|
// The summary endpoint must also be re-issued with the new
|
|
// department; otherwise the summary cards show stale counts.
|
|
expect(source).toMatch(/HallId:\s*effectiveDepartmentId\.value/);
|
|
});
|
|
});
|