|
|
|
|
@ -0,0 +1,116 @@
|
|
|
|
|
--- |
|
|
|
|
title: 'Roles & Permissions overview' |
|
|
|
|
--- |
|
|
|
|
import Tabs from '@theme/Tabs'; |
|
|
|
|
import TabItem from '@theme/TabItem'; |
|
|
|
|
|
|
|
|
|
In NocoDB, we have roles that determine what people can do in a Workspace or Base. You can give a member one of these roles: Creator, Editor, Commenter, or Viewer. |
|
|
|
|
|
|
|
|
|
:::info |
|
|
|
|
Role for a member, if assigned at base level carry precedence over workspace level role. |
|
|
|
|
::: |
|
|
|
|
|
|
|
|
|
When inviting a user, their role designation is initially assigned but can be modified later. Our role system operates incrementally, with higher-level roles encompassing all privileges of lower-level roles. This hierarchy offers flexibility in permissions and fosters a transparent organizational structure in workspace or base management. |
|
|
|
|
|
|
|
|
|
## Roles |
|
|
|
|
Roles serve as the basis for user privileges in NocoDB. They are associated with members at two levels: Workspace and Base. When a member is invited to a Workspace with a specific role, like an "Editor," they automatically have that role in all Bases within that Workspace. However, project owners or creators can customize permissions at the project level to align with specific needs. This dual-level role assignment system ensures adaptable user permissions and access management in NocoDB. |
|
|
|
|
|
|
|
|
|
**Owner**: When a member creates a new Workspace or Base, they automatically become the Workspace or Base "Owner." This role grants exclusive privileges, including the authority to delete the Workspace or Base. The "Owner" role's privileges are non-transferable, ensuring ownership and control integrity. |
|
|
|
|
|
|
|
|
|
**Creator**: The "Creator" role shares all privileges with an "Owner," except for deleting the workspace or base. "Creators" have full administrative rights, except for deletion authority, which remains exclusive to the "Owner." This ensures balanced workspace or base management. |
|
|
|
|
|
|
|
|
|
**Editor**: An "Editor" can create and edit records but cannot modify the project schema, like adding tables or columns. They strike a balance between data input and schema management. |
|
|
|
|
|
|
|
|
|
**Commenter**: The "Commenter" role cannot add or edit records but can provide comments on existing records, facilitating communication and feedback. |
|
|
|
|
|
|
|
|
|
**Viewer**: "Viewers" can only access records and associated comments, without the ability to contribute or make changes, ensuring controlled access for informational purposes. |
|
|
|
|
|
|
|
|
|
**No Access**: This role, applied exclusively at the base level, revokes project access for the designated user, ensuring robust security and access management. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Workspace level permissions |
|
|
|
|
The individual who creates the workspace is automatically designated as a Workspace owner. A workspace can have only one Owner. |
|
|
|
|
Access to bases within that workspace is granted to members based on their roles within the parent workspace. When a member becomes part of a workspace, the role at the workspace level is automatically applied to them for all bases in that workspace, unless a specific exception is configured to override at base level. |
|
|
|
|
|
|
|
|
|
| Task | Owner | Creator | Editor | Commenter | Viewer | |
|
|
|
|
|-----------------------------------------|:-----:|:-------:|:------:|:---------:|:------:| |
|
|
|
|
| Invite member to workspace | ✔️ | ✔️ | | | | |
|
|
|
|
| Manage member access to workspace | ✔️ | ✔️ | | | | |
|
|
|
|
| Remove member access from workspace | ✔️ | ✔️ | | | | |
|
|
|
|
| View members in workspace | ✔️ | ✔️ | | | | |
|
|
|
|
| Delete Workspace | ✔️ | ️ | | | | |
|
|
|
|
| Billing & upgrade options | ✔️ | ️ | | | | |
|
|
|
|
| Create a new base | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
| Access existing bases at assigned roles | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Base level permissions |
|
|
|
|
|
|
|
|
|
#### Collaboration |
|
|
|
|
| Task | Owner | Creator | Editor | Commenter | Viewer | |
|
|
|
|
|----------------------------------------------|:-----:|:-------:|:------:|:---------:|:------:| |
|
|
|
|
| Invite members to base at or below your role | ✔️ | ✔️ | | | | |
|
|
|
|
| Manage members access to base | ✔️ | ✔️ | | | | |
|
|
|
|
| Remove member access from a base | ✔️ | ✔️ | | | | |
|
|
|
|
| View members in a base | ✔️ | ✔️ | | | | |
|
|
|
|
| Share base | ✔️ | ✔️ | | | | |
|
|
|
|
| Share view | ✔️ | ✔️ | | | | |
|
|
|
|
|
|
|
|
|
#### Table & view operations |
|
|
|
|
| Task | Owner | Creator | Editor | Commenter | Viewer | |
|
|
|
|
|---------------------------------|:-----:|:-------:|:------:|:---------:|:------:| |
|
|
|
|
| Add / modify / delete table | ✔️ | ✔️ | | | | |
|
|
|
|
| Add / modify / delete fields | ✔️ | ✔️ | | | | |
|
|
|
|
| Add / modify / delete views | ✔️ | ✔️ | | | | |
|
|
|
|
| Hide / un-hide / reorder fields | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
| Add / modify / delete sort | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
| Add / modify / delete filters | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
| Add / modify / delete group-by | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
|
|
|
|
|
#### Record operations |
|
|
|
|
| Task | Owner | Creator | Editor | Commenter | Viewer | |
|
|
|
|
|---------------------------------|:-----:|:-------:|:------:|:---------:|:------:| |
|
|
|
|
| Add / modify / delete record | ✔️ | ✔️ | | | | |
|
|
|
|
| View & add comment on a record | ✔️ | ✔️ | ✔️ | ✔️ | | |
|
|
|
|
| View record | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
|
|
|
|
|
#### Automations & advanced |
|
|
|
|
| Task | Owner | Creator | Editor | Commenter | Viewer | |
|
|
|
|
|---------------------------------|:-----:|:-------:|:------:|:---------:|:------:| |
|
|
|
|
| Add / modify / delete Webhook | ✔️ | ✔️ | | | | |
|
|
|
|
| ERD (Project & Table relations) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
| API Snippet | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
| API Token | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
|
|
|
|
|
|
|
|
|
## Related Links |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--------------- |
|
|
|
|
|
|
|
|
|
# Backup |
|
|
|
|
|
|
|
|
|
Upon extending an invitation to a user, the assigning of their role level is an initial step in the process, but it's important to note that this role designation can be modified at a later time. Our role system operates incrementally, meaning that higher-level roles inherently encompass all the privileges associated with lower-level roles. This hierarchical approach not only provides flexibility in tailoring permissions but also fosters a transparent and responsible organizational structure within the framework of workspace or base management. |
|
|
|
|
|
|
|
|
|
## Roles |
|
|
|
|
|
|
|
|
|
Roles serve as the defining factor for the privileges assigned to users within NocoDB. These roles can be associated with a member at two distinct levels: the Workspace level and the Base level. When a member is invited to a Workspace and granted a specific role, such as an "Editor," they will inherently carry that privilege across all the Bases within that particular Workspace by default. However, it's essential to note that project owners or creators maintain the authority to enforce customized permission settings at the project level, allowing for the fine-tuning of access and control as needed to align with specific project requirements. This dual-level role assignment system ensures a flexible and adaptable approach to user permissions and access management within NocoDB. |
|
|
|
|
|
|
|
|
|
### Owner |
|
|
|
|
When a member initiates the creation of a new Workspace or Base within our system, they are automatically designated as the Workspace or Base "Owner." This ownership role comes with certain exclusive privileges, including the sole authority to delete the Workspace or Base. It is important to note that the "Owner" role's privileges are non-transferable, ensuring the integrity of ownership and control within the system. |
|
|
|
|
|
|
|
|
|
### Creator |
|
|
|
|
The role of "Creator" within our system encompasses all the privileges associated with a Workspace or Base "Owner," except the ability to delete the workspace or base. In essence, a "Creator" possesses the full spectrum of administrative rights and control over the workspace or base, except for the authority to initiate its deletion. This distinction ensures that while "Creators" can oversee and manage various aspects of the workspace or base, the critical decision to remove it remains exclusive to the designated "Owner." This arrangement allows for a balanced and secure approach to workspace or base management. |
|
|
|
|
|
|
|
|
|
### Editor |
|
|
|
|
The role of an "Editor" comes with specific limitations and permissions. An "Editor" does not have the capability to make alterations to the project schema, such as adding tables, views or columns. However, they are empowered to create and edit records within the project. This role is designed to strike a balance between data input and schema management, ensuring that while "Editors" can contribute and modify content, the structural integrity of the project remains protected and controlled by higher-level roles. |
|
|
|
|
|
|
|
|
|
### Commenter |
|
|
|
|
The "Commenter" role is characterized by its distinct set of permissions. Specifically, a "Commenter" does not possess the ability to add or edit records within the designated context. However, their role is centered on the capability to provide comments on existing records. This role is purposefully designed to facilitate communication and feedback while maintaining a clear distinction from roles responsible for record creation and modification. |
|
|
|
|
|
|
|
|
|
### Viewer |
|
|
|
|
The role of a "Viewer" is defined by a specific set of permissions. In this capacity, individuals with the "Viewer" role are granted access solely for the purpose of viewing records and associated comments. This role is intentionally limited to passive observation and does not include the ability to contribute or make changes, ensuring a secure and controlled environment for those who require access solely for informational purposes. |
|
|
|
|
|
|
|
|
|
### No Access |
|
|
|
|
The "No Access" role is a distinctive designation within NocoDB, and it is exclusively applied at the base level. This role serves the specific purpose of revoking project access for the designated user at that particular base. By assigning the "No Access" role, access to the associated project is effectively denied, providing a clear and effective means of controlling user permissions and project participation. This role plays a crucial role in ensuring security and access management within the system. |
|
|
|
|
|
|
|
|
|
|
Raju Udava
1 year ago
