Roles & Permissions

This page explains the roles Buzz uses, who gets them, and what each one can do. Use it when you set up an event team — organizers, check-in staff, and attendees all sit at different permission levels.

Buzz ships three roles that matter day to day:

The exact role names are Buzz User, Frontdesk Manager, and Event Manager. Assign them as written — Frappe roles are case-sensitive.

The Buzz User and Frontdesk Manager roles are created when you install the app (they ship as fixtures). See Install & Setup for the install steps.

Buzz User (auto-assigned)

Buzz User is the default role for everyone who interacts with the dashboard — attendees booking tickets, sponsors submitting enquiries, and speakers proposing talks.

You don't assign this role manually. Buzz adds it to every user the moment the user record is created, via an after_insert hook on the User doctype. This covers people who sign up themselves and guest users created automatically during OTP-based guest booking, so anyone who lands in the system can immediately use the dashboard.

What a Buzz User can do:

• Book tickets and pay (create and edit their own Event Booking).
• View events that are published.
• Manage their own tickets — transfer, change add-ons, request a cancellation — from /b/account.
• Submit and track talk proposals and sponsorship enquiries.

What a Buzz User cannot do:

• Edit or delete events (read-only access to Buzz Event).
• Submit or cancel bookings at the document level (that's reserved for managers and the system).
• Check in tickets.

Ownership is enforced on top of the role: dashboard actions check that the booking, ticket, or enquiry belongs to the current user before allowing changes. For example, requesting a cancellation or viewing a sponsorship enquiry is blocked unless you own the record or hold write/read permission on it through a higher role.

Inviting other organizers

When an organizer invites teammates through Frappe's user invitation flow, Buzz limits which roles can be granted:

• An Event Manager can invite people as Buzz User.
• A Buzz User can invite people as Buzz User.

So an invite never escalates someone above your own baseline through this flow — granting Event Manager or Frontdesk Manager is done directly on the User record by an admin (below).

Frontdesk Manager (check-in)

Frontdesk Manager is the door-staff role. Assign it to anyone who runs the check-in scanner on event day.

This role gates the check-in API directly. The scanner's two server calls — validating a scanned ticket and recording the check-in — both require the Frontdesk Manager role; a user without it gets a permission error and cannot scan. At the doctype level, a Frontdesk Manager can read, create, and edit Event Check In records (but not delete, submit, or cancel them).

A Frontdesk Manager does not automatically get event-management access — give the same person Event Manager as well if they also need to edit events or bookings.

For the end-to-end scanning flow, see Check-in Scanner.

Event Manager (event & booking admin)

Event Manager is the back-office role for the people who actually run events from Desk. It carries full management permissions across the core doctypes:

• Buzz Event — read, write, create, delete.
• Event Booking — read, write, create, delete, submit, and cancel (the booking lifecycle actions a Buzz User can't perform).
• Event Check In — read, write, create, delete, submit, cancel.

Event Managers also pass the ownership checks on sponsorship enquiries and bookings — actions that a plain Buzz User can only perform on their own records, an Event Manager can perform across the board because they hold write/read permission on those doctypes.

In short: assign Event Manager to organizers and back-office staff who need to create and manage events, ticket types, bookings, and sponsorships in Desk. Assign Buzz User only (the default) to attendees.

How permission gating works

Buzz layers two kinds of checks:

1. Doctype permissions — the standard Frappe role table on each doctype (the tables above). These decide who can read/write/create/delete/submit/cancel a record type.
2. Code-level checks in the dashboard API — on top of doctype permissions, sensitive actions add explicit guards:
   • Check-in requires the Frontdesk Manager role before a ticket can be validated or checked in.
   • Booking and sponsorship actions verify record ownership (record.user == current user) and fall back to a Frappe permission check, so a Buzz User can only act on their own bookings and enquiries, while a manager with write/read permission can act on any.

This means simply having Buzz User is never enough to reach the door scanner or to touch another attendee's booking — the role check or the ownership check stops it.

Assigning a role to a user

To grant Frontdesk Manager or Event Manager:

1. In Desk, go to the User list and open the person's User record.
2. In the Roles section, add the role (Frontdesk Manager and/or Event Manager).
3. Save.

Buzz User is already there from account creation, so you only ever add the elevated roles.