You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: reorganize users and groups documentation (#822)
- Move Users and Groups content from data-model.mdx to user-groups.mdx
- Rename user-groups.mdx title from "User Groups" to "Users and Groups"
- Add Service Account section explaining their purpose
- Consolidate and simplify constraints about service accounts in groups
- Convert constraints to Note component for better visibility
- Rename Role section to IAM and link both Users/Groups and Roles/Permissions
- Reorder navigation to show Users and Groups before Roles and Permissions
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <[email protected]>
Copy file name to clipboardExpand all lines: mintlify/administration/custom-approval.mdx
+55-16Lines changed: 55 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,31 +9,70 @@ feature_name: CUSTOM_APPROVAL
9
9
10
10
<iframewidth="675"height="380"src="https://www.youtube.com/embed/K_RWlqdplZQ"title="YouTube video player"className="w-full"frameBorder="0"allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"allowfullscreen="allowFullScreen"></iframe>
11
11
12
-
<Tip>
12
+
## Overview
13
13
14
-
- Custom Approval is mostly used by [UI workflow](/change-database/change-workflow/#ui-workflow). If you use [GitOps workflow](/change-database/change-workflow/#gitops-workflow), we recommend you to configure approval in the PR/MR process.
15
-
- By default, you **can not** self-approve your own created issue even if you are a qualified approver. You
16
-
can [toggle](/change-database/issue/#self-approval) this behavior under project settings.
14
+
Custom Approval allows you to create multi-stage approval workflows based on change risk levels. Each database change can require approvals from specific roles before proceeding to rollout.
17
15
16
+
<Tip>
17
+
**Best Practices:**
18
+
- Custom Approval works best with [UI workflow](/change-database/change-workflow/#ui-workflow). For [GitOps workflow](/change-database/change-workflow/#gitops-workflow), configure approvals in your PR/MR process instead.
19
+
- By default, users cannot self-approve their own issues. You can [change this setting](/change-database/issue/#self-approval) in project settings if needed.
18
20
</Tip>
19
21
20
-
In **Settings > Custom Approval**, you can choose which approval flow to use for a [risk level](/administration/risk-center) and define approval flows.
22
+
## How It Works
23
+
24
+
### Approval Flow Structure
25
+
26
+
An approval flow consists of one or more **approval nodes** arranged in sequence:
27
+
- Each node specifies a role (e.g., `Project Owner`, `DBA`, or custom role)
28
+
- Any member with that role can approve the node
29
+
- All nodes must be approved before the issue proceeds to rollout
21
30
22
-
An approval flow can contain one or multiple approval nodes. Each approval node specifies a role. Any member
23
-
of the role can approve that node. An issue will enter the rollout stage once all nodes have been approved.
24
-
Note, depending on how the [rollout policy](/administration/environment-policy/rollout-policy/) is configured,
25
-
it may still require another step to deploy the change manually.
31
+
<Note>
32
+
After approval, the actual deployment may still require manual action depending on your [rollout policy](/administration/environment-policy/rollout-policy/) configuration.
Copy file name to clipboardExpand all lines: mintlify/administration/roles.mdx
+72-30Lines changed: 72 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,49 +1,92 @@
1
1
---
2
2
title: Roles and Permissions
3
+
feature_name: CUSTOM_ROLES
3
4
---
4
5
5
6
<Cardtitle="Tutorial: How to Manage Roles"icon="graduation-cap"href="/tutorials/how-to-manage-roles"horizontal />
6
7
7
8
## Overview
8
9
9
-
Bytebase employs RBAC (Role-Based-Access-Control). Permissions are assigned to roles and roles are
10
-
granted to the users and groups.
10
+
Bytebase uses RBAC (Role-Based Access Control) to manage permissions. A **role** is a collection of permissions that can be granted to users and user groups.
Organizations can create custom roles with specific permission sets tailored to their needs. Custom roles are defined at the workspace level and can be granted at both workspace and project levels.
28
41
29
-
To grant users a project role for all the projects, grant that project role at the workspace level.
42
+
### Granting Roles
30
43
44
+
Roles are granted through IAM policies at two levels:
45
+
46
+
1.**Workspace IAM Policy** (Workspace > Members page)
47
+
- Grant roles that apply across all projects
48
+
- Manage workspace-level permissions
49
+
50
+
2.**Project IAM Policy** (Project > Members page)
51
+
- Grant roles for specific project resources
52
+
- Inherits roles granted at the workspace level
53
+
54
+
<Tip>
55
+
**Inheritance:** Project IAM policies automatically inherit roles granted at the workspace level. For example, if a user is granted `Project Developer` at the workspace level, they have that role in all projects.
Above diagram describes the mapping between an engineering org and the corresponding roles in the Bytebase workspace. Note, a particular user can be assigned multiple roles as well:
Use **Import from role** to start with an existing role's permissions and modify them as needed.
69
+
70
+
<Tip>
71
+
**Example:** To create a role that can approve and comment on issues but not execute them, create a `Project Approver` role by importing from `Project Releaser` and removing execution permissions.
72
+
</Tip>
73
+
74
+
## Granting Roles in IAM Policy
75
+
76
+
Roles (both built-in and custom) can be assigned to users and groups through the Members page at either workspace or project level:
36
77
37
-
- A user can only be assigned multiple workspace roles.
38
-
- In a particular project, a user can be assigned multiple project roles. A user can also be assigned different project roles in the different projects.
78
+
1. Navigate to **Members** page (either in Workspace or specific Project)
79
+
2. Click **Grant Access** to add users or groups
80
+
3. Select the appropriate roles to grant
81
+
4. Confirm to apply the IAM policy changes
39
82
40
-
Real-world scenarios:
83
+
When roles are granted at the workspace level, they automatically apply to all projects. Project-level grants only affect the specific project.
41
84
42
-
- Organizations may not establish a dedicated DBA or platform engineering group. In such case, usaually the application engineering group head and the tech leads will wear those hats. Say a user named Alice can be a `Workspace DBA` and a `Project Owner` for Project Apollo at the same time.
- An application developer could be involved in multiple projects. In such case, that engineer would also be assigned project roles in different projects respectively. Say a user named Bob can be a `Workspace Member`, a `Project Owner` for Project Apollo and a `Project Developer` for Project Mars at the same time.
87
+
## Appendix
45
88
46
-
## Workspace roles
89
+
###Workspace Role Permissions
47
90
48
91
By default, the first registered user is granted the `Admin` role, all following registered users are granted `Member` role. `Admin` can update any user's role later.
49
92
@@ -84,10 +127,9 @@ By default, the first registered user is granted the `Admin` role, all following
84
127
| Manage IM integration ||| ✔️ |
85
128
| Change logo ||| ✔️ |
86
129
87
-
## Project roles
130
+
###Project Role Permissions
88
131
89
-
Any user can create project. By default, the project creator is granted the `Project Owner` role.
90
-
`Workspace DBA` and `Workspace Admin` assume the `Project Owner` role for all projects.
132
+
Any user can create project. By default, the project creator is granted the `Project Owner` role. `Workspace DBA` and `Workspace Admin` assume the `Project Owner` role for all projects.
Bytebase does not define database specific roles. Whether a user can perform certain action to the database is based on the user's Workspace role and the role of the project owning the database.
102
144
@@ -107,15 +149,15 @@ Bytebase does not define database specific roles. Whether a user can perform cer
107
149
| Edit database label |||| ✔️ | ✔️ | ✔️ |
108
150
| Transfer database |||| ✔️ | ✔️ | ✔️ |
109
151
110
-
## Sheet permissions
152
+
###Sheet Permissions
111
153
112
154
User can save sheets from [SQL Editor](/sql-editor/overview). A sheet always belongs to a project. Sheet has three visibility levels:
\*`Project Owner` can change issue status when the current active [Environment Rollout Policy](/administration/environment-policy/rollout-policy) is set to **Require manual rolling out**.
198
+
\*`Project Owner` can change issue status when the current active [Environment Rollout Policy](/administration/environment-policy/rollout-policy) is set to **Require manual rolling out**.
Copy file name to clipboardExpand all lines: mintlify/administration/user-groups.mdx
+15-12Lines changed: 15 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,24 @@
1
1
---
2
-
title: User Groups
2
+
title: Users and Groups
3
3
feature_name: USER_GROUPS
4
4
---
5
5
6
-
`User Group` or simply `Group` contains a set of users. `Group` simplifies access management as you can grant
7
-
roles to a `Group` instead of granting to the individual users one by one.
6
+
## User
8
7
9
-
## Constraints
8
+
A `User` represents anyone who can access and perform operations in Bytebase. Users include both human team members and service accounts.
10
9
11
-
- Bytebase does not support nested group. A group can only contain users, it can't contain another group.
12
-
- You can only add normal user account to the group and can not add service account. Service account within a group is an [anti-pattern](https://cloud.google.com/iam/docs/best-practices-service-accounts#groups).
10
+
## Service Account
11
+
12
+
Service accounts are special users designed for automated processes and applications.
13
+
14
+
## User Group
15
+
16
+
A `User Group` organizes multiple users together for easier permission management. Workspace admins create groups and add users, then assign these groups to roles within projects.
17
+
18
+
<Note>
19
+
- Bytebase does not support nested groups. A group can only contain users, it can't contain another group.
20
+
- Service accounts cannot be part of user groups. Since service accounts are for automated processes with specific access needs, including them in groups could grant unintended permissions. This is considered an [anti-pattern](https://cloud.google.com/iam/docs/best-practices-service-accounts#groups).
21
+
</Note>
13
22
14
23
## Add group
15
24
@@ -48,9 +57,3 @@ Now you can see the `Contractor Group` under **View by members** page as well as
All members within this group now share permission to the project.
51
-
52
-
## Service account
53
-
54
-
You can only add normal user account to the group and can not add service account.
55
-
56
-
Service accounts are designed for application use, with each application typically having unique access needs. Since applications rarely perform identical functions, their required resource access tends to differ, making shared or identical permissions uncommon.
0 commit comments