mirror of
https://github.com/Unleash/unleash.git
synced 2024-12-22 19:07:54 +01:00
0b3ed79ecc
https://linear.app/unleash/issue/2-1171/refactor-custom-root-roles-with-correct-plan-assumptions This cleans up the hotfix `RoleSelect2` component and makes `RoleSelect` take in a `roles` prop from the parent component. This also simplifies the role hooks again to assume Enterprise plan by default. This means, however, that we must ensure that we only call these hooks in Enterprise features or, if we do call them in other plans, that we provide a graceful fallback for non-Enterprise. Non-Enterprise instances do not have this endpoint, and so they are currently grabbing role information from e.g. `useUsers` and `useServiceAccounts`. I'm not sure how I feel about this. Roles are an overarching concept of Unleash. To me, having to be extremely conscious about the exact scenario in which you're using such a hook feels like a trap, instead of "I need roles, so I'll grab the `useRoles` hook and not think much about it". I also don't like the way `roles` are currently tied to the users, service accounts, project access, (...) instead of being its own thing. This could be solved by a `RoleController` exposing the GET endpoints in OSS, since all of the logic we need for this use-case lives there anyways. This would then be overridden with the Enterprise-specific controller when wrapped. This way we could assume the endpoint is always there, no matter the plan. This is just an idea and not something I explored in the PR. For now I'm just focusing on leaving this feature in a sane state. Tested this manually on `Pro` and `Enterprise` and I believe everything is acting the way we intend, but would love some extra eyes. |
||
|---|---|---|
| .. | ||
| __mocks__ | ||
| assets | ||
| component | ||
| constants | ||
| contexts | ||
| hooks | ||
| interfaces | ||
| openapi | ||
| themes | ||
| types | ||
| utils | ||
| index.tsx | ||
| setupTests.ts | ||
| vite-env.d.ts | ||