Fix RBAC misconfiguration for /users/guards endpoint (Phase 1)

[LoopyB]

Quick PR addresses an RBAC issue in the /api/v1/users/guards endpoint.

Issue

• Route referenced invalid role EMPLOYEE
• Employers were receiving 403 errors
• Endpoint currently returns unscoped guard data

Fix (Phase 1)

• Removed invalid role EMPLOYEE
• Restricted endpoint to ADMIN only for now
• Added TODO for scoped employer access

Notes

Employer access will require:

• proper RBAC permission design
• organisation-based filtering in the service layer

This will be handled in a follow-up task.

[uppalkrish]

Hey
Please let employers and admin both access this endpoint

[LoopyB]

Hey Krish, quick clarification on this one.

At the moment the endpoint returns all guards with no employer/org scoping, so allowing EMPLOYER here would expose global guard data across tenants.

That’s why I restricted it to admin only in Phase 1.

Happy to enable employer access, but I think we should do it with scoped filtering (guards linked to the employer’s organisation), otherwise we’ll leak data.

Do you want:

1. quick enable (no scoping, all guards visible), or
2. scoped access (correct long-term approach)?

I can implement either, just want to confirm direction (fyi phase 2 and 3 are outlined in the ticket in Teams)

[uppalkrish]

Since the platform operates as a free marketplace rather than an organisation-locked system, guards are not permanently tied to any single organisation. Instead, they exist as independent users who can browse and apply for shifts across multiple organisations.

To implement scoped access in this model, the relationship between a guard and an organisation should be contextual and temporary, based on shift applications rather than fixed assignments.

A practical approach is:

Guards apply to shifts posted by organisations.
When a guard applies, a link is created between the guard and the organisation through that specific shift (e.g., via an Application or ShiftAssignment entity).
The employer reviews applicants and selects a guard.
Only upon selection does the guard gain scoped access to that organisation’s relevant data (e.g., shift details, communication, incident reporting).

This means:

No permanent guard–organisation mapping is required.
Access control is enforced dynamically based on accepted shifts, not user roles alone.
Employers retain full control over who gets access by deciding which guard is assigned.

In short, the system should treat the guard–organisation relationship as event-driven (per shift) rather than structural (per organisation).
@LoopyB

[LoopyB]

Updated the Phase 2/3 proposal based on the marketplace model in the Teams ticket.

Switched from organisation-based scoping to shift-based (application/assignment-driven) access.

Let me know if that aligns