Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jacobsamo/buzztrip/llms.txt

Use this file to discover all available pages before exploring further.

Every collaborator added to a BuzzTrip map is assigned one of four roles. These roles determine precisely what actions that person can perform — from editing markers and collections through to deleting the map itself. Roles are enforced server-side in Convex so they cannot be bypassed from the client.

The Four Roles

Owner

Full control over the map. Can manage all content, invite and remove collaborators, change roles, and permanently delete the map. Every map has exactly one owner — the person who created it.

Editor

Can create, edit, and delete all map content (markers, collections, labels, paths, routes) and invite or update collaborators. Cannot remove collaborators or delete the map.

Viewer

Read-only access to the map and all of its content. Cannot make any changes or invite others.

Commenter

Currently equivalent to Viewer. Can view all map content. Commenting and annotation features that will differentiate this role from Viewer are planned for a future release.

Permission Matrix

The table below is derived directly from rolePermissions in packages/backend/helpers/rbac.ts.
PermissionOwnerEditorViewerCommenter
View map
Create markers
Edit markers
Delete markers
Create collections
Edit collections
Delete collections
Create / edit / delete labels
Create / edit / delete paths
Create / edit / delete routes
Invite collaborators
Edit collaborator roles
Remove collaborators
Delete map
Update map settings

The canPerformAction() Helper

All permission checks throughout the Convex backend go through a single function:
import { canPerformAction } from "@buzztrip/backend/helpers/rbac";

canPerformAction(role, "markers:create"); // returns boolean
The function looks up role in the rolePermissions record and checks whether the requested permission string is present. It returns false for any unknown role or permission rather than throwing.

Permission String Format

Permissions follow the pattern entity:action:
<entity>:<create | update | delete>
Supported entity types:
EntityDescription
mapsThe map document itself
map_usersCollaborator records on a map
labelsText labels placed on the map
markersPoint-of-interest markers
collectionsGroups of markers
collection_linksAssociations between markers and collections
routesNamed routes on the map
route_stopsIndividual stops within a route
pathsDrawn paths / polylines
Example permission strings:
"markers:create"
"collections:delete"
"map_users:update"
"maps:delete"
"paths:create"

Ownership

When you create a new map in BuzzTrip you are automatically assigned the owner role for that map. Ownership comes with two exclusive permissions that editors do not have: removing collaborators (map_users:delete) and deleting the map itself (maps:delete).
Owners cannot be removed or downgraded by editors. Only the owner themselves can transfer or relinquish ownership.

Sharing & Managing Collaborators

To add a new collaborator, change someone’s role, or remove them from a map, see the Sharing guide. All role changes take effect immediately and are reflected in real-time for all active sessions on that map.
The commenter role currently carries no additional permissions beyond viewing the map. The ability to leave comments and annotations on markers and paths is on the BuzzTrip roadmap and will unlock the full potential of this role when released.

Build docs developers (and LLMs) love