v1.4.8 - fix(permissions): Hero, Vigilante and Sidekick users can request again, and a tier change reaches a user who is already signed in
🩹 Hotfix
- Users signed in with a password got a red "Requests not enabled - Ask an admin to grant you the Request permission" message on every request button, even with the Request permission (every Hero, Vigilante and Sidekick), and several request and Monitor buttons were hidden from them. Users who sign in through SSO were not affected.
- Root cause: since the permission tiers arrived (v1.1.0-beta.055), the password sign-in copied every tier flag onto the session except "can request". The request buttons check that flag in the browser, so they refused before anything reached the server - which itself always checked the real permission and would have allowed the request. The header's tier badge showed these users as "Custom" for the same reason.
- A signed-in user now also picks up permission changes: applying a tier (or changing someone's role) used to change only the database, and their session kept its sign-in copy until they signed out. The session's periodic check (every 5 minutes) now refreshes the role and the tier flags too, and the activity ping no longer postpones that check for someone who is actively using the app - which also means a "sign out everywhere" or a password change now reaches the user's other open sessions within the same 5 minutes even while they're in use.
- While an admin is impersonating someone, that periodic check now looks at the admin's own account. It used to compare the admin's session with the impersonated user's account, which could sign the admin out a few minutes into impersonating.
📦 Upgrading
Standard three-service compose: docker compose pull && docker compose down && docker compose up -d. No compose, environment, or schema changes. Users who are signed in when you update are fixed within about 5 minutes without doing anything; signing out and back in fixes it immediately.
🧪 Verification
- Tests first (11 new, red → green): a password sign-in carries every tier's flags onto the session and the session reads as that tier (Civilian, Sidekick, Vigilante, Hero); a signed-in Sidekick becomes Hero at the next check without signing out; an old session missing "can request" is healed; permissions are taken away the same way (Hero → Civilian, an admin demoted to user); the activity ping no longer postpones the check, but a ping inside the 5 minutes still doesn't touch the database; impersonation is judged on the admin's own account, and revoking the admin's sessions still ends it. Mutation checks: undoing each of the four parts turns its tests red
- tsc clean, vitest 1522 passed / 2 skipped, eslint 0 errors, npm run build exit 0
- Live (lab copy, a Hero signing in through the real login form): on v1.4.7 the session lacked "can request", the Monitor buttons were hidden and Request Issue showed "Requests not enabled" without contacting the server; on this build the session carries it, the Monitor and per-issue Request buttons are back, and Request Issue answered "Download started" with the request auto-approved (PENDING, not waiting for an admin). An admin then changed the signed-in user to Vigilante through the Users page's route: the session kept Hero inside the 5 minutes and switched to Vigilante after them, without signing out