1
0
mirror of https://github.com/Unleash/unleash.git synced 2025-01-06 00:07:44 +01:00
unleash.unleash/src/lib/services/access-service.test.ts

269 lines
8.2 KiB
TypeScript
Raw Normal View History

import NameExistsError from '../error/name-exists-error';
import getLogger from '../../test/fixtures/no-logger';
import { createFakeAccessService } from '../features/access/createAccessService';
import {
AccessService,
IRoleCreation,
IRoleValidation,
} from './access-service';
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 15:40:40 +02:00
import { createTestConfig } from '../../test/config/test-config';
import { CUSTOM_ROOT_ROLE_TYPE } from '../util/constants';
import FakeGroupStore from '../../test/fixtures/fake-group-store';
import { FakeAccountStore } from '../../test/fixtures/fake-account-store';
import FakeRoleStore from '../../test/fixtures/fake-role-store';
import FakeEnvironmentStore from '../../test/fixtures/fake-environment-store';
import AccessStoreMock from '../../test/fixtures/fake-access-store';
import { GroupService } from '../services/group-service';
import FakeEventStore from '../../test/fixtures/fake-event-store';
import { IRole } from '../../lib/types/stores/access-store';
import { IGroup, ROLE_CREATED } from '../../lib/types';
import EventService from './event-service';
import FakeFeatureTagStore from '../../test/fixtures/fake-feature-tag-store';
function getSetup(customRootRolesKillSwitch: boolean = true) {
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 15:40:40 +02:00
const config = createTestConfig({
getLogger,
experimental: {
flags: {
customRootRolesKillSwitch,
},
},
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 15:40:40 +02:00
});
return createFakeAccessService(config);
}
test('should fail when name exists', async () => {
const { accessService } = getSetup();
const existingRole = await accessService.createRole({
name: 'existing role',
description: 'description',
permissions: [],
});
expect(accessService.validateRole(existingRole)).rejects.toThrow(
new NameExistsError(
`There already exists a role with the name ${existingRole.name}`,
),
);
});
test('should validate a role without permissions', async () => {
const { accessService } = getSetup();
const withoutPermissions: IRoleValidation = {
name: 'name of the role',
description: 'description',
};
expect(await accessService.validateRole(withoutPermissions)).toEqual(
withoutPermissions,
);
});
test('should complete description field when not present', async () => {
const { accessService } = getSetup();
const withoutDescription: IRoleValidation = {
name: 'name of the role',
};
expect(await accessService.validateRole(withoutDescription)).toEqual({
name: 'name of the role',
description: '',
});
});
test('should accept empty permissions', async () => {
const { accessService } = getSetup();
const withEmptyPermissions: IRoleValidation = {
name: 'name of the role',
description: 'description',
permissions: [],
};
expect(await accessService.validateRole(withEmptyPermissions)).toEqual({
name: 'name of the role',
description: 'description',
permissions: [],
});
});
test('should complete environment field of permissions when not present', async () => {
const { accessService } = getSetup();
const withoutEnvironmentInPermissions: IRoleValidation = {
name: 'name of the role',
description: 'description',
permissions: [
{
id: 1,
},
],
};
expect(
await accessService.validateRole(withoutEnvironmentInPermissions),
).toEqual({
name: 'name of the role',
description: 'description',
permissions: [
{
id: 1,
environment: '',
},
],
});
});
test('should return the same object when all fields are valid and present', async () => {
const { accessService } = getSetup();
const roleWithAllFields: IRoleValidation = {
name: 'name of the role',
description: 'description',
permissions: [
{
id: 1,
environment: 'development',
},
],
};
expect(await accessService.validateRole(roleWithAllFields)).toEqual({
name: 'name of the role',
description: 'description',
permissions: [
{
id: 1,
environment: 'development',
},
],
});
});
test('should be able to validate and cleanup with additional properties', async () => {
const { accessService } = getSetup();
const base = {
name: 'name of the role',
description: 'description',
additional: 'property',
permissions: [
{
id: 1,
environment: 'development',
name: 'name',
displayName: 'displayName',
type: 'type',
additional: 'property',
},
],
};
expect(await accessService.validateRole(base)).toEqual({
name: 'name of the role',
description: 'description',
permissions: [
{
id: 1,
name: 'name',
environment: 'development',
},
],
});
});
test('user with custom root role should get a user root role', async () => {
const { accessService, eventStore } = getSetup(false);
const createRoleInput: IRoleCreation = {
name: 'custom-root-role',
description: 'test custom root role',
type: CUSTOM_ROOT_ROLE_TYPE,
permissions: [
{
id: 1,
environment: 'development',
name: 'fake',
},
{
name: 'root-fake-permission',
},
],
};
const customRootRole = await accessService.createRole(createRoleInput);
const user = {
id: 1,
rootRole: customRootRole.id,
};
await accessService.setUserRootRole(user.id, customRootRole.id);
const roles = await accessService.getUserRootRoles(user.id);
expect(roles).toHaveLength(1);
expect(roles[0].name).toBe('custom-root-role');
const events = await eventStore.getEvents();
expect(events).toHaveLength(1);
expect(events[0]).toEqual({
type: ROLE_CREATED,
createdBy: 'unknown',
data: {
id: 0,
name: 'custom-root-role',
description: 'test custom root role',
type: CUSTOM_ROOT_ROLE_TYPE,
// make sure we have a cleaned up version of permissions in the event
permissions: [
{ environment: 'development', name: 'fake' },
{ name: 'root-fake-permission' },
],
},
});
});
test('throws error when trying to delete a project role in use by group', async () => {
const groupIdResultOverride = async (): Promise<number[]> => {
return [1];
};
const config = createTestConfig({
getLogger,
});
const eventStore = new FakeEventStore();
const groupStore = new FakeGroupStore();
groupStore.getAllWithId = async (): Promise<IGroup[]> => {
return [{ id: 1, name: 'group' }];
};
const accountStore = new FakeAccountStore();
const roleStore = new FakeRoleStore();
const environmentStore = new FakeEnvironmentStore();
const accessStore = new AccessStoreMock();
accessStore.getGroupIdsForRole = groupIdResultOverride;
accessStore.getUserIdsForRole = async (): Promise<number[]> => {
return [];
};
accessStore.get = async (): Promise<IRole> => {
return { id: 1, type: 'custom', name: 'project role' };
};
const eventService = new EventService(
{ eventStore, featureTagStore: new FakeFeatureTagStore() },
config,
);
const groupService = new GroupService(
{ groupStore, accountStore },
{ getLogger },
eventService,
);
const accessService = new AccessService(
{
accessStore,
accountStore,
roleStore,
environmentStore,
},
config,
groupService,
eventService,
);
try {
await accessService.deleteRole(1);
} catch (e) {
expect(e.toString()).toBe(
'RoleInUseError: Role is in use by users(0) or groups(1). You cannot delete a role that is in use without first removing the role from the users and groups.',
);
}
});