Fix: Guard Profiles page failing to load (403 errors) — FE 001

[josephmoorman]

Root cause

Employers got 403s ("Insufficient role" → "Insufficient permissions") loading Guard Profiles. Root cause was a data issue, not a code bug: the seeded employer Role doc in MongoDB was missing user:read. The RBAC logic was working correctly just with incomplete data.

The fix

• Added "user:read" to the employer role in src/scripts/seedRoles.js.
• Ran the script to apply it.

⚠️ Merging this alone won't fix local DB. See action required below.*** ⚠️

Also fixed (not root cause)

• user.routes.js: /guards route referenced ROLES.EMPLOYEE, which doesn't exist (only EMPLOYER does) dead code, removed.
• rbac.js: getEffectivePermissions() let an empty DB permissions array silently override in-code defaults. Added a guard so defaults are used unless the DB array is non-empty.
• rbac.js: authorizeRoles() now normalizes case/whitespace on role checks (defensive only — ruled out as the cause here).

Action required

• Anyone with an existing local DB, run after pulling: docker exec -it secureshift-backend node -r dotenv/config ./src/scripts/seedRoles.js
• We might need to consider auto-running the seed script on backend startup.

Testing

Reproduced by removing user:read from the local employer doc → confirmed 403. Re-ran seed script → confirmed Guard Profiles loads end-to-end for an Employer account.

[LoopyB]

PR #445 - FE 001: One backend authorisation correction is required before merge. The new empty-permissions fallback broadens access and causes users with an explicitly empty permission set to receive default permissions. Please remove that fallback so empty permissions remain deny-by-default, while retaining the employer seed and route fixes.

Please resolve merge conflicts.

No other changes requested.

[josephmoorman]

Completed requested change and resolved merge conflict.

[josephmoorman]

Completed requested change and resolved merge conflict.

[LoopyB]

Thanks for the work on this. I’ve reviewed the PR against current main and there are a couple of things I think need resolving before merge.

The new user:read requirement appears to change the existing /users/guards contract and could cause existing employer roles to receive 403s unless the role seed is manually rerun. Can you please confirm whether this permission change is actually required for FE 001? If not, I think it should be removed.

Also, FE 001 includes fixing Guard Profile data mapping/rendering, but the current PR doesn’t appear to change the frontend mapping. The page is still expecting fields that don’t match the current Guard/User schema.

Could you please revisit the API-to-UI mapping and add focused testing/evidence for the intended end-to-end behaviour? Once those are addressed I’m happy to review again.