[GH-ISSUE #342] Role-Based Access Control (RBAC) for Team Members #222

New issue

Closed

opened 2026-03-03 11:14:08 +03:00 by kerem · 1 comment

kerem commented

2026-03-03 11:14:08 +03:00

Owner

Originally created by @jagadeesh507 on GitHub (Jul 14, 2025).
Original GitHub issue: https://github.com/dflow-sh/dflow/issues/342

Originally assigned to: @jagadeesh507 on GitHub.

✨ Feature Request: Role-Based Access Control (RBAC) for Team Members

Description

Introduce Role-Based Access Control (RBAC) to allow workspace admins to manage access permissions for team members.
Admins should be able to create custom roles from the dashboard, assigning specific permissions (create, read, update, delete) across various resource types such as:

Projects
Services
Servers
Secrets
...and more.

💡 Motivation

Improve security and control within teams by restricting access to only what's necessary.
Prevent accidental modification or deletion of critical resources.

✅ Expected Behavior

Admins can create custom roles in the dashboard.
For each role, admins can define granular permissions for each collection/resource (CRUD).
When inviting a team member, an admin can assign role.
UI and API should respect the assigned permissions when rendering options or performing actions.

📌 Notes

Consider starting with predefined roles: Admin, Developer, Viewer, and allowing custom roles afterward.

Originally created by @jagadeesh507 on GitHub (Jul 14, 2025). Original GitHub issue: https://github.com/dflow-sh/dflow/issues/342 Originally assigned to: @jagadeesh507 on GitHub. ### ✨ Feature Request: Role-Based Access Control (RBAC) for Team Members #### Description Introduce **Role-Based Access Control (RBAC)** to allow workspace admins to manage access permissions for team members. Admins should be able to create custom roles from the dashboard, assigning specific permissions (create, read, update, delete) across various resource types such as: - Projects - Services - Servers - Secrets ...and more. --- #### 💡 Motivation - Improve security and control within teams by restricting access to only what's necessary. - Prevent accidental modification or deletion of critical resources. --- #### ✅ Expected Behavior - Admins can create custom roles in the dashboard. - For each role, admins can define granular permissions for each collection/resource (CRUD). - When inviting a team member, an admin can assign role. - UI and API should respect the assigned permissions when rendering options or performing actions. --- #### 📌 Notes - Consider starting with predefined roles: **Admin**, **Developer**, **Viewer**, and allowing custom roles afterward.

kerem

2026-03-03 11:14:08 +03:00

closed this issue
added the
enhancement

frontend

feature

backend
labels

kerem commented

2026-03-03 11:14:09 +03:00

Author

Owner

@jagadeesh507 commented on GitHub (Jul 25, 2025):

✨ New Feature: Role-Based Access Control (RBAC) for Team Members

We’ve implemented Role-Based Access Control (RBAC) to enhance how workspace admins manage team permissions. This feature brings fine-grained access control across all collections and actions within the platform.

🔑 Key Features

Create Custom Roles
- Workspace admins can now create new roles from the dashboard, defining specific access levels for team members.
Update Role Permissions
- Existing roles can be updated at any time to modify their associated permissions.
Assign Roles to Team Members
- Admins can change a team member’s role or assign a new role during invitation or later through the team settings.
Granular Collection Permissions
- For each role, admins can define CRUD (Create, Read, Update, Delete) permissions across all collections.
- Admins have flexibility to choose which collections should be accessible and specify the allowed actions for each.
Enforced Action Restrictions with Feedback
- Team members attempting unauthorized actions will receive a toast error message saying "Access Denied".
- This prevents updates or deletions on entries where the assigned role lacks necessary permissions.
Role-Based Access Control on Actions using next-safe-actions
- All server-side actions are protected by next-safe-actions.
- Actions will check the user's assigned role before executing and deny access if the permissions do not match.
Role Validation through protectedClient
- The protectedClient wrapper enforces role checks automatically.
- Unauthorized access attempts trigger a role mismatch error before the action is performed.

⚙️ Example: Action Role Configuration

export const createTemplateAction = protectedClient
  .metadata({
    // This action name is used for tracking (e.g., Sentry)
    actionName: 'createTemplateAction',
  })
  .schema(createTemplateSchema)
  .action(async ({ clientInput, ctx }) => {
    const { userTenant, payload } = ctx
    const { name, description, services, imageUrl } = clientInput

    const response = await payload.create({
      collection: 'templates',
      data: {
        name,
        description,
        services,
        imageUrl,
        tenant: userTenant.tenant,
      },
    })
    return response
  })

To enforce RBAC on this action, configure the required role permission in your role-permission mapping:

createTemplateAction: ['templates.create']

This means the createTemplateAction requires create permission on the templates collection.
If a team member does not have this permission, the system will:
- Show a toast notification saying "Access Denied: missing permission(s) for templates.create".

@jagadeesh507 commented on GitHub (Jul 25, 2025): ## ✨ New Feature: Role-Based Access Control (RBAC) for Team Members We’ve implemented **Role-Based Access Control (RBAC)** to enhance how workspace admins manage team permissions. This feature brings fine-grained access control across all collections and actions within the platform. --- ### 🔑 Key Features 1. **Create Custom Roles** - Workspace admins can now create new roles from the dashboard, defining specific access levels for team members. 2. **Update Role Permissions** - Existing roles can be updated at any time to modify their associated permissions. 3. **Assign Roles to Team Members** - Admins can change a team member’s role or assign a new role during invitation or later through the team settings. 4. **Granular Collection Permissions** - For each role, admins can define **CRUD (Create, Read, Update, Delete)** permissions across all collections. - Admins have flexibility to choose which collections should be accessible and specify the allowed actions for each. 5. **Enforced Action Restrictions with Feedback** - Team members attempting unauthorized actions will receive a **toast error message** saying **"Access Denied"**. - This prevents updates or deletions on entries where the assigned role lacks necessary permissions. 6. **Role-Based Access Control on Actions using `next-safe-actions`** - All server-side actions are protected by **next-safe-actions**. - Actions will check the user's assigned role before executing and deny access if the permissions do not match. 7. **Role Validation through `protectedClient`** - The `protectedClient` wrapper enforces role checks automatically. - Unauthorized access attempts trigger a role mismatch error before the action is performed. --- ### ⚙️ Example: Action Role Configuration ```ts export const createTemplateAction = protectedClient .metadata({ // This action name is used for tracking (e.g., Sentry) actionName: 'createTemplateAction', }) .schema(createTemplateSchema) .action(async ({ clientInput, ctx }) => { const { userTenant, payload } = ctx const { name, description, services, imageUrl } = clientInput const response = await payload.create({ collection: 'templates', data: { name, description, services, imageUrl, tenant: userTenant.tenant, }, }) return response }) ``` **To enforce RBAC on this action, configure the required role permission in your role-permission mapping:** ```ts createTemplateAction: ['templates.create'] ``` * This means the `createTemplateAction` requires **create** permission on the **templates** collection. * If a team member does not have this permission, the system will: * Show a **toast notification** saying **"Access Denied: missing permission(s) for templates.create"**.