@telos-dev-team/dealernode-permissions 1.1.43 → 1.1.44

package/dist/backoffice-permissions.d.ts

@@ -0,0 +1,91 @@
+/**
+ * Backoffice realm — a separate, flat catalog from `PERMISSIONS`.
+ *
+ * The backoffice (internal admin tool) authorizes against its own
+ * `backoffice_user_permission` table, never against a dealer's `user_dealer`
+ * membership. Its permission ids share the `permission` table in the
+ * database with the product catalog above, but the two are otherwise
+ * unrelated: a `backoffice.*` id is never assignable to a dealer role, and a
+ * product id is never assignable to a backoffice user. Keeping them as a
+ * separate export (instead of a top-level key inside `PERMISSIONS`) makes
+ * that boundary explicit and lets each side filter the other out of its own
+ * catalog listing.
+ */
+export declare const BACKOFFICE_PERMISSIONS: {
+    readonly DEALERS: {
+        readonly VIEW: "backoffice.dealers.view";
+        readonly MANAGE: "backoffice.dealers.manage";
+    };
+    readonly USERS: {
+        readonly VIEW: "backoffice.users.view";
+        readonly MANAGE: "backoffice.users.manage";
+    };
+    /**
+     * Split out from USERS.MANAGE on purpose: granting/revoking a backoffice
+     * user's permissions is more sensitive than editing their name or email,
+     * and folding both into one permission let any admin escalate themselves
+     * to anything. No VIEW counterpart — reading a user's permissions is
+     * already covered by USERS.VIEW (GET /backoffice/users/:id).
+     */
+    readonly PERMISSIONS: {
+        readonly MANAGE: "backoffice.permissions.manage";
+    };
+    readonly PAYMENTS: {
+        readonly VIEW: "backoffice.payments.view";
+        readonly MANAGE: "backoffice.payments.manage";
+    };
+    /**
+     * Management of per-dealer resources from the backoffice — catalogs each
+     * dealer otherwise manages under Company → Resources: bank, color, floor,
+     * purchase_source, agency, plate_origin, wholesale_target,
+     * commission_category, deal_actor_type, title_status,
+     * car_extra_category/type, deal_extra_category/type, arbitration_issue_type.
+     * One permission per area (same grain as DEALERS/USERS/PAYMENTS), not one
+     * per entity — 15 very similar entities, one permission each would be
+     * noise with no real granularity benefit.
+     */
+    readonly DEALER_RESOURCES: {
+        readonly VIEW: "backoffice.dealer_resources.view";
+        readonly MANAGE: "backoffice.dealer_resources.manage";
+    };
+    /** Global vehicle catalog: brand/model/trim/style/fuel-type/title-brand. */
+    readonly CATALOG: {
+        readonly VIEW: "backoffice.catalog.view";
+        readonly MANAGE: "backoffice.catalog.manage";
+    };
+    /**
+     * Management of a dealer's roles and permissions from the backoffice —
+     * roles, role↔permission, role↔user and direct user↔permission grants.
+     * Its own permission (not DEALER_RESOURCES): roles/permissions govern a
+     * dealer's whole RBAC, more sensitive than a catalog of colors/banks.
+     */
+    readonly DEALER_ROLES: {
+        readonly VIEW: "backoffice.dealer_roles.view";
+        readonly MANAGE: "backoffice.dealer_roles.manage";
+    };
+};
+export type BackofficePermission = typeof BACKOFFICE_PERMISSIONS;
+/**
+ * The actual union of backoffice permission id strings. `BackofficePermission`
+ * (the type of the whole tree, mirroring `Permission` above) can't be used to
+ * type "any single backoffice permission id" — this can.
+ */
+type Leaves<T> = T extends string ? T : {
+    [K in keyof T]: Leaves<T[K]>;
+}[keyof T];
+export type BackofficePermissionId = Leaves<BackofficePermission>;
+/**
+ * Selection presets for the permission-assignment UI. Consumers resolve
+ * these ids against their own `permission` table rows (the DB, not this
+ * package, owns the ULIDs) — see `GET /backoffice/permissions/backoffice`
+ * in dealernode-backend.
+ */
+export declare const BACKOFFICE_PERMISSION_PRESETS: {
+    /** Every `*.view` permission, nothing else. */
+    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")[];
+    /** Read-only plus the two areas support routinely needs to act on. */
+    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"];
+    /** Every backoffice permission. */
+    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")[];
+};
+export {};

package/dist/backoffice-permissions.js

@@ -0,0 +1,102 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.BACKOFFICE_PERMISSION_PRESETS = exports.BACKOFFICE_PERMISSIONS = void 0;
+/**
+ * Backoffice realm — a separate, flat catalog from `PERMISSIONS`.
+ *
+ * The backoffice (internal admin tool) authorizes against its own
+ * `backoffice_user_permission` table, never against a dealer's `user_dealer`
+ * membership. Its permission ids share the `permission` table in the
+ * database with the product catalog above, but the two are otherwise
+ * unrelated: a `backoffice.*` id is never assignable to a dealer role, and a
+ * product id is never assignable to a backoffice user. Keeping them as a
+ * separate export (instead of a top-level key inside `PERMISSIONS`) makes
+ * that boundary explicit and lets each side filter the other out of its own
+ * catalog listing.
+ */
+exports.BACKOFFICE_PERMISSIONS = {
+    DEALERS: {
+        VIEW: "backoffice.dealers.view",
+        MANAGE: "backoffice.dealers.manage",
+    },
+    USERS: {
+        VIEW: "backoffice.users.view",
+        MANAGE: "backoffice.users.manage",
+    },
+    /**
+     * Split out from USERS.MANAGE on purpose: granting/revoking a backoffice
+     * user's permissions is more sensitive than editing their name or email,
+     * and folding both into one permission let any admin escalate themselves
+     * to anything. No VIEW counterpart — reading a user's permissions is
+     * already covered by USERS.VIEW (GET /backoffice/users/:id).
+     */
+    PERMISSIONS: {
+        MANAGE: "backoffice.permissions.manage",
+    },
+    PAYMENTS: {
+        VIEW: "backoffice.payments.view",
+        MANAGE: "backoffice.payments.manage",
+    },
+    /**
+     * Management of per-dealer resources from the backoffice — catalogs each
+     * dealer otherwise manages under Company → Resources: bank, color, floor,
+     * purchase_source, agency, plate_origin, wholesale_target,
+     * commission_category, deal_actor_type, title_status,
+     * car_extra_category/type, deal_extra_category/type, arbitration_issue_type.
+     * One permission per area (same grain as DEALERS/USERS/PAYMENTS), not one
+     * per entity — 15 very similar entities, one permission each would be
+     * noise with no real granularity benefit.
+     */
+    DEALER_RESOURCES: {
+        VIEW: "backoffice.dealer_resources.view",
+        MANAGE: "backoffice.dealer_resources.manage",
+    },
+    /** Global vehicle catalog: brand/model/trim/style/fuel-type/title-brand. */
+    CATALOG: {
+        VIEW: "backoffice.catalog.view",
+        MANAGE: "backoffice.catalog.manage",
+    },
+    /**
+     * Management of a dealer's roles and permissions from the backoffice —
+     * roles, role↔permission, role↔user and direct user↔permission grants.
+     * Its own permission (not DEALER_RESOURCES): roles/permissions govern a
+     * dealer's whole RBAC, more sensitive than a catalog of colors/banks.
+     */
+    DEALER_ROLES: {
+        VIEW: "backoffice.dealer_roles.view",
+        MANAGE: "backoffice.dealer_roles.manage",
+    },
+};
+function flatten(node) {
+    const values = [];
+    for (const key of Object.keys(node)) {
+        const value = node[key];
+        if (typeof value === "string") {
+            values.push(value);
+        }
+        else if (typeof value === "object" && value !== null) {
+            values.push(...flatten(value));
+        }
+    }
+    return values;
+}
+const ALL_BACKOFFICE_PERMISSIONS = flatten(exports.BACKOFFICE_PERMISSIONS);
+const READ_ONLY_BACKOFFICE_PERMISSIONS = ALL_BACKOFFICE_PERMISSIONS.filter((id) => id.endsWith(".view"));
+/**
+ * Selection presets for the permission-assignment UI. Consumers resolve
+ * these ids against their own `permission` table rows (the DB, not this
+ * package, owns the ULIDs) — see `GET /backoffice/permissions/backoffice`
+ * in dealernode-backend.
+ */
+exports.BACKOFFICE_PERMISSION_PRESETS = {
+    /** Every `*.view` permission, nothing else. */
+    READ_ONLY: READ_ONLY_BACKOFFICE_PERMISSIONS,
+    /** Read-only plus the two areas support routinely needs to act on. */
+    SUPPORT: [
+        ...READ_ONLY_BACKOFFICE_PERMISSIONS,
+        exports.BACKOFFICE_PERMISSIONS.DEALERS.MANAGE,
+        exports.BACKOFFICE_PERMISSIONS.DEALER_RESOURCES.MANAGE,
+    ],
+    /** Every backoffice permission. */
+    ADMIN: ALL_BACKOFFICE_PERMISSIONS,
+};

package/dist/index.d.ts

@@ -1 +1,2 @@
 export { PERMISSIONS, Permission } from './permissions';
+export { BACKOFFICE_PERMISSIONS, BackofficePermission, BackofficePermissionId, BACKOFFICE_PERMISSION_PRESETS, } from './backoffice-permissions';

package/dist/index.js

@@ -1,5 +1,8 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.PERMISSIONS = void 0;
+exports.BACKOFFICE_PERMISSION_PRESETS = exports.BACKOFFICE_PERMISSIONS = exports.PERMISSIONS = void 0;
 var permissions_1 = require("./permissions");
 Object.defineProperty(exports, "PERMISSIONS", { enumerable: true, get: function () { return permissions_1.PERMISSIONS; } });
+var backoffice_permissions_1 = require("./backoffice-permissions");
+Object.defineProperty(exports, "BACKOFFICE_PERMISSIONS", { enumerable: true, get: function () { return backoffice_permissions_1.BACKOFFICE_PERMISSIONS; } });
+Object.defineProperty(exports, "BACKOFFICE_PERMISSION_PRESETS", { enumerable: true, get: function () { return backoffice_permissions_1.BACKOFFICE_PERMISSION_PRESETS; } });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@telos-dev-team/dealernode-permissions",
-  "version": "1.1.43",
+  "version": "1.1.44",
   "description": "Shared permissions constants for dealernode projects",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/src/backoffice-permissions.ts

@@ -0,0 +1,113 @@
+/**
+ * Backoffice realm — a separate, flat catalog from `PERMISSIONS`.
+ *
+ * The backoffice (internal admin tool) authorizes against its own
+ * `backoffice_user_permission` table, never against a dealer's `user_dealer`
+ * membership. Its permission ids share the `permission` table in the
+ * database with the product catalog above, but the two are otherwise
+ * unrelated: a `backoffice.*` id is never assignable to a dealer role, and a
+ * product id is never assignable to a backoffice user. Keeping them as a
+ * separate export (instead of a top-level key inside `PERMISSIONS`) makes
+ * that boundary explicit and lets each side filter the other out of its own
+ * catalog listing.
+ */
+export const BACKOFFICE_PERMISSIONS = {
+  DEALERS: {
+    VIEW: "backoffice.dealers.view",
+    MANAGE: "backoffice.dealers.manage",
+  },
+  USERS: {
+    VIEW: "backoffice.users.view",
+    MANAGE: "backoffice.users.manage",
+  },
+  /**
+   * Split out from USERS.MANAGE on purpose: granting/revoking a backoffice
+   * user's permissions is more sensitive than editing their name or email,
+   * and folding both into one permission let any admin escalate themselves
+   * to anything. No VIEW counterpart — reading a user's permissions is
+   * already covered by USERS.VIEW (GET /backoffice/users/:id).
+   */
+  PERMISSIONS: {
+    MANAGE: "backoffice.permissions.manage",
+  },
+  PAYMENTS: {
+    VIEW: "backoffice.payments.view",
+    MANAGE: "backoffice.payments.manage",
+  },
+  /**
+   * Management of per-dealer resources from the backoffice — catalogs each
+   * dealer otherwise manages under Company → Resources: bank, color, floor,
+   * purchase_source, agency, plate_origin, wholesale_target,
+   * commission_category, deal_actor_type, title_status,
+   * car_extra_category/type, deal_extra_category/type, arbitration_issue_type.
+   * One permission per area (same grain as DEALERS/USERS/PAYMENTS), not one
+   * per entity — 15 very similar entities, one permission each would be
+   * noise with no real granularity benefit.
+   */
+  DEALER_RESOURCES: {
+    VIEW: "backoffice.dealer_resources.view",
+    MANAGE: "backoffice.dealer_resources.manage",
+  },
+  /** Global vehicle catalog: brand/model/trim/style/fuel-type/title-brand. */
+  CATALOG: {
+    VIEW: "backoffice.catalog.view",
+    MANAGE: "backoffice.catalog.manage",
+  },
+  /**
+   * Management of a dealer's roles and permissions from the backoffice —
+   * roles, role↔permission, role↔user and direct user↔permission grants.
+   * Its own permission (not DEALER_RESOURCES): roles/permissions govern a
+   * dealer's whole RBAC, more sensitive than a catalog of colors/banks.
+   */
+  DEALER_ROLES: {
+    VIEW: "backoffice.dealer_roles.view",
+    MANAGE: "backoffice.dealer_roles.manage",
+  },
+} as const;
+
+export type BackofficePermission = typeof BACKOFFICE_PERMISSIONS;
+
+/**
+ * The actual union of backoffice permission id strings. `BackofficePermission`
+ * (the type of the whole tree, mirroring `Permission` above) can't be used to
+ * type "any single backoffice permission id" — this can.
+ */
+type Leaves<T> = T extends string ? T : { [K in keyof T]: Leaves<T[K]> }[keyof T];
+export type BackofficePermissionId = Leaves<BackofficePermission>;
+
+function flatten(node: Record<string, unknown>): BackofficePermissionId[] {
+  const values: BackofficePermissionId[] = [];
+  for (const key of Object.keys(node)) {
+    const value = node[key];
+    if (typeof value === "string") {
+      values.push(value as BackofficePermissionId);
+    } else if (typeof value === "object" && value !== null) {
+      values.push(...flatten(value as Record<string, unknown>));
+    }
+  }
+  return values;
+}
+
+const ALL_BACKOFFICE_PERMISSIONS = flatten(BACKOFFICE_PERMISSIONS);
+const READ_ONLY_BACKOFFICE_PERMISSIONS = ALL_BACKOFFICE_PERMISSIONS.filter((id) =>
+  id.endsWith(".view"),
+);
+
+/**
+ * Selection presets for the permission-assignment UI. Consumers resolve
+ * these ids against their own `permission` table rows (the DB, not this
+ * package, owns the ULIDs) — see `GET /backoffice/permissions/backoffice`
+ * in dealernode-backend.
+ */
+export const BACKOFFICE_PERMISSION_PRESETS = {
+  /** Every `*.view` permission, nothing else. */
+  READ_ONLY: READ_ONLY_BACKOFFICE_PERMISSIONS,
+  /** Read-only plus the two areas support routinely needs to act on. */
+  SUPPORT: [
+    ...READ_ONLY_BACKOFFICE_PERMISSIONS,
+    BACKOFFICE_PERMISSIONS.DEALERS.MANAGE,
+    BACKOFFICE_PERMISSIONS.DEALER_RESOURCES.MANAGE,
+  ],
+  /** Every backoffice permission. */
+  ADMIN: ALL_BACKOFFICE_PERMISSIONS,
+} as const satisfies Record<string, readonly BackofficePermissionId[]>;

package/src/index.ts

@@ -1 +1,7 @@
 export { PERMISSIONS, Permission } from './permissions';
+export {
+  BACKOFFICE_PERMISSIONS,
+  BackofficePermission,
+  BackofficePermissionId,
+  BACKOFFICE_PERMISSION_PRESETS,
+} from './backoffice-permissions';