Team members and roles

Why are there two surfaces — /settings/team and /settings/roles — that overlap so much?

Two different lenses on the same team_members rows. /settings/team leads with the membership perspective — “who's on the team, what role do they hold, are they accepted, when did they last sign in, who do I want to invite or remove?”. /settings/roles leads with the role-and-permission perspective — “what permissions does each member effectively have, what location access, what notification preferences, what phone number for WhatsApp alerts?”.

A manager managing headcount lands on /settings/team naturally. A manager tuning who can do what lands on /settings/roles. Both write the same data; switching between them mid-edit is safe — flipping a role on /settings/team is reflected on /settings/roles immediately on next load.

I want to promote someone to a role between manager and staff — finance-only or repairs-only or sales-only. Why can't I?

The four supported roles (owner, manager, staff, technician) are the role surface today. Specialty roles — salesperson, accountant, repair_technician, inventory_manager, workshop_jeweller — were originally planned and still appear in some older UI code, but the DB CHECK constraint rejects them. Assigning any specialty role fails at the database layer.

The intended shape is to start from one of the four baselines and tune via the permission matrix and per-member overrides. A “finance-only manager” is a manager role with most non-financial action keys disabled at the per-member override layer. A “sales-only staff” is the default staff (already sales-leaning). The permission keys cover the major dimensions — canCreateSales, canManageRepairs, canManageBespoke, canProcessRefunds, canViewFinancials, canCloseEOD, canManageTeam, canManageSettings — so most plausible specialty shapes can be expressed as overrides on a baseline role.

Why is the activity log owner-only? Managers handle day-to-day operations.

The activity log is the audit trail of consequential tenant operations, including the manager's own actions. A manager who could amend or read selectively the log of their own approvals weakens the audit property. Owner-only access preserves the log as a trustworthy after-the-fact record — the one role with no accountability above them is also the one role that reads the log.

Managers can still see the consequences of their own actions through the operational surfaces — the refunds list shows refunds they processed, the team page shows roles they assigned. The activity log adds the cross-cutting view, which is the audit dimension that's owner-gated by design.

I forgot my manager-PIN. Can someone reset it for me?

The owner can clear your PIN from the team / roles surface. The reset clears the PIN and forces you to self-set on your next PIN-needing operation — the owner doesn't see your old PIN at any point and doesn't set the new one for you. The reset is audit-logged so the trail of who reset whose PIN when is preserved.

If you're the owner and YOU forget your own PIN, set a new one from your account settings — your PIN is self-controlled, and replacing it is just re-running the set flow with a new value. The previous PIN hash is overwritten.

How do I see when a team member last signed in?

Both /settings/team and /settings/roles surface the last-sign-in timestamp on each member card. The system reads the timestamp from Supabase's underlying auth.users.last_sign_in_at column, which auto-populates on every successful login. Pending invites that have never been accepted render as “Never” — no auth record yet exists for them.

Useful for spotting dormant accounts (former staff who should be removed) and for confirming an invitee has actually completed signup. If a member shows “Never” but says they've been using the system, their invite probably wasn't accepted in the usual flow — check the invite-status badge; if it's Expired, hit Resend.

Can a manager edit business profile, tax, or banking?

Yes — manager role passes the owner-or-manager gate on /settings/business-profile and the legacy /settings tabs. The settings role-tier boundary is owner-or-manager (which gates the page-layer access), not owner-only. The one exception is canManageSettings as a permission key — the default is OFF for manager, which is the permission-matrix surface, not the role gate. The role gate at the page layer takes precedence; the key's default OFF was a permission-matrix artefact from an earlier model that hasn't been reconciled.

Practical implication: managers in your tenant can edit business profile, tax, banking, and numbering by default. If you want to restrict that, the only path today is removing the manager role entirely from that person and using per-member permission overrides on a staff role instead. We're tracking the reconciliation for a future settings cleanup.

What sensitive operations get audit-logged versus not?

Logged: settings updates (business profile, tax, currency, banking, numbering), role assignments and permission changes, manager-PIN sets and resets, team-member invites and removals, refund processings, and several specific sensitive state-change paths in inventory and finance. The entity_type filter on the activity log enumerates the types currently captured.

Not logged: read-only operations (viewing a customer, opening a sale), high-volume operational writes (creating a routine sale, updating an inventory quantity in-flow), and signin / signout events themselves (last-sign-in is captured at the auth layer but isn't replayed into the audit log). The log captures the consequential mutations that matter for after-the-fact investigations without flooding the surface with routine activity.

Invite email never arrived

Symptom: you sent an invite, the team page shows the member as Pending, but they say no email arrived. Cause: most commonly the email landed in their spam folder, or their corporate mail filter blocked the sender. Less commonly, the email address was typed wrong. Fix:ask them to check spam and add support@nexpura.com to their safe-senders list. If the email address was wrong, remove the pending invite and re-invite with the correct address. If the right address still isn't delivering, use the Resend action on the pending row — that regenerates the link with a fresh window and re-sends.

Trying to assign a role that the UI shows but the system rejects with a 500 error

Symptom: you select a role from a dropdown that includes specialty options (salesperson, accountant, inventory_manager, workshop_jeweller, repair_technician), save, and the server returns a 500 or an opaque database error. Cause: the DB CHECK constraint on users.role and team_members.role only accepts owner, manager, staff, or technician. The dropdown including specialty options is leftover dead UI from an earlier role model. Fix: use one of the four supported roles. If you need a shape between manager and staff (e.g. a sales-leaning staff member who can also process refunds), assign the closest baseline role (staff) and use per-member permission overrides on /settings/roles to flip the keys you need. The Common questions section above covers the recommended shapes.

Permission matrix change persists, but the member still hits Access Denied

Symptom: you flipped a permission ON for a role at /settings/team/permissions, but the affected member still gets Access Denied on the surface they were trying to reach. Cause:two common reasons. First, the member is using a cached session and hasn't reloaded since the matrix change. Second, there's a per-member override on that key that's overriding the role default — the per-member value takes precedence. Fix:ask the member to hard-refresh (Cmd+Shift+R or Ctrl+Shift+R) — that pulls a fresh server-side permission read. If the issue persists, open the member's detail panel on /settings/roles and check the per-member override for the affected key — clear it to fall back to the role default, or flip the override explicitly to the value you want.

Manager-PIN keeps rejecting a PIN I'm sure is correct

Symptom:the refund-override modal returns “Invalid PIN” or “Too many attempts” even though you've entered the right code. Cause: three possibilities. First, the per-user rate limit (5 attempts per minute) tripped from earlier wrong entries — the next attempts get blocked regardless of correctness. Second, the PIN field rejects non-numeric input silently; if you typed letters or special characters in by accident, the system treats it as a malformed PIN with no error detail. Third, you genuinely forgot the PIN. Fix: wait a minute for the rate limit to lift, retry with the numeric PIN only (no spaces, no letters). If still failing, ask the owner to reset your PIN from /settings/roles → your detail panel; you'll self-set a new one on the next refund operation.

Member removed but their historical sales / repairs still show their name

Symptom: you removed a former staff member, but their name still appears on historical sales, repairs, and other records they created. Cause: expected — removal soft-clears theteam_members row (revokes their access) but leaves the historical attribution. Reports broken down by salesperson, repair technician, or clienteler still need the historical name to display correctly. Removing a member doesn't rewrite their history. Fix:no fix needed — this is the correct behaviour for audit and reporting integrity. The removed member can no longer sign in or take new actions; their old actions stay attributed to them. If you need a specific historical row reattributed (e.g. they shouldn't have been credited with that sale), edit the row directly — most surfaces support changing the assigned-to / salesperson field.

Activity log shows “Access Denied” for a manager

Symptom: a manager navigates to /settings/activity and sees Access Denied. Cause: expected — the activity log is owner-only by design. The page checks role and returns the denial for anything below owner. Common questions above covers the rationale. Fix:if a manager needs information from the log (e.g. when a specific change was made), ask the owner to pull the log filter and screenshot or export the relevant range. The owner gate is intentional; there's no role escalation path here without promoting the manager to owner (which is a one-per-tenant role).