Roles and Permissions

This guide explains what each role can do and why some actions are intentionally restricted.

Community Roles

Event Staff Permissions (Event-Scoped)

Event staff can be assigned explicit permissions per event, such as:

• SCAN_TICKETS
• VIEW_ATTENDEE_LIST
• EDIT_EVENT
• MANAGE_TICKETS
• ISSUE_COMP_TICKETS
• OVERRIDE_CONSENT
• VERIFY_MEMBERS

This allows event-day delegation without granting full hub governance.

Sensitive Event Permissions

VERIFY_MEMBERS and OVERRIDE_CONSENT are intentionally stricter than normal event operations.

• VERIFY_MEMBERS lets staff review a member’s private door-check details: legal name and, if present, an optional private photo.
• OVERRIDE_CONSENT lets staff bypass required-form readiness at the scanner when policy allows.
• OWNER and ADMIN can use this capability implicitly.
• MANAGER is not implicit.
• Only OWNER and ADMIN can grant these sensitive permissions on staff roles, per-person staff overrides, or event-staff invites.

Hubs can have more than one OWNER, but use that sparingly. Treat OWNER as a very small trusted set of people who genuinely need equal governance and destructive control.

Event Staff Setup

Use Event -> Admin -> Staff when people should operate one event without becoming full hub admins.

• Create custom staff roles when the same permission bundle will be reused.
• Use Customise access on an individual staff assignment when one person needs an exception for that event.
• Reset that person back to Role defaults once the exception is no longer needed.
• Invite staff only to the event they need.
• Review pending invitations before event day so no one arrives without access.
• Prefer event staff permissions over broader hub roles when the need is operational, temporary, or event-specific.

Who Should Have Which Role?

• Use OWNER for very small trusted count.
• Use multiple OWNER users only when they need equal governance authority.
• Use ADMIN for people responsible for hub governance.
• Use MANAGER for reliable event operators.
• Use event staff permissions when someone should operate one event only.

Practical Capability Matrix

Permissions still depend on feature state:

• /chat, Hub -> Chat, and Event -> Chat all use the same shared channel creator now, but the member-facing pages still stay join/open-first.
• Owners, admins, and managers can create or manage hub/event channels from those surfaces where policy allows.
• Scan only appears when the event attendance registration allows QR scanning.
• Event Day stays available for roster-capable roles when attendance registration is off, but it becomes read-only and Scan is hidden.
• Managers keep full Event Day controls for event operations.
• Roster-capable staff can use Event Day as a read-only roster workspace when their permissions allow it, while scan-only staff stay focused on Scanner.

Why You Sometimes See 404 Instead of 403

Hubbaly uses privacy-by-default for sensitive resources:

• 404 can mean “not found” or “not allowed to know this exists”.
• This prevents existence leakage of private hubs, events, and records.

Permission Debug Checklist

1. Confirm active hub context.
2. Confirm your hub role in that hub.
3. If event-scoped, confirm event staff permissions.
4. Confirm whether route is governance-level or operations-level.
5. Capture URL + role + exact error text if still blocked.

Related Guides

• Hubs and Community Setup
• Community Admin
• Required Forms and Waivers
• Troubleshooting