|
| 1 | +/** |
| 2 | + * User permission policies. |
| 3 | + * Can be used with `hasPermission` method. |
| 4 | + * |
| 5 | + * PERMISSION GUIDELINES |
| 6 | + * |
| 7 | + * All the permission name and meaning should define **WHAT** can be done having such permission |
| 8 | + * but not **WHO** can do it. |
| 9 | + * |
| 10 | + * Examples of CORRECT permission naming and meaning: |
| 11 | + * - `VIEW_PROJECT` |
| 12 | + * - `EDIT_MILESTONE` |
| 13 | + * - `DELETE_WORK` |
| 14 | + * |
| 15 | + * Examples of INCORRECT permissions naming and meaning: |
| 16 | + * - `COPILOT_AND_MANAGER` |
| 17 | + * - `PROJECT_MEMBERS` |
| 18 | + * - `ADMINS` |
| 19 | + * |
| 20 | + * The same time **internally only** in this file, constants like `COPILOT_AND_ABOVE`, |
| 21 | + * `PROJECT_MEMBERS`, `ADMINS` could be used to define permissions. |
| 22 | + * |
| 23 | + * NAMING GUIDELINES |
| 24 | + * |
| 25 | + * There are unified prefixes to indicate what kind of permissions. |
| 26 | + * If no prefix is suitable, please, feel free to use a new prefix. |
| 27 | + * |
| 28 | + * CREATE_ - create somethings |
| 29 | + * READ_ - read something |
| 30 | + * UPDATE_ - update something |
| 31 | + * DELETE_ - delete something |
| 32 | + * |
| 33 | + * MANAGE_ - means combination of 3 operations CREATE/UPDATE/DELETE. |
| 34 | + * usually should be used, when READ operation is allowed to everyone |
| 35 | + * while 3 manage operations require additional permissions |
| 36 | + * ACCESS_ - means combination of all 4 operations READ/CREATE/UPDATE/DELETE. |
| 37 | + * usually should be used, when by default users cannot even READ something |
| 38 | + * and if someone can READ, then also can do other kind of operations. |
| 39 | + * |
| 40 | + * ANTI-PERMISSIONS |
| 41 | + * |
| 42 | + * If it's technically impossible to create permission rules for some situation in "allowed" manner, |
| 43 | + * in such case we can create permission rules, which would disallow somethings. |
| 44 | + * - Create such rules ONLY IF CREATING ALLOW RULE IS IMPOSSIBLE. |
| 45 | + * - Add a comment to such rules explaining why allow-rule cannot be created. |
| 46 | + */ |
| 47 | +/* eslint-disable no-unused-vars */ |
| 48 | +import _ from "lodash"; |
| 49 | + |
| 50 | +/** |
| 51 | + * Topcoder User roles |
| 52 | + * |
| 53 | + * Here we list only the part of the roles which might be used in the TaaS App |
| 54 | + */ |
| 55 | +export const TOPCODER_ROLE = { |
| 56 | + BOOKING_MANAGER: "bookingmanager", |
| 57 | + CONNECT_MANAGER: "Connect Manager", |
| 58 | + ADMINISTRATOR: "administrator", |
| 59 | + TOPCODER_USER: "Topcoder User", |
| 60 | +}; |
| 61 | + |
| 62 | +/** |
| 63 | + * Project Member roles |
| 64 | + * |
| 65 | + * NOTE: Team in the TaaS app is same as Project in Connect App or Projects Serivce API |
| 66 | + * |
| 67 | + * Here we list only the part of the project member roles which are used in TaaS App |
| 68 | + */ |
| 69 | +export const PROJECT_ROLE = { |
| 70 | + CUSTOMER: "customer", |
| 71 | +}; |
| 72 | + |
| 73 | +/* |
| 74 | + * The next sets of roles are exported for outside usage with `hasPermission` method. |
| 75 | + */ |
| 76 | + |
| 77 | +export const PERMISSIONS = { |
| 78 | + EDIT_RESOURCE_BOOKING: { |
| 79 | + meta: { |
| 80 | + group: "Resource Booking", |
| 81 | + title: "Edit Resource Booking", |
| 82 | + }, |
| 83 | + topcoderRoles: [TOPCODER_ROLE.BOOKING_MANAGER, TOPCODER_ROLE.ADMINISTRATOR], |
| 84 | + }, |
| 85 | + |
| 86 | + ACCESS_RESOURCE_BOOKING_MEMBER_RATE: { |
| 87 | + meta: { |
| 88 | + group: "Resource Booking", |
| 89 | + title: "Access Member Rate (view and edit)", |
| 90 | + }, |
| 91 | + topcoderRoles: [TOPCODER_ROLE.BOOKING_MANAGER, TOPCODER_ROLE.ADMINISTRATOR], |
| 92 | + }, |
| 93 | + |
| 94 | + EDIT_JOB_STATUS: { |
| 95 | + meta: { |
| 96 | + group: "Job", |
| 97 | + title: 'Edit Job "status"', |
| 98 | + }, |
| 99 | + topcoderRoles: [TOPCODER_ROLE.BOOKING_MANAGER, TOPCODER_ROLE.ADMINISTRATOR], |
| 100 | + }, |
| 101 | +}; |
0 commit comments