Roles and Permissions¶

PrimeThink uses a role-based access control (RBAC) system to manage what users can do within a group. Each user in a group can be assigned a role, and each role grants a set of permissions that control access to features and actions.

How It Works¶

1. A Group Admin assigns a role to each user in the group.
2. Each role carries a set of permissions that determine what the user can access.
3. Permissions are checked at runtime — if a user lacks the required permission, the action is denied with an HTTP 403 error.

Roles¶

A role is a named collection of permissions. Roles can be system roles (built-in to the platform) or custom roles created by a Group Admin.

Each role has the following properties:

Per-Task Role Access¶

A task can grant access to one or more roles in addition to its normal owner and task-type rules. A user whose current group role is assigned to the task:

• Sees the task in task lists for that group
• Can open the task even when they are not its owner
• Passes task checks that normally require owner-level access

This assignment does not change the user's role or add permissions to that role globally. It applies only to the selected task, and task responses expose the assignment as an assigned_roles list containing each role's id and name.

Removing a role from the task revokes this additional path for every user with that role. Clearing the assignment list restores the task's normal owner and task-type access rules.

For API-based assignment, see Assign Roles to a Task.

Permission Scopes¶

Each permission has a scope that determines where it applies and who can assign it.

Permissions Reference¶

Permissions are organized into categories. Each permission has an ID (used in code and returned by pt.getUserRole()), a human-readable name, a scope, and optional dependencies (permissions that must also be granted).

administration¶

agents¶

api_access¶

chat_sidebar¶

chats¶

collaboration¶

collections¶

documents¶

group¶

group_variables¶

live_apps¶

llm¶

Permissions related to LLM and agent execution behavior.

memory¶

notifications¶

roles¶

scheduled_jobs¶

tasks¶

users¶

workspaces¶

Enforcement¶

Permission checks are enforced at runtime before the requested action is executed. When a user lacks the required permission, the platform returns an HTTP 403 response with a descriptive error message.

Examples of enforcement behavior:

Checking Permissions in Live Apps¶

Use pt.getUserRole() to retrieve the current user's role and permissions at runtime.

Response structure:

{
  role: {
    id: string,           // Role UUID
    name: string,         // Role display name (e.g. "Admin", "Editor")
    description: string,  // Role description
    is_system_role: bool  // true if this is a built-in platform role
  },
  permissions: string[]   // Array of permission IDs (e.g. ["download_documents", "invite_users"])
}

Returns null when the user is not logged in or has no role assigned.

Example — gate a feature based on permission:

const userRole = await pt.getUserRole();

if (userRole?.permissions.includes('call_llm')) {
    // User can trigger LLM actions
    enableAIFeatures();
} else {
    showMessage('You do not have permission to use AI features.');
}

Example — show admin-only UI:

const userRole = await pt.getUserRole();
const isAdmin = userRole?.role.name === 'Admin';

document.querySelectorAll('.admin-only').forEach(el => {
    el.style.display = isAdmin ? '' : 'none';
});

For full API details, see the pt.getUserRole() reference.