docs: Access Manager Feature Documentation #95
Conversation
docs/user-guide/global-configurations/authorization/user-access.md
Outdated
Show resolved
Hide resolved
docs/user-guide/global-configurations/authorization/user-access.md
Outdated
Show resolved
Hide resolved
docs/user-guide/global-configurations/authorization/user-access.md
Outdated
Show resolved
Hide resolved
docs/user-guide/global-configurations/authorization/user-access.md
Outdated
Show resolved
Hide resolved
docs/user-guide/global-configurations/authorization/user-access.md
Outdated
Show resolved
Hide resolved
|
|
||
| The **Access Manager** toggle in the **Role** drop-down box is disabled by default. | ||
|
|
||
| When a Super-Admin creates a new user or edits the permissions of an existing user, if he enables the **Access Manager** toggle from the **Role** drop-down box but do not select any permissions, the system treats it as if the toggle were never enabled. In other words, enabling the toggle without assigning any permissions has no effect. Therefore, when enabling the **Access Manager** toggle, it is recommended to select at least one permission to ensure the role is active. |
There was a problem hiding this comment.
Since this is an extra information and also important for the user to notice, put it in a hintblock
There was a problem hiding this comment.
The wordings also seem over-explained...how the system treats the input is not the reader's concern, what is the reader supposed to know/supposed to do should be put forward, and in simple words (not a para)
Maybe go for: While you enable the 'Access Manager' toggle, make sure to select at least one permission from the checkboxes of permissions shown beneath the toggle
|
|
||
|  | ||
|
|
||
| Enabling this toggle, however, does not grant the user the ability to give another user the Access Manager role. For example, when a Super-Admin enables the **Can manage access for all roles** toggle for a user, then for that user, the **Access Manager** toggle will not be available in the **Role** drop-down box, thereby restricting the ability to create Access Managers to Super-Admin. |
There was a problem hiding this comment.
Repetition is there, pls check: ...restricting the ability to create Access Managers to Super-Admin here was already written in line 165: Creation of new users and Access Manager is restricted only to Super-Admins so remove it
There was a problem hiding this comment.
It seems we should reduce the usage of a para whenever it is possible. FYI, this doc is meant only for superadmins, so calling them by first person really helps reduce the confusion of who is superadmin, who is user, who am I.
Keep it in a hintblock and let's just simply put: If you enable **Can manage access for all roles** toggle for a user, that user won't get the option to further make another user an Access Manager
| 5. **Image approver**: These users can approve image deployment requests. | ||
| 6. **Configuration approver**: These users can approve configuration change requests for [Deployment Templates](../../creating-application/deployment-template.md), [ConfigMaps](../../creating-application/config-maps.md), and [Secrets](../../creating-application/secrets.md). However, users cannot self-approve their own proposed changes, even if they have this role or Super Admin access. | ||
| 7. **Artifact promoter**: These users have the authority to approve the promotion of [artifacts](../../../reference/glossary.md#artifacts) directly to the target CD pipeline. | ||
| When an Access Manager modifies and assigns the **Artifact Promoter** permission to an existing user, for example, then that user will only have **Artifact Promoter** permission selected and displayed in the **Role** drop-down box, whereas the other permissions, **Config Approver** and **Deployment approver**, will not be displayed. |
There was a problem hiding this comment.
Let this example clearly go in a hintblock. Reason: This information demands attention, but it is hindering the flow of doc if it is going in plain text.
|
|
||
| * **Additional Roles** [](https://devtron.ai/pricing) | ||
|
|
||
| **Additional Roles** is an enterprise feature that allows you to assign specific permissions to a user beyond their **Base Role**. For example, you can grant a user both the **Build and Deploy** (Base Role) and **Config Approver** permissions (Additional Role). This allows the user to build and deploy images, while also being responsible for approving configuration change requests. |
There was a problem hiding this comment.
Since we have added Enterprise tag above, let's not re-explain it below that it is an enterprise feature.
We don't want our OSS readers to feel pushed repeatedly...
|
|
||
|  | ||
|
|
||
| **Access Manager** is an enterprise feature that allows you to manage user permissions on a granular level. As an Access Manager, you can assign or revoke permissions of existing users within your granted scope. |
There was a problem hiding this comment.
Since we have added Enterprise tag in line 143, let's not re-explain that it is an enterprise feature.
Our OSS readers might feel pushed more often...
|
|
||
| **Access Manager** is an enterprise feature that allows you to manage user permissions on a granular level. As an Access Manager, you can assign or revoke permissions of existing users within your granted scope. | ||
|
|
||
| For example, when a Super-Admin creates an Access Manager and grants him **View only** access under **Base Role**, and **Admin**, **Config Approver** permissions under the **Access Manager** role, then the Access Manager will have **View only** access across Devtron and will not be able to perform any other operations. |
There was a problem hiding this comment.
...when a Super-Admin creates an Access Manager and grants him
...when you create an Access Manager and grant him
Remember, this doc is for a superadmin only, so calibrate the wordings according to FPP (first person) and not TPP
There was a problem hiding this comment.
Added few more inputs, @bharathvaj-p. FYI, anything in Global Configuration is a super-admin's job, so once the RBAC is clearly mentioned by us, we should prefer using first-person (you) rather than speaking in third person (super-admin) throughout the doc.
Sample Preview
Changes made: