## Summary
- Add self-service deletion for the authenticated customer or subuser
identity only.
- Preserve shared customer grants, reset keys, bookings, order bookings,
vehicles, invoices, and legally required history.
- Require password/TOTP or a fresh deletion-specific, five-minute,
single-use WebAuthn assertion.
- Reject support impersonation and expired legacy plain-session tokens.
- Use durable database throttling, transactional request processing, a
durable outbox, and terminal `manual_review` state.
- Keep API and worker default-off behind separate
`account_deletion.api_enabled` and `account_deletion.worker_enabled`
module-config flags.
## Safe rollout
1. Keep both flags disabled.
2. Run `php scripts/account-deletion-schema.php check`.
3. If needed, run `php scripts/account-deletion-schema.php apply --yes`,
then rerun `check` until `ready:true`.
4. Deploy the frontend companion PR while the API remains disabled.
5. Enable `api_enabled` for a controlled canary; verify password and
passwordless request flows plus immediate authentication revocation.
6. Inspect queued request/outbox state, then enable `worker_enabled`.
7. Verify anonymization, preserved tenant/history data, outbox delivery,
retries, and manual-review behavior before broad rollout.
## Verification
- Account deletion unit tests: 2 passed, 43 assertions.
- PHP lint, both OpenAPI YAML parses, runtime-DDL scan,
destructive-scope scan, and `git diff --check` passed.
- Full API/unit/integration evidence is required from exact-head CI;
local Docker is unavailable and shared-vendor tests were explicitly
discarded.
## Security notes
- Schema mutation is CLI-only; web and cron paths perform read-only
readiness checks.
- Runtime behavior fails closed when schema/config/throttle/delivery
prerequisites are unavailable.
Resolve recommended-profile Critical and High findings, retain narrow analyzer exceptions, and update the edge-broker WebSocket dependency to a non-vulnerable release.
Introduce unit and API tests for subuser password policies ensuring compliance with complexity requirements. Normalize subuser grant permission handling for consistency, including support for legacy zero permissions.
- Introduced `safety_seal` column in the `orders` table.
- Updated order creation and completion logic to handle safety seal values.
- Enhanced order and booking classes to manage safety seal attachment and retrieval.
- Added tests to validate safety seal functionality in order processing.
- Introduced Redis-backed caching for user and subuser permission evaluations in the `route_t` trait, reducing database queries.
- Enhanced `Redis` class with methods for permission caching: `cache_permission`, `get_permission`, and `clear_permission`.
- Added test coverage for the new caching logic in `PermissionRedisCacheTest.php`.
- Implemented Redis caching for authentication sessions with `cache_auth_session`, `get_auth_session`, and `clear_auth_session`.
- Improved CORS handling for preflight requests in `index.php`.
- Add fallback logic to resolve subuser sessions via the tokens table when cache is missing or expired, with re-caching for future use.
- Refactor 2FA flow to prioritize subuser over user objects for better clarity and ensure compatibility with TOTP logic.
- Add safeguards to avoid operations on nonexistent users or subusers in 2FA and authentication flows.
- Extend `users_o` and `subusers_o` with `two_factor_enabled` and `two_factor_secret` properties.
- Implement methods for managing 2FA (`isTwoFactorEnabled`, `setTwoFactorSecret`, `verify_2fa_code`) in authentication logic.
- Add 2FA handling in login flows for both users and subusers, including token generation and validation.
- Introduce `totp` class for TOTP-based authentication, including QR code generation and code verification.
- Add test cases for 2FA functionality (`TwoFactorAuthTest.php`) and coverage for login scenarios with 2FA.
- Update OpenAPI specifications to include 2FA flows (`auth/2fa/setup`, `auth/2fa/enable`, `auth/2fa/verify`, `auth/2fa/disable`).
- Introduce `hasPermission` method in `subusers_o` for permission checks tied to customer context.
- Update `/subusers/me` route to return subuser grants with normalized permissions and metadata.
- Add `get_subuser_customer_number_target` in `authentication` to resolve customer context from request headers.
- Refactor route-level permission checks to handle subuser grants dynamically.
- Introduce CLI test scripts for subuser grants and permission node mappings.
- Add test coverage for subuser grants and permission nodes in new test classes.
- Add token creation for subusers in `subusers_o` during session generation.
- Refactor `orderBookingRoute` to use dynamic subuser permission definitions with `subusers_permission_node_key`.
- Introduce a comprehensive permission system for subusers, including permission nodes and types with support for vehicles, bookings, orders, subusers, and self-serve modules.
- Implement `subusers_user`, `subuser_user_grant`, and `subusers_permission_node` classes for managing subuser permissions and grants.
- Extend `subuser_grants_o` with methods to retrieve permissions for subusers linked to customers.
- Add traits and enumerations to streamline permission handling across modules.
- Update subuser session handling to include token-based subuser lookups.
- Add `/subusers/auth/password` route for subuser authentication using password or other username types (phone, ID, etc.).
- Implement `getSubuserByUsername` in `subusers_o` for retrieving subusers by username.
- Introduce `generateSession` in `subusers_o` for creating and caching session tokens with expiration logic.
- Introduce `invalidateSetupToken` method in `subusers_o` to invalidate setup tokens after registration completion.
- Replace regex with `filter_var` for stricter email format validation.
- Update registration link domain from `web.truckwash.dk` to `truckwash.io`.
- Introduce `/subusers` route for creating subusers and linking them to companies via phone number validation.
- Add token-based subuser setup flow including token generation, validation, and expiration handling.
- Extend `subusers_o` with methods for subuser lookup, token handling, and secure password management.
- Implement enhanced input validation for subuser creation, ensuring stricter checks for name, username, and email fields.
- Introduce `setPassword` method for securely updating subuser passwords with validation and hashing.
- Enhance `add` method with stricter password validation and error handling.
- Refactor exception handling and standardize imports for improved clarity.
- Define object properties for subuser details (username, password, email, etc.).
- Implement methods for adding subuser records with validation and password hashing.
- Include database table structure and property setup within the class.
Jeppe B