Manage team access

Invite a teammate and control exactly what they can see and do, enforced on the server.

Goal

Give a teammate their own login with exactly the access you grant — nothing more — and have that access actually enforced, not just hidden in the interface.

Only the workspace owner manages team access (app/api/admin/team.py) — not a manager, not another teammate.

Steps

Team → Add to team → Panel access. Pick a starting preset (chatter, traffer, manager, trial) — presets are starting points, not a fixed menu.

Set a name, a login, and a password. The password is shown once, right after creation, and is never shown again — copy it there. It is only accepted on create or reset, never returned by any later read.

Tick which tabs the member can see, whether they can edit (vs. view-only) in each, and whether they see money figures. Optionally confine them to specific accounts.

Save. The teammate signs in on the normal panel login page with their own login and password.

How to verify it worked

Every grant is enforced on the server, for each request — hiding a tab in the interface is never the only fence. To verify: sign in as the teammate (or ask them to) and confirm they see exactly the tabs and edit/money state you set, and nothing else.

Concepts worth knowing

Roles (app/products/platform/core/rbac.py) — a principal's data scope is derived from membership rows: owner/manager with no creator confinement see the whole tenant; owner/manager confined to a creator, and model/chatter, only ever see that creator's data.
Job titles — a reusable named set of rights. While a person wears a title, their own checkboxes go read-only; unassigning one copies the current rights onto the person so nothing changes at that instant. A title someone currently wears cannot be deleted.
Ranks — 0 (executor) or 1 (manager). A manager can only manage executors, never another manager, and can never hand out wider access than their own grant.
Functions inside a tab — beyond view/edit, each tab has finer-grained function checkboxes (e.g. "send PPV", "manage scripts"). Unticking one makes the server refuse the action, not just hide the button.
Assigned accounts — confines a teammate to specific creators/accounts across money, inbox, dashboard, and exports alike, resolved in one place so no screen can show a wider slice than another.
Shifts — a member can have a separate, narrower role while off shift; leaving it unset means they see only the shift screen while off the clock.

Revoking access

Revoking a member frees their login immediately and kills every one of their active sessions right away — not on next request, not eventually.

If it doesn't work

A refusal always carries a human-readable message, not just a code — if a teammate reports being blocked, ask them what the message said before assuming it's a bug.
A tab or function the server doesn't recognize is refused outright, never silently dropped — a mismatch between the panel and the server shows up as an explicit error, not a checkbox that quietly does nothing.

Looking for the API?

/api/admin/team/* (members, roles, devices) has its own reference page — see API — Team access. /api/admin/shift/* is a separate, Club-owned API for work-shift scheduling; this section only validates against its shift vocabulary, it doesn't document those endpoints.

What's next

Want to know what a teammate can and can't reach outside their granted tabs? See Boundaries.