For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to page URLs; this page is available as Markdown.

Permissions and roles

Roles

• admin – Full access to all sections, settings, user management, logs, and APIs that are restricted to admin.
• client (default) – Limited to what you assign: typically client dashboard, settings, and only the commissions/boards you assign. No access to admin-only pages unless you grant specific permissions.

Other role names can exist; the app typically treats “admin” as the superuser and everyone else as non-admin for “view all” logic (e.g. list of commissions, list of users).

Permissions object

Each user has a permissions field (JSON). It is a nested object that controls access to sections. Typical shape:

• payments – view, full (e.g. access to Admin / payments page and creating payment links).
• commissions – view, create, full (commission-admin list and create/edit/delete; commission client view is also gated by assigned commissions).
• calendar – view, full (todo/calendar page).
• lists – view, full (boards/list page); can be further limited by assigned boards.
• customers – view, full (customer management page).
• log – view (audit log page).
• hub – view, create, full (hub page).

If a user is admin, they bypass these checks and can access everything. For non-admins, the server checks both:

• Permission for that section (e.g. perms.commissions.view or perms.commissions.full for commission-admin), and/or
• Assignment (e.g. at least one assignedBoardIds for list, or at least one assignedCommissionIds for commission client view).

Assignments (restrict what a user sees)

• assignedBoardIds – Array of board IDs. The user can access those boards (and only those) on the Lists page, unless they are admin or have “view all” for lists.
• assignedCommissionIds – Array of commission IDs. The user can open the Commission (client) page and see only those commissions. The list API (GET /api/commissions) returns only commissions where the user is the client or the commission id is in assignedCommissionIds; admins get all.
• clientId on a commission – The “client” user for that commission; they can see it on the commission client view if they have access to commissions (by assignment or permission).

So: “give a client access to only one commission” = set assignedCommissionIds to [thatCommissionId] and do not grant commissions “view all” permission. The API already filters the list and single-commission access by assignment and clientId.

Page access summary

API endpoints mirror this: e.g. GET /api/commissions returns all only for admin; for others, only commissions where clientId = user or id in assignedCommissionIds. Same idea for boards and other resources.