diff --git a/packages/noco-docs/docs/085.data-source/010.data-source-overview.md b/packages/noco-docs/docs/085.data-source/010.data-source-overview.md index 5ab55545d1..6b62362c50 100644 --- a/packages/noco-docs/docs/085.data-source/010.data-source-overview.md +++ b/packages/noco-docs/docs/085.data-source/010.data-source-overview.md @@ -10,7 +10,9 @@ description: 'NocoDB Data-Source sync, access control & re-config' - UI Access Control - Relations -Note that, currently only one external data source can be added per project. +:::info +Currently only one external data source can be added per project. +::: ## Accessing Data Sources diff --git a/packages/noco-docs/docs/090.roles-and-permissions/010.overview.md b/packages/noco-docs/docs/090.roles-and-permissions/010.overview.md index 95e7562b51..6191162745 100644 --- a/packages/noco-docs/docs/090.roles-and-permissions/010.overview.md +++ b/packages/noco-docs/docs/090.roles-and-permissions/010.overview.md @@ -81,35 +81,4 @@ Access to bases within that workspace is granted to members based on their roles | 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. -