Custom Permissions

Permissions control what org members can do within a feature. Define them in config/custom.php and they automatically appear in the admin panel for role assignment.

Registering Permissions

Add permission strings to the permissions array in config/custom.php:

// config/custom.php

'permissions' => [
    'view_projects',
    'create_projects',
    'update_projects',
    'delete_projects',
],

Where Permissions Appear

Registered permissions show up in Admin → Org Roles → Edit Role. Admins can assign each permission to specific org roles (e.g., give "Member" only view_projects, while "Admin" gets all four).

Checking Permissions in Routes

Use the org.can middleware on your routes:

// routes/custom.php

Route::get('/projects', [ProjectController::class, 'index'])
    ->middleware('org.can:view_projects');

Route::post('/projects', [ProjectController::class, 'store'])
    ->middleware('org.can:create_projects');

Route::delete('/projects/{project}', [ProjectController::class, 'destroy'])
    ->middleware('org.can:delete_projects');

If the user's org role does not have the required permission, the middleware returns a 403 response.

Checking Permissions in Code

You can also check permissions programmatically:

$orgRole = $request->user()->orgRoleFor($org);

if ($orgRole->hasPermission('delete_projects')) {
    // user can delete projects
}

Owner Bypass

Organization owners always pass permission checks. You do not need to special-case owners in your code — the permission system handles it automatically.

Frontend Permission Checks

Permissions are also enforced on the frontend. Both custom/navItems.ts and custom/routes.tsx support a permission property that hides UI elements from users who lack the required permission.