@ -81,35 +81,4 @@ Access to bases within that workspace is granted to members based on their roles
| API Snippet | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| API Snippet | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| API Token | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| 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