1
0
mirror of https://github.com/Unleash/unleash.git synced 2025-01-06 00:07:44 +01:00
Commit Graph

9 Commits

Author SHA1 Message Date
Tymoteusz Czech
ef495a35ee
Feature toggle types list (#4260)
## About the changes

![image](https://github.com/Unleash/unleash/assets/2625371/0f66333f-5ed9-4e44-b658-2e7c3606a2c3)
2023-07-18 13:46:06 +02:00
Nuno Góis
95a0c7748f
feat: upgrade AdminAlert to PermissionGuard (#4074)
https://linear.app/unleash/issue/2-1165/improve-adminalert-usage-to-be-more-generic-accept-non-admin

Upgrades our `AdminAlert` to a new `PermissionGuard`.

**Question**: We don't **need** to, but **should** we be specific about
the `ADMIN` permission every time?
Technically `PermissionGuard` could have `permissions` as optional and
assume `[]` by default, which will add `ADMIN` anyways. However, I feel
like we may gain some readability if we're specific about it. WDYT?

Single permission:

![image](https://github.com/Unleash/unleash/assets/14320932/eab414ae-e798-4ab6-ba96-cde2977dc98b)

Multiple permissions:

![image](https://github.com/Unleash/unleash/assets/14320932/25302442-8fcc-4aa1-9525-d54f5f9350af)
2023-06-23 13:25:35 +01:00
Nuno Góis
4163788bba
fix: update roles permission guard (#4070)
https://linear.app/unleash/issue/2-1162/read-roles-permissions-should-give-you-access-to-read-roles

This updates the roles page permission guard to be the `READ_ROLES`
permission instead of `ADMIN`, which better reflects on the UI the real
permissions of the user.

Our current `AdminAlert` component is pretty limited however, and I plan
to improve it in
https://linear.app/unleash/issue/2-1165/improve-adminalert-usage-to-be-more-generic-accept-non-admin
to better reflect the permission we're missing (instead of alerting that
you need to be an admin).
2023-06-22 14:43:26 +00:00
Nuno Góis
7e9069e390
refactor: token permissions, drop admin-like permissions (#4050)
https://linear.app/unleash/issue/2-1155/refactor-permissions

- Our `rbac-middleware` now supports multiple OR permissions;
- Drops non-specific permissions (e.g. CRUD API token permissions
without specifying the token type);
- Makes our permission descriptions consistent;
- Drops our higher-level permissions that basically mean ADMIN (e.g.
ADMIN token permissions) in favor of `ADMIN` permission in order to
avoid privilege escalations;

This PR may help with
https://linear.app/unleash/issue/2-1144/discover-potential-privilege-escalations
as it may prevent privilege escalations altogether.

There's some UI permission logic around this, but in the future
https://linear.app/unleash/issue/2-1156/adapt-api-tokens-creation-ui-to-new-permissions
could take it a bit further by adapting the creation of tokens as well.

---------

Co-authored-by: Gastón Fournier <gaston@getunleash.io>
2023-06-22 08:35:54 +01:00
Nuno Góis
a9e9ae8c3e
feat: use new role components in project access (#4018)
https://linear.app/unleash/issue/2-1143/adapt-project-roles-to-use-the-new-role-selector-and-role-description

This PR further unifies roles, by having a single `IRole` interface to
cover both types, and re-using the same components for project roles.
2023-06-21 08:16:37 +01:00
Nuno Góis
3a27f2a4bd
feat: implement better roles sub-tabs (#4009)
https://linear.app/unleash/issue/2-1145/improve-roles-sub-tabs

Improves UI/UX of the roles sub-tabs.

Some of the logic is a bit specific due to the feature flag, will be
nice to clean this up once we remove it.

Before:

![image](https://github.com/Unleash/unleash/assets/14320932/cc277920-557c-45a9-a560-6026167dab1d)

After:

![image](https://github.com/Unleash/unleash/assets/14320932/51d1b5b3-068a-4bf5-84ca-24fdf708f899)
2023-06-19 12:52:56 +01:00
Nuno Góis
eb8f16da8d
feat: roles unification (#3999)
https://linear.app/unleash/issue/2-1137/roles-unification-on-the-ui

Root and project roles should be managed in a similar manner, which
means using the same roles route and tab for both.

Additionally, this includes a big revamp to the project roles to align
them more closely with the modern and standardized custom root roles
that were recently developed. They mostly use the same components.

There are still more things we want to improve and unify, but we've left
some of that out of this PR due to PR size concerns.
2023-06-19 09:41:40 +01:00
Nuno Góis
58607f7f48
refactor: address custom root roles PR comments (#3994)
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.
2023-06-15 14:03:47 +01:00
Nuno Góis
bb026c0ba1
feat: custom root roles (#3975)
## 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:
 - Users;
 - Service Accounts;
 - Groups;

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.

![image](https://github.com/Unleash/unleash/assets/14320932/1ad8695c-8c3f-440d-ac32-39746720d588)
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:

![image](https://github.com/Unleash/unleash/assets/14320932/81c4aae7-8b4d-4cb4-92d1-8f1bc3ef1f2a)

### Create and edit role

Here's how the role form looks like (create / edit):

![image](https://github.com/Unleash/unleash/assets/14320932/85baec29-bb10-48c5-a207-b3e9a8de838a)
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 extra `root-custom` type we
see on the payload. By default we assume `custom` (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:

![image](https://github.com/Unleash/unleash/assets/14320932/352ed529-76be-47a8-88da-5e924fb191d4)
~~As mentioned in the screenshot, when deleting a custom role, we demote
all entities associated with it to the predefined `Viewer` role.~~
**EDIT**: Apparently we currently block this from the API
(access-service deleteRole) with a message:

![image](https://github.com/Unleash/unleash/assets/14320932/82a8e50f-8dc5-4c18-a2ba-54e2ae91b91c)
What should the correct behavior be?

### Role selector

I added a new easy-to-use role selector component that is present in:
 - Users 

![image](https://github.com/Unleash/unleash/assets/14320932/76953139-7fb6-437e-b3fa-ace1d9187674)
 - Service Accounts

![image](https://github.com/Unleash/unleash/assets/14320932/2b80bd55-9abb-4883-b715-15650ae752ea)
- Groups

![image](https://github.com/Unleash/unleash/assets/14320932/ab438f7c-2245-4779-b157-2da1689fe402)

### 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:

![image](https://github.com/Unleash/unleash/assets/14320932/a3eecac1-2a34-4500-a68c-e3f62ebfa782)

I'm not listing all the permissions of predefined roles. Those simply
show the description in the tooltip:

![image](https://github.com/Unleash/unleash/assets/14320932/7e5b2948-45f0-4472-8311-bf533409ba6c)

### Role badge

Groups is a bit different, since it uses a list of cards, so I added yet
another component - Role badge:

![image](https://github.com/Unleash/unleash/assets/14320932/1d62c3db-072a-4c97-b86f-1d8ebdd3523e)

I'm using this same component on the profile tab:

![image](https://github.com/Unleash/unleash/assets/14320932/214272db-a828-444e-8846-4f39b9456bc6)

## Discussion points
- Are we being defensive enough with the use of the flag? Should we
cover more?
 - Are we breaking backwards compatibility in any way?
 - What should we do when removing a role? Block or demote?
- Maybe some existing permission-related issues will surface with this
change: Are we being specific enough with our permissions? A lot of
places are simply checking for `ADMIN`;
- We may want to get rid of the API roles coupling we have with the
users and SAs and instead use the new hooks (e.g. `useRoles`)
explicitly;
 - We should update the docs;
- Maybe we could allow the user to add a custom role directly from the
role selector component;

---------

Co-authored-by: Gastón Fournier <gaston@getunleash.io>
2023-06-14 14:40:40 +01:00