-
-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: custom root roles #3975
feat: custom root roles #3975
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
83d59c3
to
f3e6c18
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WIP some comments
interface IRole { | ||
id: number; | ||
name: string; | ||
project: string | null; | ||
description: string; | ||
type: string; | ||
permissions?: IPermission[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I'd add a new interface extending IRole, something like:
interface IRoleWithPermissions extends IRole {
permissions: IPermission[];
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good enough to merge and test. There's a couple of minor things but I don't think they're blockers
<Route path="project-roles/new" element={<CreateProjectRole />} /> | ||
<Route | ||
path="project-roles/:id/edit" | ||
element={<EditProjectRole />} | ||
/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should keep the same URL as before for project roles or just add a new one for root-roles? I see pros and cons with both approaches, the main concern is that we are changing the meaning of the existing resource (but this is not on the API level, so this should be fine)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the goal is to eventually merge both root roles and project roles on the same tab, I don't think we should prioritize this for now.
const allChecked = rootPermissions.every( | ||
(permission: IPermission) => checkedPermissionsCopy[permission.id] | ||
); | ||
|
||
if (allChecked) { | ||
rootPermissions.forEach((permission: IPermission) => { | ||
delete checkedPermissionsCopy[permission.id]; | ||
}); | ||
} else { | ||
rootPermissions.forEach((permission: IPermission) => { | ||
checkedPermissionsCopy[permission.id] = { | ||
...permission, | ||
}; | ||
}); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a refactoring opportunity as this code is repeated in a couple of places
const baseRole = { | ||
...(await this.validateRole(role)), | ||
roleType: CUSTOM_ROLE_TYPE, | ||
roleType, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note for the reviewers CUSTOM_PROJECT_ROLE_TYPE has currently the same value as CUSTOM_ROLE_TYPE had
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
https://linear.app/unleash/issue/2-1135/address-3975-pr-comments-by-refactoring-some-of-the-new-custom-root This pull request addresses the majority of the comments raised in issue #3975 and lays the groundwork for unifying roles. The idea is for project roles to also be managed in the "Roles" tab, and several components, such as `RoleForm` and the `useRoleForm` can potentially be reused. I'll leave the further investigation and implementation of unifying roles to be addressed in a separate task. As a mostly unrelated UI fix, this also adds an arrow to the tooltip in the `RoleBadge` component.
About the changes
Implements custom root roles, encompassing a lot of different areas of the project, and slightly refactoring the current roles logic. It includes quite a clean up.
This feature itself is behind a flag:
customRootRoles
This feature covers root roles in:
Apologies in advance. I may have gotten a bit carried away 🙈
Roles
We now have a new admin tab called "Roles" where we can see all root roles and manage custom ones. We are not allowed to edit or remove predefined roles.
This meant slightly pushing away the existing roles to
project-roles
instead. One idea we want to explore in the future is to unify both types of roles in the UI instead of having 2 separate tabs. This includes modernizing project roles to fit more into our current design and decisions.Hovering the permissions cell expands detailed information about the role:
Create and edit role
Here's how the role form looks like (create / edit):
Here I categorized permissions so it's easier to visualize and manage from a UX perspective.
I'm using the same endpoint as before. I tried to unify the logic and get rid of the
projectRole
specific hooks. What distinguishes custom root roles from custom project roles is the extraroot-custom
type we see on the payload. By default we assumecustom
(custom project role) instead, which should help in terms of backwards compatibility.Delete role
When we delete a custom role we try to help the end user make an informed decision by listing all the entities which currently use this custom root role:
As mentioned in the screenshot, when deleting a custom role, we demote all entities associated with it to the predefinedViewer
role.EDIT: Apparently we currently block this from the API (access-service deleteRole) with a message:
What should the correct behavior be?
Role selector
I added a new easy-to-use role selector component that is present in:
Role description
I also added a new role description component that you can see below the dropdown in the selector component, but it's also used to better describe each role in the respective tables:
I'm not listing all the permissions of predefined roles. Those simply show the description in the tooltip:
Role badge
Groups is a bit different, since it uses a list of cards, so I added yet another component - Role badge:
I'm using this same component on the profile tab:
Discussion points
ADMIN
;useRoles
) explicitly;