@telos-dev-team/dealernode-permissions 1.1.43 → 1.1.45
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/backoffice-permissions.d.ts +91 -0
- package/dist/backoffice-permissions.js +102 -0
- package/dist/index.d.ts +1 -0
- package/dist/index.js +4 -1
- package/dist/permissions.d.ts +8 -0
- package/dist/permissions.js +11 -0
- package/package.json +1 -1
- package/src/backoffice-permissions.ts +113 -0
- package/src/index.ts +6 -0
- package/src/permissions.ts +12 -0
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Backoffice realm — a separate, flat catalog from `PERMISSIONS`.
|
|
3
|
+
*
|
|
4
|
+
* The backoffice (internal admin tool) authorizes against its own
|
|
5
|
+
* `backoffice_user_permission` table, never against a dealer's `user_dealer`
|
|
6
|
+
* membership. Its permission ids share the `permission` table in the
|
|
7
|
+
* database with the product catalog above, but the two are otherwise
|
|
8
|
+
* unrelated: a `backoffice.*` id is never assignable to a dealer role, and a
|
|
9
|
+
* product id is never assignable to a backoffice user. Keeping them as a
|
|
10
|
+
* separate export (instead of a top-level key inside `PERMISSIONS`) makes
|
|
11
|
+
* that boundary explicit and lets each side filter the other out of its own
|
|
12
|
+
* catalog listing.
|
|
13
|
+
*/
|
|
14
|
+
export declare const BACKOFFICE_PERMISSIONS: {
|
|
15
|
+
readonly DEALERS: {
|
|
16
|
+
readonly VIEW: "backoffice.dealers.view";
|
|
17
|
+
readonly MANAGE: "backoffice.dealers.manage";
|
|
18
|
+
};
|
|
19
|
+
readonly USERS: {
|
|
20
|
+
readonly VIEW: "backoffice.users.view";
|
|
21
|
+
readonly MANAGE: "backoffice.users.manage";
|
|
22
|
+
};
|
|
23
|
+
/**
|
|
24
|
+
* Split out from USERS.MANAGE on purpose: granting/revoking a backoffice
|
|
25
|
+
* user's permissions is more sensitive than editing their name or email,
|
|
26
|
+
* and folding both into one permission let any admin escalate themselves
|
|
27
|
+
* to anything. No VIEW counterpart — reading a user's permissions is
|
|
28
|
+
* already covered by USERS.VIEW (GET /backoffice/users/:id).
|
|
29
|
+
*/
|
|
30
|
+
readonly PERMISSIONS: {
|
|
31
|
+
readonly MANAGE: "backoffice.permissions.manage";
|
|
32
|
+
};
|
|
33
|
+
readonly PAYMENTS: {
|
|
34
|
+
readonly VIEW: "backoffice.payments.view";
|
|
35
|
+
readonly MANAGE: "backoffice.payments.manage";
|
|
36
|
+
};
|
|
37
|
+
/**
|
|
38
|
+
* Management of per-dealer resources from the backoffice — catalogs each
|
|
39
|
+
* dealer otherwise manages under Company → Resources: bank, color, floor,
|
|
40
|
+
* purchase_source, agency, plate_origin, wholesale_target,
|
|
41
|
+
* commission_category, deal_actor_type, title_status,
|
|
42
|
+
* car_extra_category/type, deal_extra_category/type, arbitration_issue_type.
|
|
43
|
+
* One permission per area (same grain as DEALERS/USERS/PAYMENTS), not one
|
|
44
|
+
* per entity — 15 very similar entities, one permission each would be
|
|
45
|
+
* noise with no real granularity benefit.
|
|
46
|
+
*/
|
|
47
|
+
readonly DEALER_RESOURCES: {
|
|
48
|
+
readonly VIEW: "backoffice.dealer_resources.view";
|
|
49
|
+
readonly MANAGE: "backoffice.dealer_resources.manage";
|
|
50
|
+
};
|
|
51
|
+
/** Global vehicle catalog: brand/model/trim/style/fuel-type/title-brand. */
|
|
52
|
+
readonly CATALOG: {
|
|
53
|
+
readonly VIEW: "backoffice.catalog.view";
|
|
54
|
+
readonly MANAGE: "backoffice.catalog.manage";
|
|
55
|
+
};
|
|
56
|
+
/**
|
|
57
|
+
* Management of a dealer's roles and permissions from the backoffice —
|
|
58
|
+
* roles, role↔permission, role↔user and direct user↔permission grants.
|
|
59
|
+
* Its own permission (not DEALER_RESOURCES): roles/permissions govern a
|
|
60
|
+
* dealer's whole RBAC, more sensitive than a catalog of colors/banks.
|
|
61
|
+
*/
|
|
62
|
+
readonly DEALER_ROLES: {
|
|
63
|
+
readonly VIEW: "backoffice.dealer_roles.view";
|
|
64
|
+
readonly MANAGE: "backoffice.dealer_roles.manage";
|
|
65
|
+
};
|
|
66
|
+
};
|
|
67
|
+
export type BackofficePermission = typeof BACKOFFICE_PERMISSIONS;
|
|
68
|
+
/**
|
|
69
|
+
* The actual union of backoffice permission id strings. `BackofficePermission`
|
|
70
|
+
* (the type of the whole tree, mirroring `Permission` above) can't be used to
|
|
71
|
+
* type "any single backoffice permission id" — this can.
|
|
72
|
+
*/
|
|
73
|
+
type Leaves<T> = T extends string ? T : {
|
|
74
|
+
[K in keyof T]: Leaves<T[K]>;
|
|
75
|
+
}[keyof T];
|
|
76
|
+
export type BackofficePermissionId = Leaves<BackofficePermission>;
|
|
77
|
+
/**
|
|
78
|
+
* Selection presets for the permission-assignment UI. Consumers resolve
|
|
79
|
+
* these ids against their own `permission` table rows (the DB, not this
|
|
80
|
+
* package, owns the ULIDs) — see `GET /backoffice/permissions/backoffice`
|
|
81
|
+
* in dealernode-backend.
|
|
82
|
+
*/
|
|
83
|
+
export declare const BACKOFFICE_PERMISSION_PRESETS: {
|
|
84
|
+
/** Every `*.view` permission, nothing else. */
|
|
85
|
+
readonly READ_ONLY: ("backoffice.dealers.view" | "backoffice.dealers.manage" | "backoffice.users.view" | "backoffice.users.manage" | "backoffice.permissions.manage" | "backoffice.payments.view" | "backoffice.payments.manage" | "backoffice.dealer_resources.view" | "backoffice.dealer_resources.manage" | "backoffice.catalog.view" | "backoffice.catalog.manage" | "backoffice.dealer_roles.view" | "backoffice.dealer_roles.manage")[];
|
|
86
|
+
/** Read-only plus the two areas support routinely needs to act on. */
|
|
87
|
+
readonly SUPPORT: readonly [...("backoffice.dealers.view" | "backoffice.dealers.manage" | "backoffice.users.view" | "backoffice.users.manage" | "backoffice.permissions.manage" | "backoffice.payments.view" | "backoffice.payments.manage" | "backoffice.dealer_resources.view" | "backoffice.dealer_resources.manage" | "backoffice.catalog.view" | "backoffice.catalog.manage" | "backoffice.dealer_roles.view" | "backoffice.dealer_roles.manage")[], "backoffice.dealers.manage", "backoffice.dealer_resources.manage"];
|
|
88
|
+
/** Every backoffice permission. */
|
|
89
|
+
readonly ADMIN: ("backoffice.dealers.view" | "backoffice.dealers.manage" | "backoffice.users.view" | "backoffice.users.manage" | "backoffice.permissions.manage" | "backoffice.payments.view" | "backoffice.payments.manage" | "backoffice.dealer_resources.view" | "backoffice.dealer_resources.manage" | "backoffice.catalog.view" | "backoffice.catalog.manage" | "backoffice.dealer_roles.view" | "backoffice.dealer_roles.manage")[];
|
|
90
|
+
};
|
|
91
|
+
export {};
|
|
@@ -0,0 +1,102 @@
|
|
|
1
|
+
"use strict";
|
|
2
|
+
Object.defineProperty(exports, "__esModule", { value: true });
|
|
3
|
+
exports.BACKOFFICE_PERMISSION_PRESETS = exports.BACKOFFICE_PERMISSIONS = void 0;
|
|
4
|
+
/**
|
|
5
|
+
* Backoffice realm — a separate, flat catalog from `PERMISSIONS`.
|
|
6
|
+
*
|
|
7
|
+
* The backoffice (internal admin tool) authorizes against its own
|
|
8
|
+
* `backoffice_user_permission` table, never against a dealer's `user_dealer`
|
|
9
|
+
* membership. Its permission ids share the `permission` table in the
|
|
10
|
+
* database with the product catalog above, but the two are otherwise
|
|
11
|
+
* unrelated: a `backoffice.*` id is never assignable to a dealer role, and a
|
|
12
|
+
* product id is never assignable to a backoffice user. Keeping them as a
|
|
13
|
+
* separate export (instead of a top-level key inside `PERMISSIONS`) makes
|
|
14
|
+
* that boundary explicit and lets each side filter the other out of its own
|
|
15
|
+
* catalog listing.
|
|
16
|
+
*/
|
|
17
|
+
exports.BACKOFFICE_PERMISSIONS = {
|
|
18
|
+
DEALERS: {
|
|
19
|
+
VIEW: "backoffice.dealers.view",
|
|
20
|
+
MANAGE: "backoffice.dealers.manage",
|
|
21
|
+
},
|
|
22
|
+
USERS: {
|
|
23
|
+
VIEW: "backoffice.users.view",
|
|
24
|
+
MANAGE: "backoffice.users.manage",
|
|
25
|
+
},
|
|
26
|
+
/**
|
|
27
|
+
* Split out from USERS.MANAGE on purpose: granting/revoking a backoffice
|
|
28
|
+
* user's permissions is more sensitive than editing their name or email,
|
|
29
|
+
* and folding both into one permission let any admin escalate themselves
|
|
30
|
+
* to anything. No VIEW counterpart — reading a user's permissions is
|
|
31
|
+
* already covered by USERS.VIEW (GET /backoffice/users/:id).
|
|
32
|
+
*/
|
|
33
|
+
PERMISSIONS: {
|
|
34
|
+
MANAGE: "backoffice.permissions.manage",
|
|
35
|
+
},
|
|
36
|
+
PAYMENTS: {
|
|
37
|
+
VIEW: "backoffice.payments.view",
|
|
38
|
+
MANAGE: "backoffice.payments.manage",
|
|
39
|
+
},
|
|
40
|
+
/**
|
|
41
|
+
* Management of per-dealer resources from the backoffice — catalogs each
|
|
42
|
+
* dealer otherwise manages under Company → Resources: bank, color, floor,
|
|
43
|
+
* purchase_source, agency, plate_origin, wholesale_target,
|
|
44
|
+
* commission_category, deal_actor_type, title_status,
|
|
45
|
+
* car_extra_category/type, deal_extra_category/type, arbitration_issue_type.
|
|
46
|
+
* One permission per area (same grain as DEALERS/USERS/PAYMENTS), not one
|
|
47
|
+
* per entity — 15 very similar entities, one permission each would be
|
|
48
|
+
* noise with no real granularity benefit.
|
|
49
|
+
*/
|
|
50
|
+
DEALER_RESOURCES: {
|
|
51
|
+
VIEW: "backoffice.dealer_resources.view",
|
|
52
|
+
MANAGE: "backoffice.dealer_resources.manage",
|
|
53
|
+
},
|
|
54
|
+
/** Global vehicle catalog: brand/model/trim/style/fuel-type/title-brand. */
|
|
55
|
+
CATALOG: {
|
|
56
|
+
VIEW: "backoffice.catalog.view",
|
|
57
|
+
MANAGE: "backoffice.catalog.manage",
|
|
58
|
+
},
|
|
59
|
+
/**
|
|
60
|
+
* Management of a dealer's roles and permissions from the backoffice —
|
|
61
|
+
* roles, role↔permission, role↔user and direct user↔permission grants.
|
|
62
|
+
* Its own permission (not DEALER_RESOURCES): roles/permissions govern a
|
|
63
|
+
* dealer's whole RBAC, more sensitive than a catalog of colors/banks.
|
|
64
|
+
*/
|
|
65
|
+
DEALER_ROLES: {
|
|
66
|
+
VIEW: "backoffice.dealer_roles.view",
|
|
67
|
+
MANAGE: "backoffice.dealer_roles.manage",
|
|
68
|
+
},
|
|
69
|
+
};
|
|
70
|
+
function flatten(node) {
|
|
71
|
+
const values = [];
|
|
72
|
+
for (const key of Object.keys(node)) {
|
|
73
|
+
const value = node[key];
|
|
74
|
+
if (typeof value === "string") {
|
|
75
|
+
values.push(value);
|
|
76
|
+
}
|
|
77
|
+
else if (typeof value === "object" && value !== null) {
|
|
78
|
+
values.push(...flatten(value));
|
|
79
|
+
}
|
|
80
|
+
}
|
|
81
|
+
return values;
|
|
82
|
+
}
|
|
83
|
+
const ALL_BACKOFFICE_PERMISSIONS = flatten(exports.BACKOFFICE_PERMISSIONS);
|
|
84
|
+
const READ_ONLY_BACKOFFICE_PERMISSIONS = ALL_BACKOFFICE_PERMISSIONS.filter((id) => id.endsWith(".view"));
|
|
85
|
+
/**
|
|
86
|
+
* Selection presets for the permission-assignment UI. Consumers resolve
|
|
87
|
+
* these ids against their own `permission` table rows (the DB, not this
|
|
88
|
+
* package, owns the ULIDs) — see `GET /backoffice/permissions/backoffice`
|
|
89
|
+
* in dealernode-backend.
|
|
90
|
+
*/
|
|
91
|
+
exports.BACKOFFICE_PERMISSION_PRESETS = {
|
|
92
|
+
/** Every `*.view` permission, nothing else. */
|
|
93
|
+
READ_ONLY: READ_ONLY_BACKOFFICE_PERMISSIONS,
|
|
94
|
+
/** Read-only plus the two areas support routinely needs to act on. */
|
|
95
|
+
SUPPORT: [
|
|
96
|
+
...READ_ONLY_BACKOFFICE_PERMISSIONS,
|
|
97
|
+
exports.BACKOFFICE_PERMISSIONS.DEALERS.MANAGE,
|
|
98
|
+
exports.BACKOFFICE_PERMISSIONS.DEALER_RESOURCES.MANAGE,
|
|
99
|
+
],
|
|
100
|
+
/** Every backoffice permission. */
|
|
101
|
+
ADMIN: ALL_BACKOFFICE_PERMISSIONS,
|
|
102
|
+
};
|
package/dist/index.d.ts
CHANGED
package/dist/index.js
CHANGED
|
@@ -1,5 +1,8 @@
|
|
|
1
1
|
"use strict";
|
|
2
2
|
Object.defineProperty(exports, "__esModule", { value: true });
|
|
3
|
-
exports.PERMISSIONS = void 0;
|
|
3
|
+
exports.BACKOFFICE_PERMISSION_PRESETS = exports.BACKOFFICE_PERMISSIONS = exports.PERMISSIONS = void 0;
|
|
4
4
|
var permissions_1 = require("./permissions");
|
|
5
5
|
Object.defineProperty(exports, "PERMISSIONS", { enumerable: true, get: function () { return permissions_1.PERMISSIONS; } });
|
|
6
|
+
var backoffice_permissions_1 = require("./backoffice-permissions");
|
|
7
|
+
Object.defineProperty(exports, "BACKOFFICE_PERMISSIONS", { enumerable: true, get: function () { return backoffice_permissions_1.BACKOFFICE_PERMISSIONS; } });
|
|
8
|
+
Object.defineProperty(exports, "BACKOFFICE_PERMISSION_PRESETS", { enumerable: true, get: function () { return backoffice_permissions_1.BACKOFFICE_PERMISSION_PRESETS; } });
|
package/dist/permissions.d.ts
CHANGED
|
@@ -738,5 +738,13 @@ export declare const PERMISSIONS: {
|
|
|
738
738
|
};
|
|
739
739
|
};
|
|
740
740
|
};
|
|
741
|
+
readonly CRM: {
|
|
742
|
+
readonly CONVERSATION: {
|
|
743
|
+
readonly OPERATIONS: {
|
|
744
|
+
readonly VIEW: "crm.conversation.operations.view";
|
|
745
|
+
readonly REPLY: "crm.conversation.operations.reply";
|
|
746
|
+
};
|
|
747
|
+
};
|
|
748
|
+
};
|
|
741
749
|
};
|
|
742
750
|
export type Permission = typeof PERMISSIONS;
|
package/dist/permissions.js
CHANGED
|
@@ -822,4 +822,15 @@ exports.PERMISSIONS = {
|
|
|
822
822
|
},
|
|
823
823
|
},
|
|
824
824
|
},
|
|
825
|
+
// ============================================
|
|
826
|
+
// CRM
|
|
827
|
+
// ============================================
|
|
828
|
+
CRM: {
|
|
829
|
+
CONVERSATION: {
|
|
830
|
+
OPERATIONS: {
|
|
831
|
+
VIEW: "crm.conversation.operations.view",
|
|
832
|
+
REPLY: "crm.conversation.operations.reply",
|
|
833
|
+
},
|
|
834
|
+
},
|
|
835
|
+
},
|
|
825
836
|
};
|
package/package.json
CHANGED
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Backoffice realm — a separate, flat catalog from `PERMISSIONS`.
|
|
3
|
+
*
|
|
4
|
+
* The backoffice (internal admin tool) authorizes against its own
|
|
5
|
+
* `backoffice_user_permission` table, never against a dealer's `user_dealer`
|
|
6
|
+
* membership. Its permission ids share the `permission` table in the
|
|
7
|
+
* database with the product catalog above, but the two are otherwise
|
|
8
|
+
* unrelated: a `backoffice.*` id is never assignable to a dealer role, and a
|
|
9
|
+
* product id is never assignable to a backoffice user. Keeping them as a
|
|
10
|
+
* separate export (instead of a top-level key inside `PERMISSIONS`) makes
|
|
11
|
+
* that boundary explicit and lets each side filter the other out of its own
|
|
12
|
+
* catalog listing.
|
|
13
|
+
*/
|
|
14
|
+
export const BACKOFFICE_PERMISSIONS = {
|
|
15
|
+
DEALERS: {
|
|
16
|
+
VIEW: "backoffice.dealers.view",
|
|
17
|
+
MANAGE: "backoffice.dealers.manage",
|
|
18
|
+
},
|
|
19
|
+
USERS: {
|
|
20
|
+
VIEW: "backoffice.users.view",
|
|
21
|
+
MANAGE: "backoffice.users.manage",
|
|
22
|
+
},
|
|
23
|
+
/**
|
|
24
|
+
* Split out from USERS.MANAGE on purpose: granting/revoking a backoffice
|
|
25
|
+
* user's permissions is more sensitive than editing their name or email,
|
|
26
|
+
* and folding both into one permission let any admin escalate themselves
|
|
27
|
+
* to anything. No VIEW counterpart — reading a user's permissions is
|
|
28
|
+
* already covered by USERS.VIEW (GET /backoffice/users/:id).
|
|
29
|
+
*/
|
|
30
|
+
PERMISSIONS: {
|
|
31
|
+
MANAGE: "backoffice.permissions.manage",
|
|
32
|
+
},
|
|
33
|
+
PAYMENTS: {
|
|
34
|
+
VIEW: "backoffice.payments.view",
|
|
35
|
+
MANAGE: "backoffice.payments.manage",
|
|
36
|
+
},
|
|
37
|
+
/**
|
|
38
|
+
* Management of per-dealer resources from the backoffice — catalogs each
|
|
39
|
+
* dealer otherwise manages under Company → Resources: bank, color, floor,
|
|
40
|
+
* purchase_source, agency, plate_origin, wholesale_target,
|
|
41
|
+
* commission_category, deal_actor_type, title_status,
|
|
42
|
+
* car_extra_category/type, deal_extra_category/type, arbitration_issue_type.
|
|
43
|
+
* One permission per area (same grain as DEALERS/USERS/PAYMENTS), not one
|
|
44
|
+
* per entity — 15 very similar entities, one permission each would be
|
|
45
|
+
* noise with no real granularity benefit.
|
|
46
|
+
*/
|
|
47
|
+
DEALER_RESOURCES: {
|
|
48
|
+
VIEW: "backoffice.dealer_resources.view",
|
|
49
|
+
MANAGE: "backoffice.dealer_resources.manage",
|
|
50
|
+
},
|
|
51
|
+
/** Global vehicle catalog: brand/model/trim/style/fuel-type/title-brand. */
|
|
52
|
+
CATALOG: {
|
|
53
|
+
VIEW: "backoffice.catalog.view",
|
|
54
|
+
MANAGE: "backoffice.catalog.manage",
|
|
55
|
+
},
|
|
56
|
+
/**
|
|
57
|
+
* Management of a dealer's roles and permissions from the backoffice —
|
|
58
|
+
* roles, role↔permission, role↔user and direct user↔permission grants.
|
|
59
|
+
* Its own permission (not DEALER_RESOURCES): roles/permissions govern a
|
|
60
|
+
* dealer's whole RBAC, more sensitive than a catalog of colors/banks.
|
|
61
|
+
*/
|
|
62
|
+
DEALER_ROLES: {
|
|
63
|
+
VIEW: "backoffice.dealer_roles.view",
|
|
64
|
+
MANAGE: "backoffice.dealer_roles.manage",
|
|
65
|
+
},
|
|
66
|
+
} as const;
|
|
67
|
+
|
|
68
|
+
export type BackofficePermission = typeof BACKOFFICE_PERMISSIONS;
|
|
69
|
+
|
|
70
|
+
/**
|
|
71
|
+
* The actual union of backoffice permission id strings. `BackofficePermission`
|
|
72
|
+
* (the type of the whole tree, mirroring `Permission` above) can't be used to
|
|
73
|
+
* type "any single backoffice permission id" — this can.
|
|
74
|
+
*/
|
|
75
|
+
type Leaves<T> = T extends string ? T : { [K in keyof T]: Leaves<T[K]> }[keyof T];
|
|
76
|
+
export type BackofficePermissionId = Leaves<BackofficePermission>;
|
|
77
|
+
|
|
78
|
+
function flatten(node: Record<string, unknown>): BackofficePermissionId[] {
|
|
79
|
+
const values: BackofficePermissionId[] = [];
|
|
80
|
+
for (const key of Object.keys(node)) {
|
|
81
|
+
const value = node[key];
|
|
82
|
+
if (typeof value === "string") {
|
|
83
|
+
values.push(value as BackofficePermissionId);
|
|
84
|
+
} else if (typeof value === "object" && value !== null) {
|
|
85
|
+
values.push(...flatten(value as Record<string, unknown>));
|
|
86
|
+
}
|
|
87
|
+
}
|
|
88
|
+
return values;
|
|
89
|
+
}
|
|
90
|
+
|
|
91
|
+
const ALL_BACKOFFICE_PERMISSIONS = flatten(BACKOFFICE_PERMISSIONS);
|
|
92
|
+
const READ_ONLY_BACKOFFICE_PERMISSIONS = ALL_BACKOFFICE_PERMISSIONS.filter((id) =>
|
|
93
|
+
id.endsWith(".view"),
|
|
94
|
+
);
|
|
95
|
+
|
|
96
|
+
/**
|
|
97
|
+
* Selection presets for the permission-assignment UI. Consumers resolve
|
|
98
|
+
* these ids against their own `permission` table rows (the DB, not this
|
|
99
|
+
* package, owns the ULIDs) — see `GET /backoffice/permissions/backoffice`
|
|
100
|
+
* in dealernode-backend.
|
|
101
|
+
*/
|
|
102
|
+
export const BACKOFFICE_PERMISSION_PRESETS = {
|
|
103
|
+
/** Every `*.view` permission, nothing else. */
|
|
104
|
+
READ_ONLY: READ_ONLY_BACKOFFICE_PERMISSIONS,
|
|
105
|
+
/** Read-only plus the two areas support routinely needs to act on. */
|
|
106
|
+
SUPPORT: [
|
|
107
|
+
...READ_ONLY_BACKOFFICE_PERMISSIONS,
|
|
108
|
+
BACKOFFICE_PERMISSIONS.DEALERS.MANAGE,
|
|
109
|
+
BACKOFFICE_PERMISSIONS.DEALER_RESOURCES.MANAGE,
|
|
110
|
+
],
|
|
111
|
+
/** Every backoffice permission. */
|
|
112
|
+
ADMIN: ALL_BACKOFFICE_PERMISSIONS,
|
|
113
|
+
} as const satisfies Record<string, readonly BackofficePermissionId[]>;
|
package/src/index.ts
CHANGED
package/src/permissions.ts
CHANGED
|
@@ -849,6 +849,18 @@ export const PERMISSIONS = {
|
|
|
849
849
|
},
|
|
850
850
|
},
|
|
851
851
|
},
|
|
852
|
+
|
|
853
|
+
// ============================================
|
|
854
|
+
// CRM
|
|
855
|
+
// ============================================
|
|
856
|
+
CRM: {
|
|
857
|
+
CONVERSATION: {
|
|
858
|
+
OPERATIONS: {
|
|
859
|
+
VIEW: "crm.conversation.operations.view",
|
|
860
|
+
REPLY: "crm.conversation.operations.reply",
|
|
861
|
+
},
|
|
862
|
+
},
|
|
863
|
+
},
|
|
852
864
|
} as const;
|
|
853
865
|
|
|
854
866
|
export type Permission = typeof PERMISSIONS;
|