Team, roles and workspaces
Who can sign in to the organiser dashboard, the four seeded roles, every permission the API checks, the workspaces a member switches between, and how to give each team member exactly what they need.
For the Full Stack package
How access works
- Staff sign in to the dashboard. Attendees have their own accounts on the website and never sign in to the dashboard.
- A member holds a role, and a role is a set of permissions named
<area>.<action>, such asevents.publish. The role is the same in every workspace the member belongs to. - The API checks a permission on every dashboard route, whatever the screen shows. The dashboard hides the sidebar items, tabs and buttons a role does not include, and a page opened by its address says "This page is not part of your role".
- A change to a member's role, or to a role's permissions, reaches that member while they are signed in.
- Each member lands on the first page their role opens: the overview for most, the check-in page for the Check-in role.
The seeded roles
| Role | Permissions | Sidebar |
|---|---|---|
| Owner | All 29 | Overview, Events, Orders, Check-in, Venues, Reports, Team, AI assistant, Venue studio and Settings |
| Manager | overview.view, events.view, events.edit, events.publish, venues.view, venues.edit, orders.view, checkin.scan, reports.view, reports.export, leads.view, leads.edit, studio.use, ai_chat.use, ai_chat.view_models: events, venues, check-in, reports, inquiries, the studio and the assistant, with orders read only; no refunds, team, roles or settings | Everything except Team and Settings |
| Finance | overview.view, orders.view, refunds.create, tickets.manage, reports.view, reports.export | Overview, Orders and Reports |
| Check-in | checkin.scan, for the sessions assigned to them only | Check-in |
The seed creates one account per role, a team of ten more members, and the attendee account on the website. It sets the four roles to exactly these lists each time it runs, so a change you made to one of them on the Roles page is undone by the next yarn seed; roles you created yourself are left alone, and an existing password is never reset. Change every password, or delete the seeded accounts, before the dashboard is reachable from the internet. The installation guide lists the sign-in details.
Every permission
| Area | Permissions |
|---|---|
| Overview | overview.view |
| Events | events.view, events.edit, events.publish |
| Venues and seat layouts | venues.view, venues.edit |
| Orders, refunds and tickets | orders.view, refunds.create, tickets.manage |
| Check-in | checkin.scan |
| Reports | reports.view, reports.export |
| Inquiries | leads.view, leads.edit |
| Venue studio | studio.use |
| Team | admins.view, admins.create, admins.edit, admins.delete, admins.assign_roles |
| Roles | roles.view, roles.create, roles.edit, roles.delete, roles.assign_permissions |
| Workspace settings | settings.view, settings.edit |
| AI assistant | ai_chat.use, ai_chat.view_models |
events.publishcovers publishing, unpublishing, cancelling and archiving an event;events.editcreating, editing and duplicating one.tickets.managereissues a ticket's QR code or voids a ticket;refunds.createrefunds tickets through the payment provider.admins.editalso assigns members to check-in sessions.
The list is defined once, in back-end/src/database/seeders/permission.seeder.ts; the seed adds new names and removes the ones the API no longer checks.
Workspaces
A workspace is one organiser: its events, venues, orders, door, reports, team and settings. The seed creates four (Northline Events, Kiln & Co., Mill Street Talks and Meadow Days), and the website lists the published events of all of them.
- The Workspace menu at the start of the dashboard's top bar lists the workspaces the member belongs to, their own first. The seeded Owner belongs to all four; the other seeded accounts to two or three.
- Choosing one reloads every page for that workspace. A record page (an order, an event, a venue) goes back to its list, since the record belongs to the other workspace.
- Each request carries the choice as the
X-Workspace-Idheader, and the API ignores a workspace the member does not belong to, falling back to their own. - The role is the same in every workspace: a role and its permissions apply in each workspace its members belong to. The bell, the inquiries and the roles are not per workspace: they stay the same whichever one is chosen.
- A member invited from the dashboard belongs to the workspace it was invited from. Adding a workspace, or an existing member to another one, is not a screen in the dashboard.
- An install started without the sample data has one workspace, created on the API's first start with its Owner from
OWNER_EMAILandOWNER_PASSWORD, as Deploy Ticketory explains.
The team
/en/dashboard/teamshows the workspace's members by role at the top, then the members table, ten a page, newest-updated first (admins.view).- One search box finds members by name or email: text with an
@searches the email, anything else the first name, the last name, the username or the full name. On the API,GET /api/adminstakesemail,nameandphone, and every filter given narrows the list: they combine with AND. - Invite member creates the account at once with a first and last name, an email, a role and a password of at least six characters, typed twice (
admins.create). Nothing is emailed: share the sign-in details with them yourself. - Each member's row edits their details (
admins.edit), changes their role (admins.assign_roles) or removes them (admins.delete). Remove takes the member out of the workspace you are working in, with their check-in sessions there; they keep signing in to their other workspaces, and the account itself is deleted only when this was its last one. The orders, refunds and check-ins they handled stay as they are. - Nobody can remove themselves ("You cannot remove yourself from the team."), and a workspace always keeps one Owner: removing the last one is refused with "This workspace needs at least one Owner. Give the Owner role to someone else first."
- A member's page lists what their role may do and, for a Check-in member, the sessions they may scan, ticked and saved there (
admins.edit). - Every member, whatever their role, edits their own name, email and phone under Settings, Profile, and changes their own password under Settings, Security, with their current one. Neither needs a permission.
Check-in staff and their sessions
A member who holds events.edit or events.publish can scan tickets for every session of the workspace. Anyone else with checkin.scan sees and scans only the sessions they are assigned to; a ticket for another session is refused with session_not_assigned. Assignments are made on the member's page in the dashboard, or with PUT /api/admin/session-staff/:code.
Roles
/en/dashboard/roles, opened from the Team page, shows what each role may do as a grid of capabilities, with a dot for allowed, some actions or not allowed. It creates, renames and deletes roles (roles.create, roles.edit, roles.delete), and grants their permissions (roles.assign_permissions). To give a team member less than a seeded role, create a role with only the permissions they need and assign it instead.
What the assistant can reach
ai_chat.use opens the AI assistant and grants nothing else. The assistant reads and changes only what the member's other permissions allow, the same ones the dashboard's pages check: without orders.view it cannot read an order, and without leads.edit it cannot change an inquiry. It checks again before every action, so a permission removed during a conversation applies to the next one.
How a change reaches a signed-in member
Included with your purchase. Sign in to read, or open it in your download.
The live connection that pushes a role change to a member who is signed in.