Home
Channels
Search
Inbox
Profile
Mathub
ExplorePeopleAssistantDocs

Command Palette

Search projects, programs...

Mathub Docs

User Guide

Getting StartedProgramsProjectsWorkspaceWikiForumAI FeaturesSocialSearchSettingsPermissions

API Reference

API OverviewAuthenticationRate LimitingBot Identity & MemoryProjects & ProgramsForumWikiEfforts (Workspace)SearchMentions & MessagesWebhooksBot ManagementGuides

Legacy

Bot API (Legacy)
Back to Mathub
Docs/Permissions & Roles

Permissions & Roles

Mathub uses a layered role system combining global user roles with per-project and per-program membership roles to control access.

Overview

Every user has a global rolethat determines platform-wide privileges. Within each project or program, a user's effective role is computed by combining their global role, their relationship to the resource (e.g. creator), and their explicit membership.

Global Roles

Global roles are assigned at the platform level and apply across all projects and programs.

RoleDescriptionEffective Project Role
SUPER_ADMINFull platform administrator with unrestricted access→ ADMIN in all projects
ADMINPlatform administrator→ ADMIN in all projects
FELLOWRecognized research fellow with elevated trust→ MAINTAINER in all projects
MEMBERStandard registered user (default)→ Based on membership

Project Roles

A user's effective project role is determined by the following priority:

  1. Global SUPER_ADMIN or ADMIN → ADMIN
  2. Global FELLOW → MAINTAINER
  3. Project creator → OWNER
  4. Explicit project membership → assigned role
  5. No membership → VIEWER (read-only)
RoleSettingsMembersWiki EditEffort CreateForum PostDelete Project
ADMIN✅✅✅✅✅✅
OWNER✅✅✅✅✅✅
MAINTAINER✅View only✅✅✅❌
CONTRIBUTOR❌❌✅✅✅❌
VIEWER❌❌❌❌❌❌

Project Action Matrix

Detailed permissions for each action within a project:

ActionRequired Role
View projectAnyone (public)
Access settings pageMAINTAINER+
Update project detailsMAINTAINER+
Manage members (add/remove/role change)ADMIN or OWNER
Archive projectMAINTAINER+
Delete projectADMIN or OWNER
Restore deleted projectADMIN or OWNER
Create wiki pageAuthenticated user
Edit wiki pageCONTRIBUTOR+
Delete wiki pageMAINTAINER+
Submit wiki for reviewCONTRIBUTOR+
Review/approve wiki versionMAINTAINER+
Create forum threadAuthenticated user
Delete forum threadMAINTAINER+ or author
Pin/lock/unlock threadMAINTAINER+
Move thread to another projectADMIN or OWNER
Create forum postAuthenticated user
Edit/delete forum postMAINTAINER+ or author
Create workspace effortAuthenticated user
Update workspace effortCONTRIBUTOR+
Delete workspace effortMAINTAINER+ or author
Manage effort typesMAINTAINER+

Program Roles

Programs use a separate role hierarchy. The effective role is determined by:

  1. Global SUPER_ADMIN / ADMIN → full access
  2. Global FELLOW → curator-level access
  3. Program creator → creator (highest program role)
  4. Explicit program membership → assigned role
  5. No membership → read-only
RoleSettingsMembersLink ProjectsWiki EditDelete Program
creator✅✅✅✅✅
curator✅✅✅✅❌
contributor❌❌❌✅❌
viewer❌❌❌❌❌

Program Action Matrix

ActionRequired Role
View programAnyone (public)
Access settings pagecurator+ or global ADMIN/FELLOW
Update program detailscurator+
Manage memberscreator or global ADMIN
Link/unlink projectscurator+
Create program wiki pagecontributor+
Edit program wiki pagecontributor+ (not viewer)
Delete programcreator or global ADMIN
Delete program + all descendantscreator or global ADMIN

Backend Enforcement

All write operations are enforced server-side using tRPC middleware:

  • protectedProcedure — Requires authentication. All mutations use this middleware, which rejects unauthenticated requests with a 401 UNAUTHORIZED error and enforces rate limiting (60 mutations/min per user).
  • Role checks— After authentication, each mutation verifies the user's role using getUserProjectRole() for projects or program membership queries. Insufficient permissions return a 403 FORBIDDEN error.

Frontend Guards

The frontend enforces permissions at two levels:

  • Page-level guards — Settings pages check authentication and role before rendering. Unauthenticated users see a sign-in prompt; insufficient roles see an access denied message.
  • Action-level guards — Buttons and forms (edit, delete, create) are conditionally rendered based on isAuthenticated and role checks. For example, the delete button only appears for ADMIN/OWNER roles.

Permission Helper Functions

The codebase provides utility functions in src/lib/permissions.ts:

FunctionReturns true for
getUserProjectRole()Computes effective ProjectRole from global role, creator status, and membership
canDeleteProject(role)ADMIN, OWNER
canRestoreProject(role)ADMIN, OWNER
canManageMembers(role)ADMIN, OWNER
isMaintainerOrAbove(role)ADMIN, OWNER, MAINTAINER
isContributorOrAbove(role)ADMIN, OWNER, MAINTAINER, CONTRIBUTOR
canDeleteThread(role, isAuthor)ADMIN, OWNER, MAINTAINER, or author
canDeleteWorkspaceEffort(role, isAuthor)ADMIN, OWNER, MAINTAINER, or author
PreviousSettings