Settings

Settings is where organisation profile, branding and user administration will live. The screen itself is planned, not yet built — the application currently shows a placeholder here. This does not mean the product has no roles or permissions: it already has both, enforced today, with just no in-app screen yet to administer them.

Every user signs in as one of four roles — Viewer, Contributor, Manager, or Admin — each carrying a defined set of permissions (e.g. hazards:write, safe_work_procedures:delete) that the real API enforces server-side; the frontend uses the same permissions to hide or disable actions a user almost certainly can't perform, as a UX nicety, not as the actual security boundary. A Viewer, for example, sees every register but no "Delete" button. There is no dedicated approval permission distinct from general write access, though — moving a Safe Work Procedure to approved or a Permit to Work to issued only requires the same write permission as any other edit to that register (see Record lifecycles and status).

Roles come from Cognito user-pool groups, mapped to permission sets the same way on both the frontend and the API. What's missing is a way to actually assign a user to a role, invite new users, or edit organisation profile/branding from within the application — that administration currently has to happen outside the product.

When this screen ships, it will let an Admin manage organisation profile, branding, and which role each user holds. Until then, role assignment is handled outside the application, and every signed-in user already operates under whichever role they were given.

If Settings isn't built, how does anyone get assigned a role today? Outside the application — there's no self-service or in-app way to do it yet.

Can a Viewer bypass a hidden action by navigating directly to a form URL? Against the real API, no — the server rejects it with a 403 regardless of what the frontend shows. (The one exception is the application's own mock-data developer mode, which doesn't enforce permissions locally — not a concern for real usage.)