@wildo-ai/saas-models 1.0.1 → 1.1.0

package/dist/esm/security/authorizations/roles.shared.utils.d.ts

@@ -0,0 +1,133 @@
+/**
+ * Role-resolution utilities — pure, shared between backend authorization and
+ * frontend display gating.
+ *
+ * The framework authorizes operations against a role **hierarchy**: a user
+ * holding a high role (e.g. `ORG_OWNER`) implicitly satisfies every role it
+ * inherits from (`ORG_OWNER → ORG_ADMIN → ORG_MANAGER → ORG_MEMBER → ORG_GUEST`).
+ * `AuthorizationsBackendService` enforces this on every request; these helpers
+ * expose the SAME hierarchy walk so the frontend can decide which operation
+ * actions to even surface — without duplicating (and drifting from) the
+ * algorithm.
+ *
+ * **Why this exists on the frontend.** The resource registry the browser holds
+ * carries every operation a resource declares, each with its `roles` requirement,
+ * but the frontend historically never consulted `operation.roles` when building
+ * the action bar — so admin-only / super-admin-only actions rendered for every
+ * viewer and only 403'd on click. The backend stays the security authority; this
+ * gate is a display optimisation that hides buttons the user provably cannot use.
+ *
+ * @see roles.shared.defaults.ts — the default app/org role configurations
+ * @see roles.shared.schemas.ts — `Roles`, `RolesConfiguration`, `RoleDefinition`
+ * @see AuthorizationsBackendService.getRoleHierarchy / validateOperationRoles —
+ *   the backend twin this mirrors. If the hierarchy walk changes there, change it
+ *   here too (the role *configuration* is already shared via the constants below,
+ *   so only the algorithm can drift).
+ */
+import { type RolesConfiguration } from './roles.shared.schemas';
+/**
+ * Walk a role's inheritance chain within a single role configuration, returning
+ * the role itself plus every role it (transitively) inherits from, nearest-first.
+ *
+ * Mirrors `AuthorizationsBackendService.getRoleHierarchy`: starts at `roleKey`
+ * and follows `inheritFrom` until a role is absent from the config. A role that
+ * is **not present** in `rolesConfig` yields an EMPTY chain (it contributes
+ * nothing), exactly like the backend — callers that must not over-restrict on
+ * unknown (app-custom) roles handle that case explicitly (see
+ * {@link userRolesSatisfyRequiredRoles}).
+ *
+ * @param roleKey - the assigned role to expand
+ * @param rolesConfig - the role configuration owning the hierarchy (app or org)
+ * @returns the role + its inherited ancestors, nearest-first; empty if unknown
+ */
+export declare function computeRoleHierarchy(roleKey: string, rolesConfig: RolesConfiguration): string[];
+/** Parameters for {@link userRolesSatisfyRequiredRoles}. */
+export interface UserRolesSatisfyRequiredRolesParams {
+    /** The operation's required roles (OR semantics). Empty/undefined ⇒ unrestricted. */
+    requiredRoles: readonly string[] | undefined;
+    /** The user's APPLICATION-scope roles (e.g. `permissions.appLevel`). */
+    userAppRoles: readonly string[];
+    /** The user's ORGANIZATIONS-scope roles for the CURRENT org (e.g. `permissions.organizations[orgId]`). */
+    userOrgRoles: readonly string[];
+    /** App role configuration (defaults to {@link DEFAULT_APP_ROLE_CONFIGURATION}). */
+    appRolesConfig?: RolesConfiguration;
+    /** Org role configuration (defaults to {@link DEFAULT_ORGANIZATION_ROLES}). */
+    orgRolesConfig?: RolesConfiguration;
+}
+/**
+ * Decide whether a user's effective roles satisfy an operation's required roles,
+ * honouring the role hierarchy — the shared answer to "can this user perform this
+ * operation, role-wise?".
+ *
+ * This is the SAME OR-with-hierarchy decision the backend enforces
+ * (`validateOperationRoles`): the user passes if ANY required role lies in the
+ * inheritance closure of ANY role they hold (app roles expanded against the app
+ * config, org roles against the org config).
+ *
+ * **Conservative on the frontend / display side.** It gates which action buttons
+ * are even shown; the backend remains the security authority. It therefore FAILS
+ * OPEN on uncertainty so it can never hide a button the user is actually allowed
+ * to use:
+ *   - no/empty `requiredRoles` ⇒ `true` (unrestricted operation).
+ *   - a required role that is a public/anonymous sentinel ⇒ `true`.
+ *   - if the user holds a role UNKNOWN to the supplied config (an app-custom role
+ *     whose inheritance the default config cannot resolve) and the known-role
+ *     expansion did not already satisfy the requirement ⇒ `true` (do not hide —
+ *     the custom role might inherit a required role). For core-role-only users
+ *     (the common case, and the whole settings hub) the decision is exact.
+ *
+ * @returns `true` if the operation should be considered role-permitted (shown).
+ */
+export declare function userRolesSatisfyRequiredRoles(params: UserRolesSatisfyRequiredRolesParams): boolean;
+/**
+ * Numeric privilege rank of a single role: `tier * 100 + hierarchyDepth`.
+ *
+ * Higher = more privileged. Derived from {@link ROLE_PRIVILEGE_TIER} (cross-tier
+ * ordering) plus the role's hierarchy depth within its config (intra-tier
+ * ordering), so e.g. `ORG_OWNER` (205) > `ORG_MEMBER` (202), and
+ * `APP_ADMIN_SUPER_ADMIN` (304) outranks every `ORG_*`. Unknown custom roles fall
+ * back to the org tier with depth 1 — exact for core-role apps (the common case),
+ * conservative otherwise.
+ *
+ * Public / anonymous gates impose no positive requirement, so they rank `0` — the
+ * floor, equal to a truly unrestricted variant (see {@link computeVariantRightsRank}).
+ *
+ * NOTE: the intra-tier tiebreak uses hierarchy DEPTH, which is a faithful proxy
+ * for privilege only when inheritance is (near-)linear, as it is in the default
+ * configs. A branching custom `RolesConfiguration` could give a shallow-but-powerful
+ * role a lower depth than a deep-but-weak one and mis-order them; thread an explicit
+ * rank (or extend this) if such a config is introduced.
+ */
+export declare function computeRolePrivilegeRank(role: string, appRolesConfig?: RolesConfiguration, orgRolesConfig?: RolesConfiguration): number;
+/** Minimal shape this module needs from an operation variant to rank it by rights. */
+export interface RightsRankableVariant {
+    /** The roles that may perform this variant (OR semantics). Empty/undefined = unrestricted. */
+    roles?: readonly string[];
+}
+/**
+ * The rights rank a variant represents = the privilege of its most-privileged
+ * required role. An unrestricted variant (no `roles`) ranks `0` — the lowest gate.
+ */
+export declare function computeVariantRightsRank(variant: RightsRankableVariant, appRolesConfig?: RolesConfiguration, orgRolesConfig?: RolesConfiguration): number;
+/**
+ * Collapse a set of operation variants to **only the highest-right-level ones**.
+ *
+ * The framework principle: variants of an operation exist to give different
+ * behaviour according to rights, so a surface should show only the variant with
+ * the highest right level the user qualifies for — not the lower-rights ones too.
+ * (A super-admin who is also an org member otherwise sees both the member READ and
+ * the super-admin READ; this keeps only the super-admin one.)
+ *
+ * **Precondition:** pass variants the user already QUALIFIES for (i.e. post
+ * role-gating via {@link userRolesSatisfyRequiredRoles}). This selector then keeps
+ * the subset with the maximum {@link computeVariantRightsRank}. Variants that
+ * **tie** at the top rank (equal rights — e.g. context/variantKey variants that
+ * are not a rights distinction) are all returned, so the caller's existing
+ * default/sub-group logic still handles non-rights multiplicity unchanged.
+ *
+ * Used globally wherever variants surface as user actions; composite / execution
+ * views deliberately bypass this (they may show all variants, for now) by not
+ * routing through the collapsing path.
+ */
+export declare function selectHighestRightsVariants<T extends RightsRankableVariant>(variants: readonly T[], appRolesConfig?: RolesConfiguration, orgRolesConfig?: RolesConfiguration): T[];
+//# sourceMappingURL=roles.shared.utils.d.ts.map

package/dist/esm/security/authorizations/roles.shared.utils.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"roles.shared.utils.d.ts","sourceRoot":"","sources":["../../../../../src/security/authorizations/roles.shared.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,OAAO,EAAkC,KAAK,kBAAkB,EAAE,MAAM,wBAAwB,CAAC;AAMjG;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,oBAAoB,CAAC,OAAO,EAAE,MAAM,EAAE,WAAW,EAAE,kBAAkB,GAAG,MAAM,EAAE,CAQ/F;AAYD,4DAA4D;AAC5D,MAAM,WAAW,mCAAmC;IAClD,qFAAqF;IACrF,aAAa,EAAE,SAAS,MAAM,EAAE,GAAG,SAAS,CAAC;IAC7C,wEAAwE;IACxE,YAAY,EAAE,SAAS,MAAM,EAAE,CAAC;IAChC,0GAA0G;IAC1G,YAAY,EAAE,SAAS,MAAM,EAAE,CAAC;IAChC,mFAAmF;IACnF,cAAc,CAAC,EAAE,kBAAkB,CAAC;IACpC,+EAA+E;IAC/E,cAAc,CAAC,EAAE,kBAAkB,CAAC;CACrC;AAED;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,wBAAgB,6BAA6B,CAAC,MAAM,EAAE,mCAAmC,GAAG,OAAO,CAoClG;AAsCD;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,wBAAwB,CACtC,IAAI,EAAE,MAAM,EACZ,cAAc,GAAE,kBAAmD,EACnE,cAAc,GAAE,kBAA+C,GAC9D,MAAM,CAMR;AAED,sFAAsF;AACtF,MAAM,WAAW,qBAAqB;IACpC,8FAA8F;IAC9F,KAAK,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;CAC3B;AAED;;;GAGG;AACH,wBAAgB,wBAAwB,CACtC,OAAO,EAAE,qBAAqB,EAC9B,cAAc,CAAC,EAAE,kBAAkB,EACnC,cAAc,CAAC,EAAE,kBAAkB,GAClC,MAAM,CAIR;AAED;;;;;;;;;;;;;;;;;;;GAmBG;AACH,wBAAgB,2BAA2B,CAAC,CAAC,SAAS,qBAAqB,EACzE,QAAQ,EAAE,SAAS,CAAC,EAAE,EACtB,cAAc,CAAC,EAAE,kBAAkB,EACnC,cAAc,CAAC,EAAE,kBAAkB,GAClC,CAAC,EAAE,CAQL"}

package/dist/esm/security/authorizations/roles.shared.utils.js

@@ -0,0 +1,218 @@
+/**
+ * Role-resolution utilities — pure, shared between backend authorization and
+ * frontend display gating.
+ *
+ * The framework authorizes operations against a role **hierarchy**: a user
+ * holding a high role (e.g. `ORG_OWNER`) implicitly satisfies every role it
+ * inherits from (`ORG_OWNER → ORG_ADMIN → ORG_MANAGER → ORG_MEMBER → ORG_GUEST`).
+ * `AuthorizationsBackendService` enforces this on every request; these helpers
+ * expose the SAME hierarchy walk so the frontend can decide which operation
+ * actions to even surface — without duplicating (and drifting from) the
+ * algorithm.
+ *
+ * **Why this exists on the frontend.** The resource registry the browser holds
+ * carries every operation a resource declares, each with its `roles` requirement,
+ * but the frontend historically never consulted `operation.roles` when building
+ * the action bar — so admin-only / super-admin-only actions rendered for every
+ * viewer and only 403'd on click. The backend stays the security authority; this
+ * gate is a display optimisation that hides buttons the user provably cannot use.
+ *
+ * @see roles.shared.defaults.ts — the default app/org role configurations
+ * @see roles.shared.schemas.ts — `Roles`, `RolesConfiguration`, `RoleDefinition`
+ * @see AuthorizationsBackendService.getRoleHierarchy / validateOperationRoles —
+ *   the backend twin this mirrors. If the hierarchy walk changes there, change it
+ *   here too (the role *configuration* is already shared via the constants below,
+ *   so only the algorithm can drift).
+ */
+import { CORE_APP_ROLES, CORE_ORG_ROLES } from './roles.shared.schemas.js';
+import { DEFAULT_APP_ROLE_CONFIGURATION, DEFAULT_ORGANIZATION_ROLES, } from './roles.shared.defaults.js';
+/**
+ * Walk a role's inheritance chain within a single role configuration, returning
+ * the role itself plus every role it (transitively) inherits from, nearest-first.
+ *
+ * Mirrors `AuthorizationsBackendService.getRoleHierarchy`: starts at `roleKey`
+ * and follows `inheritFrom` until a role is absent from the config. A role that
+ * is **not present** in `rolesConfig` yields an EMPTY chain (it contributes
+ * nothing), exactly like the backend — callers that must not over-restrict on
+ * unknown (app-custom) roles handle that case explicitly (see
+ * {@link userRolesSatisfyRequiredRoles}).
+ *
+ * @param roleKey - the assigned role to expand
+ * @param rolesConfig - the role configuration owning the hierarchy (app or org)
+ * @returns the role + its inherited ancestors, nearest-first; empty if unknown
+ */
+export function computeRoleHierarchy(roleKey, rolesConfig) {
+    const hierarchy = [];
+    let current = roleKey;
+    while (current && rolesConfig[current]) {
+        hierarchy.push(current);
+        current = rolesConfig[current].inheritFrom;
+    }
+    return hierarchy;
+}
+/**
+ * Required-role sentinels that impose NO positive role requirement — an operation
+ * gated on public / anonymous access must never be hidden from a viewer. Treated
+ * as always-satisfied.
+ */
+const OPEN_REQUIRED_ROLES = new Set([
+    CORE_APP_ROLES.APP_PUBLIC,
+    CORE_APP_ROLES.APP_ANONYMOUS,
+]);
+/**
+ * Decide whether a user's effective roles satisfy an operation's required roles,
+ * honouring the role hierarchy — the shared answer to "can this user perform this
+ * operation, role-wise?".
+ *
+ * This is the SAME OR-with-hierarchy decision the backend enforces
+ * (`validateOperationRoles`): the user passes if ANY required role lies in the
+ * inheritance closure of ANY role they hold (app roles expanded against the app
+ * config, org roles against the org config).
+ *
+ * **Conservative on the frontend / display side.** It gates which action buttons
+ * are even shown; the backend remains the security authority. It therefore FAILS
+ * OPEN on uncertainty so it can never hide a button the user is actually allowed
+ * to use:
+ *   - no/empty `requiredRoles` ⇒ `true` (unrestricted operation).
+ *   - a required role that is a public/anonymous sentinel ⇒ `true`.
+ *   - if the user holds a role UNKNOWN to the supplied config (an app-custom role
+ *     whose inheritance the default config cannot resolve) and the known-role
+ *     expansion did not already satisfy the requirement ⇒ `true` (do not hide —
+ *     the custom role might inherit a required role). For core-role-only users
+ *     (the common case, and the whole settings hub) the decision is exact.
+ *
+ * @returns `true` if the operation should be considered role-permitted (shown).
+ */
+export function userRolesSatisfyRequiredRoles(params) {
+    const { requiredRoles, userAppRoles, userOrgRoles, appRolesConfig = DEFAULT_APP_ROLE_CONFIGURATION, orgRolesConfig = DEFAULT_ORGANIZATION_ROLES, } = params;
+    // Unrestricted operation — always permitted.
+    if (!requiredRoles || requiredRoles.length === 0)
+        return true;
+    // A public/anonymous gate imposes no positive requirement.
+    if (requiredRoles.some(role => OPEN_REQUIRED_ROLES.has(role)))
+        return true;
+    // Expand the user's roles through their respective hierarchies.
+    const satisfiedRoles = new Set();
+    let hasUnresolvableUserRole = false;
+    for (const role of userAppRoles) {
+        const hierarchy = computeRoleHierarchy(role, appRolesConfig);
+        if (hierarchy.length === 0)
+            hasUnresolvableUserRole = true;
+        for (const inherited of hierarchy)
+            satisfiedRoles.add(inherited);
+    }
+    for (const role of userOrgRoles) {
+        const hierarchy = computeRoleHierarchy(role, orgRolesConfig);
+        if (hierarchy.length === 0)
+            hasUnresolvableUserRole = true;
+        for (const inherited of hierarchy)
+            satisfiedRoles.add(inherited);
+    }
+    // Direct OR-with-hierarchy satisfaction.
+    if (requiredRoles.some(role => satisfiedRoles.has(role)))
+        return true;
+    // Fail open if the user holds a role the supplied config can't expand — its
+    // (unknown) inheritance might cover a required role. Never hide on uncertainty.
+    return hasUnresolvableUserRole;
+}
+// ════════════════════════════════════════════════════════════════════════════
+// Variant selection by rights ("show only the highest-right-level variant")
+// ════════════════════════════════════════════════════════════════════════════
+/**
+ * Privilege **tier** of a core role — the product ordering between role families.
+ * A variant gated on a higher-tier role represents a "higher right level".
+ *
+ *   3 — platform/app admin (`APP_ADMIN_*`)
+ *   2 — organisation roles (`ORG_*`)
+ *   1 — authenticated user (`APP_USER`)
+ *   0 — public / anonymous
+ *
+ * This is the one **cross-scope** decision the ranking needs: app-admin outranks
+ * org, which outranks the plain authenticated user. Within a tier, the role
+ * hierarchy depth breaks ties (a deeper role inherits more, so it is higher).
+ */
+const ROLE_PRIVILEGE_TIER = {
+    [CORE_APP_ROLES.APP_PUBLIC]: 0,
+    [CORE_APP_ROLES.APP_ANONYMOUS]: 0,
+    [CORE_APP_ROLES.APP_USER]: 1,
+    [CORE_ORG_ROLES.ORG_GUEST]: 2,
+    [CORE_ORG_ROLES.ORG_MEMBER]: 2,
+    [CORE_ORG_ROLES.ORG_MANAGER]: 2,
+    [CORE_ORG_ROLES.ORG_ADMIN]: 2,
+    [CORE_ORG_ROLES.ORG_OWNER]: 2,
+    [CORE_APP_ROLES.APP_ADMIN_VIEWER]: 3,
+    [CORE_APP_ROLES.APP_ADMIN_MARKETING_EDITOR]: 3,
+    [CORE_APP_ROLES.APP_ADMIN_BILLING_MANAGER]: 3,
+    [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN]: 3,
+};
+/** Tier used for a role unknown to the default config (an app-custom role). */
+const UNKNOWN_ROLE_TIER = 2;
+const TIER_MULTIPLIER = 100;
+/**
+ * Numeric privilege rank of a single role: `tier * 100 + hierarchyDepth`.
+ *
+ * Higher = more privileged. Derived from {@link ROLE_PRIVILEGE_TIER} (cross-tier
+ * ordering) plus the role's hierarchy depth within its config (intra-tier
+ * ordering), so e.g. `ORG_OWNER` (205) > `ORG_MEMBER` (202), and
+ * `APP_ADMIN_SUPER_ADMIN` (304) outranks every `ORG_*`. Unknown custom roles fall
+ * back to the org tier with depth 1 — exact for core-role apps (the common case),
+ * conservative otherwise.
+ *
+ * Public / anonymous gates impose no positive requirement, so they rank `0` — the
+ * floor, equal to a truly unrestricted variant (see {@link computeVariantRightsRank}).
+ *
+ * NOTE: the intra-tier tiebreak uses hierarchy DEPTH, which is a faithful proxy
+ * for privilege only when inheritance is (near-)linear, as it is in the default
+ * configs. A branching custom `RolesConfiguration` could give a shallow-but-powerful
+ * role a lower depth than a deep-but-weak one and mis-order them; thread an explicit
+ * rank (or extend this) if such a config is introduced.
+ */
+export function computeRolePrivilegeRank(role, appRolesConfig = DEFAULT_APP_ROLE_CONFIGURATION, orgRolesConfig = DEFAULT_ORGANIZATION_ROLES) {
+    if (OPEN_REQUIRED_ROLES.has(role))
+        return 0;
+    const tier = ROLE_PRIVILEGE_TIER[role] ?? UNKNOWN_ROLE_TIER;
+    const config = appRolesConfig[role] ? appRolesConfig : orgRolesConfig[role] ? orgRolesConfig : undefined;
+    const depth = config ? computeRoleHierarchy(role, config).length : 1;
+    return tier * TIER_MULTIPLIER + depth;
+}
+/**
+ * The rights rank a variant represents = the privilege of its most-privileged
+ * required role. An unrestricted variant (no `roles`) ranks `0` — the lowest gate.
+ */
+export function computeVariantRightsRank(variant, appRolesConfig, orgRolesConfig) {
+    const roles = variant.roles ?? [];
+    if (roles.length === 0)
+        return 0;
+    return Math.max(...roles.map(role => computeRolePrivilegeRank(role, appRolesConfig, orgRolesConfig)));
+}
+/**
+ * Collapse a set of operation variants to **only the highest-right-level ones**.
+ *
+ * The framework principle: variants of an operation exist to give different
+ * behaviour according to rights, so a surface should show only the variant with
+ * the highest right level the user qualifies for — not the lower-rights ones too.
+ * (A super-admin who is also an org member otherwise sees both the member READ and
+ * the super-admin READ; this keeps only the super-admin one.)
+ *
+ * **Precondition:** pass variants the user already QUALIFIES for (i.e. post
+ * role-gating via {@link userRolesSatisfyRequiredRoles}). This selector then keeps
+ * the subset with the maximum {@link computeVariantRightsRank}. Variants that
+ * **tie** at the top rank (equal rights — e.g. context/variantKey variants that
+ * are not a rights distinction) are all returned, so the caller's existing
+ * default/sub-group logic still handles non-rights multiplicity unchanged.
+ *
+ * Used globally wherever variants surface as user actions; composite / execution
+ * views deliberately bypass this (they may show all variants, for now) by not
+ * routing through the collapsing path.
+ */
+export function selectHighestRightsVariants(variants, appRolesConfig, orgRolesConfig) {
+    if (variants.length <= 1)
+        return [...variants];
+    const ranked = variants.map(variant => ({
+        variant,
+        rank: computeVariantRightsRank(variant, appRolesConfig, orgRolesConfig),
+    }));
+    const maxRank = Math.max(...ranked.map(entry => entry.rank));
+    return ranked.filter(entry => entry.rank === maxRank).map(entry => entry.variant);
+}
+//# sourceMappingURL=roles.shared.utils.js.map

package/dist/esm/security/authorizations/roles.shared.utils.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"roles.shared.utils.js","sourceRoot":"","sources":["../../../../../src/security/authorizations/roles.shared.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,OAAO,EAAE,cAAc,EAAE,cAAc,EAA2B,MAAM,wBAAwB,CAAC;AACjG,OAAO,EACL,8BAA8B,EAC9B,0BAA0B,GAC3B,MAAM,yBAAyB,CAAC;AAEjC;;;;;;;;;;;;;;GAcG;AACH,MAAM,UAAU,oBAAoB,CAAC,OAAe,EAAE,WAA+B;IACnF,MAAM,SAAS,GAAa,EAAE,CAAC;IAC/B,IAAI,OAAO,GAAuB,OAAO,CAAC;IAC1C,OAAO,OAAO,IAAI,WAAW,CAAC,OAAO,CAAC,EAAE,CAAC;QACvC,SAAS,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;QACxB,OAAO,GAAG,WAAW,CAAC,OAAO,CAAC,CAAC,WAAW,CAAC;IAC7C,CAAC;IACD,OAAO,SAAS,CAAC;AACnB,CAAC;AAED;;;;GAIG;AACH,MAAM,mBAAmB,GAAwB,IAAI,GAAG,CAAS;IAC/D,cAAc,CAAC,UAAU;IACzB,cAAc,CAAC,aAAa;CAC7B,CAAC,CAAC;AAgBH;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,UAAU,6BAA6B,CAAC,MAA2C;IACvF,MAAM,EACJ,aAAa,EACb,YAAY,EACZ,YAAY,EACZ,cAAc,GAAG,8BAA8B,EAC/C,cAAc,GAAG,0BAA0B,GAC5C,GAAG,MAAM,CAAC;IAEX,6CAA6C;IAC7C,IAAI,CAAC,aAAa,IAAI,aAAa,CAAC,MAAM,KAAK,CAAC;QAAE,OAAO,IAAI,CAAC;IAE9D,2DAA2D;IAC3D,IAAI,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC,mBAAmB,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;QAAE,OAAO,IAAI,CAAC;IAE3E,gEAAgE;IAChE,MAAM,cAAc,GAAG,IAAI,GAAG,EAAU,CAAC;IACzC,IAAI,uBAAuB,GAAG,KAAK,CAAC;IAEpC,KAAK,MAAM,IAAI,IAAI,YAAY,EAAE,CAAC;QAChC,MAAM,SAAS,GAAG,oBAAoB,CAAC,IAAI,EAAE,cAAc,CAAC,CAAC;QAC7D,IAAI,SAAS,CAAC,MAAM,KAAK,CAAC;YAAE,uBAAuB,GAAG,IAAI,CAAC;QAC3D,KAAK,MAAM,SAAS,IAAI,SAAS;YAAE,cAAc,CAAC,GAAG,CAAC,SAAS,CAAC,CAAC;IACnE,CAAC;IACD,KAAK,MAAM,IAAI,IAAI,YAAY,EAAE,CAAC;QAChC,MAAM,SAAS,GAAG,oBAAoB,CAAC,IAAI,EAAE,cAAc,CAAC,CAAC;QAC7D,IAAI,SAAS,CAAC,MAAM,KAAK,CAAC;YAAE,uBAAuB,GAAG,IAAI,CAAC;QAC3D,KAAK,MAAM,SAAS,IAAI,SAAS;YAAE,cAAc,CAAC,GAAG,CAAC,SAAS,CAAC,CAAC;IACnE,CAAC;IAED,yCAAyC;IACzC,IAAI,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC,cAAc,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;QAAE,OAAO,IAAI,CAAC;IAEtE,4EAA4E;IAC5E,gFAAgF;IAChF,OAAO,uBAAuB,CAAC;AACjC,CAAC;AAED,+EAA+E;AAC/E,4EAA4E;AAC5E,+EAA+E;AAE/E;;;;;;;;;;;;GAYG;AACH,MAAM,mBAAmB,GAAqC;IAC5D,CAAC,cAAc,CAAC,UAAU,CAAC,EAAE,CAAC;IAC9B,CAAC,cAAc,CAAC,aAAa,CAAC,EAAE,CAAC;IACjC,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,CAAC;IAC5B,CAAC,cAAc,CAAC,SAAS,CAAC,EAAE,CAAC;IAC7B,CAAC,cAAc,CAAC,UAAU,CAAC,EAAE,CAAC;IAC9B,CAAC,cAAc,CAAC,WAAW,CAAC,EAAE,CAAC;IAC/B,CAAC,cAAc,CAAC,SAAS,CAAC,EAAE,CAAC;IAC7B,CAAC,cAAc,CAAC,SAAS,CAAC,EAAE,CAAC;IAC7B,CAAC,cAAc,CAAC,gBAAgB,CAAC,EAAE,CAAC;IACpC,CAAC,cAAc,CAAC,0BAA0B,CAAC,EAAE,CAAC;IAC9C,CAAC,cAAc,CAAC,yBAAyB,CAAC,EAAE,CAAC;IAC7C,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,CAAC;CAC1C,CAAC;AAEF,+EAA+E;AAC/E,MAAM,iBAAiB,GAAG,CAAC,CAAC;AAC5B,MAAM,eAAe,GAAG,GAAG,CAAC;AAE5B;;;;;;;;;;;;;;;;;;GAkBG;AACH,MAAM,UAAU,wBAAwB,CACtC,IAAY,EACZ,iBAAqC,8BAA8B,EACnE,iBAAqC,0BAA0B;IAE/D,IAAI,mBAAmB,CAAC,GAAG,CAAC,IAAI,CAAC;QAAE,OAAO,CAAC,CAAC;IAC5C,MAAM,IAAI,GAAG,mBAAmB,CAAC,IAAI,CAAC,IAAI,iBAAiB,CAAC;IAC5D,MAAM,MAAM,GAAG,cAAc,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,cAAc,CAAC,CAAC,CAAC,cAAc,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,cAAc,CAAC,CAAC,CAAC,SAAS,CAAC;IACzG,MAAM,KAAK,GAAG,MAAM,CAAC,CAAC,CAAC,oBAAoB,CAAC,IAAI,EAAE,MAAM,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,CAAC;IACrE,OAAO,IAAI,GAAG,eAAe,GAAG,KAAK,CAAC;AACxC,CAAC;AAQD;;;GAGG;AACH,MAAM,UAAU,wBAAwB,CACtC,OAA8B,EAC9B,cAAmC,EACnC,cAAmC;IAEnC,MAAM,KAAK,GAAG,OAAO,CAAC,KAAK,IAAI,EAAE,CAAC;IAClC,IAAI,KAAK,CAAC,MAAM,KAAK,CAAC;QAAE,OAAO,CAAC,CAAC;IACjC,OAAO,IAAI,CAAC,GAAG,CAAC,GAAG,KAAK,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,wBAAwB,CAAC,IAAI,EAAE,cAAc,EAAE,cAAc,CAAC,CAAC,CAAC,CAAC;AACxG,CAAC;AAED;;;;;;;;;;;;;;;;;;;GAmBG;AACH,MAAM,UAAU,2BAA2B,CACzC,QAAsB,EACtB,cAAmC,EACnC,cAAmC;IAEnC,IAAI,QAAQ,CAAC,MAAM,IAAI,CAAC;QAAE,OAAO,CAAC,GAAG,QAAQ,CAAC,CAAC;IAC/C,MAAM,MAAM,GAAG,QAAQ,CAAC,GAAG,CAAC,OAAO,CAAC,EAAE,CAAC,CAAC;QACtC,OAAO;QACP,IAAI,EAAE,wBAAwB,CAAC,OAAO,EAAE,cAAc,EAAE,cAAc,CAAC;KACxE,CAAC,CAAC,CAAC;IACJ,MAAM,OAAO,GAAG,IAAI,CAAC,GAAG,CAAC,GAAG,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC;IAC7D,OAAO,MAAM,CAAC,MAAM,CAAC,KAAK,CAAC,EAAE,CAAC,KAAK,CAAC,IAAI,KAAK,OAAO,CAAC,CAAC,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC;AACpF,CAAC","sourcesContent":["/**\n * Role-resolution utilities — pure, shared between backend authorization and\n * frontend display gating.\n *\n * The framework authorizes operations against a role **hierarchy**: a user\n * holding a high role (e.g. `ORG_OWNER`) implicitly satisfies every role it\n * inherits from (`ORG_OWNER → ORG_ADMIN → ORG_MANAGER → ORG_MEMBER → ORG_GUEST`).\n * `AuthorizationsBackendService` enforces this on every request; these helpers\n * expose the SAME hierarchy walk so the frontend can decide which operation\n * actions to even surface — without duplicating (and drifting from) the\n * algorithm.\n *\n * **Why this exists on the frontend.** The resource registry the browser holds\n * carries every operation a resource declares, each with its `roles` requirement,\n * but the frontend historically never consulted `operation.roles` when building\n * the action bar — so admin-only / super-admin-only actions rendered for every\n * viewer and only 403'd on click. The backend stays the security authority; this\n * gate is a display optimisation that hides buttons the user provably cannot use.\n *\n * @see roles.shared.defaults.ts — the default app/org role configurations\n * @see roles.shared.schemas.ts — `Roles`, `RolesConfiguration`, `RoleDefinition`\n * @see AuthorizationsBackendService.getRoleHierarchy / validateOperationRoles —\n *   the backend twin this mirrors. If the hierarchy walk changes there, change it\n *   here too (the role *configuration* is already shared via the constants below,\n *   so only the algorithm can drift).\n */\n\nimport { CORE_APP_ROLES, CORE_ORG_ROLES, type RolesConfiguration } from './roles.shared.schemas';\nimport {\n  DEFAULT_APP_ROLE_CONFIGURATION,\n  DEFAULT_ORGANIZATION_ROLES,\n} from './roles.shared.defaults';\n\n/**\n * Walk a role's inheritance chain within a single role configuration, returning\n * the role itself plus every role it (transitively) inherits from, nearest-first.\n *\n * Mirrors `AuthorizationsBackendService.getRoleHierarchy`: starts at `roleKey`\n * and follows `inheritFrom` until a role is absent from the config. A role that\n * is **not present** in `rolesConfig` yields an EMPTY chain (it contributes\n * nothing), exactly like the backend — callers that must not over-restrict on\n * unknown (app-custom) roles handle that case explicitly (see\n * {@link userRolesSatisfyRequiredRoles}).\n *\n * @param roleKey - the assigned role to expand\n * @param rolesConfig - the role configuration owning the hierarchy (app or org)\n * @returns the role + its inherited ancestors, nearest-first; empty if unknown\n */\nexport function computeRoleHierarchy(roleKey: string, rolesConfig: RolesConfiguration): string[] {\n  const hierarchy: string[] = [];\n  let current: string | undefined = roleKey;\n  while (current && rolesConfig[current]) {\n    hierarchy.push(current);\n    current = rolesConfig[current].inheritFrom;\n  }\n  return hierarchy;\n}\n\n/**\n * Required-role sentinels that impose NO positive role requirement — an operation\n * gated on public / anonymous access must never be hidden from a viewer. Treated\n * as always-satisfied.\n */\nconst OPEN_REQUIRED_ROLES: ReadonlySet<string> = new Set<string>([\n  CORE_APP_ROLES.APP_PUBLIC,\n  CORE_APP_ROLES.APP_ANONYMOUS,\n]);\n\n/** Parameters for {@link userRolesSatisfyRequiredRoles}. */\nexport interface UserRolesSatisfyRequiredRolesParams {\n  /** The operation's required roles (OR semantics). Empty/undefined ⇒ unrestricted. */\n  requiredRoles: readonly string[] | undefined;\n  /** The user's APPLICATION-scope roles (e.g. `permissions.appLevel`). */\n  userAppRoles: readonly string[];\n  /** The user's ORGANIZATIONS-scope roles for the CURRENT org (e.g. `permissions.organizations[orgId]`). */\n  userOrgRoles: readonly string[];\n  /** App role configuration (defaults to {@link DEFAULT_APP_ROLE_CONFIGURATION}). */\n  appRolesConfig?: RolesConfiguration;\n  /** Org role configuration (defaults to {@link DEFAULT_ORGANIZATION_ROLES}). */\n  orgRolesConfig?: RolesConfiguration;\n}\n\n/**\n * Decide whether a user's effective roles satisfy an operation's required roles,\n * honouring the role hierarchy — the shared answer to \"can this user perform this\n * operation, role-wise?\".\n *\n * This is the SAME OR-with-hierarchy decision the backend enforces\n * (`validateOperationRoles`): the user passes if ANY required role lies in the\n * inheritance closure of ANY role they hold (app roles expanded against the app\n * config, org roles against the org config).\n *\n * **Conservative on the frontend / display side.** It gates which action buttons\n * are even shown; the backend remains the security authority. It therefore FAILS\n * OPEN on uncertainty so it can never hide a button the user is actually allowed\n * to use:\n *   - no/empty `requiredRoles` ⇒ `true` (unrestricted operation).\n *   - a required role that is a public/anonymous sentinel ⇒ `true`.\n *   - if the user holds a role UNKNOWN to the supplied config (an app-custom role\n *     whose inheritance the default config cannot resolve) and the known-role\n *     expansion did not already satisfy the requirement ⇒ `true` (do not hide —\n *     the custom role might inherit a required role). For core-role-only users\n *     (the common case, and the whole settings hub) the decision is exact.\n *\n * @returns `true` if the operation should be considered role-permitted (shown).\n */\nexport function userRolesSatisfyRequiredRoles(params: UserRolesSatisfyRequiredRolesParams): boolean {\n  const {\n    requiredRoles,\n    userAppRoles,\n    userOrgRoles,\n    appRolesConfig = DEFAULT_APP_ROLE_CONFIGURATION,\n    orgRolesConfig = DEFAULT_ORGANIZATION_ROLES,\n  } = params;\n\n  // Unrestricted operation — always permitted.\n  if (!requiredRoles || requiredRoles.length === 0) return true;\n\n  // A public/anonymous gate imposes no positive requirement.\n  if (requiredRoles.some(role => OPEN_REQUIRED_ROLES.has(role))) return true;\n\n  // Expand the user's roles through their respective hierarchies.\n  const satisfiedRoles = new Set<string>();\n  let hasUnresolvableUserRole = false;\n\n  for (const role of userAppRoles) {\n    const hierarchy = computeRoleHierarchy(role, appRolesConfig);\n    if (hierarchy.length === 0) hasUnresolvableUserRole = true;\n    for (const inherited of hierarchy) satisfiedRoles.add(inherited);\n  }\n  for (const role of userOrgRoles) {\n    const hierarchy = computeRoleHierarchy(role, orgRolesConfig);\n    if (hierarchy.length === 0) hasUnresolvableUserRole = true;\n    for (const inherited of hierarchy) satisfiedRoles.add(inherited);\n  }\n\n  // Direct OR-with-hierarchy satisfaction.\n  if (requiredRoles.some(role => satisfiedRoles.has(role))) return true;\n\n  // Fail open if the user holds a role the supplied config can't expand — its\n  // (unknown) inheritance might cover a required role. Never hide on uncertainty.\n  return hasUnresolvableUserRole;\n}\n\n// ════════════════════════════════════════════════════════════════════════════\n// Variant selection by rights (\"show only the highest-right-level variant\")\n// ════════════════════════════════════════════════════════════════════════════\n\n/**\n * Privilege **tier** of a core role — the product ordering between role families.\n * A variant gated on a higher-tier role represents a \"higher right level\".\n *\n *   3 — platform/app admin (`APP_ADMIN_*`)\n *   2 — organisation roles (`ORG_*`)\n *   1 — authenticated user (`APP_USER`)\n *   0 — public / anonymous\n *\n * This is the one **cross-scope** decision the ranking needs: app-admin outranks\n * org, which outranks the plain authenticated user. Within a tier, the role\n * hierarchy depth breaks ties (a deeper role inherits more, so it is higher).\n */\nconst ROLE_PRIVILEGE_TIER: Readonly<Record<string, number>> = {\n  [CORE_APP_ROLES.APP_PUBLIC]: 0,\n  [CORE_APP_ROLES.APP_ANONYMOUS]: 0,\n  [CORE_APP_ROLES.APP_USER]: 1,\n  [CORE_ORG_ROLES.ORG_GUEST]: 2,\n  [CORE_ORG_ROLES.ORG_MEMBER]: 2,\n  [CORE_ORG_ROLES.ORG_MANAGER]: 2,\n  [CORE_ORG_ROLES.ORG_ADMIN]: 2,\n  [CORE_ORG_ROLES.ORG_OWNER]: 2,\n  [CORE_APP_ROLES.APP_ADMIN_VIEWER]: 3,\n  [CORE_APP_ROLES.APP_ADMIN_MARKETING_EDITOR]: 3,\n  [CORE_APP_ROLES.APP_ADMIN_BILLING_MANAGER]: 3,\n  [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN]: 3,\n};\n\n/** Tier used for a role unknown to the default config (an app-custom role). */\nconst UNKNOWN_ROLE_TIER = 2;\nconst TIER_MULTIPLIER = 100;\n\n/**\n * Numeric privilege rank of a single role: `tier * 100 + hierarchyDepth`.\n *\n * Higher = more privileged. Derived from {@link ROLE_PRIVILEGE_TIER} (cross-tier\n * ordering) plus the role's hierarchy depth within its config (intra-tier\n * ordering), so e.g. `ORG_OWNER` (205) > `ORG_MEMBER` (202), and\n * `APP_ADMIN_SUPER_ADMIN` (304) outranks every `ORG_*`. Unknown custom roles fall\n * back to the org tier with depth 1 — exact for core-role apps (the common case),\n * conservative otherwise.\n *\n * Public / anonymous gates impose no positive requirement, so they rank `0` — the\n * floor, equal to a truly unrestricted variant (see {@link computeVariantRightsRank}).\n *\n * NOTE: the intra-tier tiebreak uses hierarchy DEPTH, which is a faithful proxy\n * for privilege only when inheritance is (near-)linear, as it is in the default\n * configs. A branching custom `RolesConfiguration` could give a shallow-but-powerful\n * role a lower depth than a deep-but-weak one and mis-order them; thread an explicit\n * rank (or extend this) if such a config is introduced.\n */\nexport function computeRolePrivilegeRank(\n  role: string,\n  appRolesConfig: RolesConfiguration = DEFAULT_APP_ROLE_CONFIGURATION,\n  orgRolesConfig: RolesConfiguration = DEFAULT_ORGANIZATION_ROLES,\n): number {\n  if (OPEN_REQUIRED_ROLES.has(role)) return 0;\n  const tier = ROLE_PRIVILEGE_TIER[role] ?? UNKNOWN_ROLE_TIER;\n  const config = appRolesConfig[role] ? appRolesConfig : orgRolesConfig[role] ? orgRolesConfig : undefined;\n  const depth = config ? computeRoleHierarchy(role, config).length : 1;\n  return tier * TIER_MULTIPLIER + depth;\n}\n\n/** Minimal shape this module needs from an operation variant to rank it by rights. */\nexport interface RightsRankableVariant {\n  /** The roles that may perform this variant (OR semantics). Empty/undefined = unrestricted. */\n  roles?: readonly string[];\n}\n\n/**\n * The rights rank a variant represents = the privilege of its most-privileged\n * required role. An unrestricted variant (no `roles`) ranks `0` — the lowest gate.\n */\nexport function computeVariantRightsRank(\n  variant: RightsRankableVariant,\n  appRolesConfig?: RolesConfiguration,\n  orgRolesConfig?: RolesConfiguration,\n): number {\n  const roles = variant.roles ?? [];\n  if (roles.length === 0) return 0;\n  return Math.max(...roles.map(role => computeRolePrivilegeRank(role, appRolesConfig, orgRolesConfig)));\n}\n\n/**\n * Collapse a set of operation variants to **only the highest-right-level ones**.\n *\n * The framework principle: variants of an operation exist to give different\n * behaviour according to rights, so a surface should show only the variant with\n * the highest right level the user qualifies for — not the lower-rights ones too.\n * (A super-admin who is also an org member otherwise sees both the member READ and\n * the super-admin READ; this keeps only the super-admin one.)\n *\n * **Precondition:** pass variants the user already QUALIFIES for (i.e. post\n * role-gating via {@link userRolesSatisfyRequiredRoles}). This selector then keeps\n * the subset with the maximum {@link computeVariantRightsRank}. Variants that\n * **tie** at the top rank (equal rights — e.g. context/variantKey variants that\n * are not a rights distinction) are all returned, so the caller's existing\n * default/sub-group logic still handles non-rights multiplicity unchanged.\n *\n * Used globally wherever variants surface as user actions; composite / execution\n * views deliberately bypass this (they may show all variants, for now) by not\n * routing through the collapsing path.\n */\nexport function selectHighestRightsVariants<T extends RightsRankableVariant>(\n  variants: readonly T[],\n  appRolesConfig?: RolesConfiguration,\n  orgRolesConfig?: RolesConfiguration,\n): T[] {\n  if (variants.length <= 1) return [...variants];\n  const ranked = variants.map(variant => ({\n    variant,\n    rank: computeVariantRightsRank(variant, appRolesConfig, orgRolesConfig),\n  }));\n  const maxRank = Math.max(...ranked.map(entry => entry.rank));\n  return ranked.filter(entry => entry.rank === maxRank).map(entry => entry.variant);\n}\n"]}

package/dist/esm/security/crypto-keys/crypto-keys.shared.schemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"crypto-keys.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../src/security/crypto-keys/crypto-keys.shared.schemas.ts"],"names":[],"mappings":"AACA,oBAAY,oBAAoB;IAC9B,QAAQ,aAAa;IACrB,QAAQ,aAAa;IACrB,GAAG,QAAQ;CACZ"}
+{"version":3,"file":"crypto-keys.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/security/crypto-keys/crypto-keys.shared.schemas.ts"],"names":[],"mappings":"AACA,oBAAY,oBAAoB;IAC9B,QAAQ,aAAa;IACrB,QAAQ,aAAa;IACrB,GAAG,QAAQ;CACZ"}

package/dist/esm/security/crypto-keys/crypto-keys.shared.schemas.js

@@ -4,4 +4,4 @@ export var CryptoKey_Management;
     CryptoKey_Management["CUSTOMER"] = "customer";
     CryptoKey_Management["HSM"] = "hsm";
 })(CryptoKey_Management || (CryptoKey_Management = {}));
-//# sourceMappingURL=crypto-keys.shared.schemas.js.map
+//# sourceMappingURL=crypto-keys.shared.schemas.js.map

package/dist/esm/security/crypto-keys/crypto-keys.shared.schemas.js.map

@@ -1 +1 @@
-{"version":3,"file":"crypto-keys.shared.schemas.js","sourceRoot":"","sources":["../../../../src/security/crypto-keys/crypto-keys.shared.schemas.ts"],"names":[],"mappings":"AACA,MAAM,CAAN,IAAY,oBAIX;AAJD,WAAY,oBAAoB;IAC9B,6CAAqB,CAAA;IACrB,6CAAqB,CAAA;IACrB,mCAAW,CAAA;AACb,CAAC,EAJW,oBAAoB,KAApB,oBAAoB,QAI/B"}
+{"version":3,"file":"crypto-keys.shared.schemas.js","sourceRoot":"","sources":["../../../../../src/security/crypto-keys/crypto-keys.shared.schemas.ts"],"names":[],"mappings":"AACA,MAAM,CAAN,IAAY,oBAIX;AAJD,WAAY,oBAAoB;IAC9B,6CAAqB,CAAA;IACrB,6CAAqB,CAAA;IACrB,mCAAW,CAAA;AACb,CAAC,EAJW,oBAAoB,KAApB,oBAAoB,QAI/B","sourcesContent":["\nexport enum CryptoKey_Management {\n  PLATFORM = 'platform',\n  CUSTOMER = 'customer',\n  HSM = 'hsm',\n}"]}

package/dist/esm/security/oauth-clients/oauth-clients-application.shared.resources-config.schemas.d.ts

@@ -0,0 +1,47 @@
+/**
+ * Application OAuth Clients Shared Resource Configuration
+ *
+ * Resource configuration for managing application-scoped registered OAuth
+ * clients. FAITHFUL MIRROR of `api-keys-application.shared.resources-config.schemas.ts`
+ * with a FOCUSED operation set: core READ/LIST/SEARCH/CREATE plus a REPOSITORY_ONLY
+ * DELETE (onParentDelete cascade) and custom ROTATE/REGENERATE. The
+ * DEACTIVATE/REACTIVATE/EXTEND_EXPIRY/USAGE_STATS custom ops from api-keys are
+ * intentionally deferred to the OIDC branch.
+ */
+import { z } from 'zod';
+import { OAuthClientStatus } from './oauth-clients.shared.schemas';
+import { CoreResourceOperation } from '../../resources/resources.shared.core.definitions';
+import { ResourceRelationship } from '../../resources/resources.shared.schemas';
+import { CORE_APP_ROLES } from '../authorizations/roles.shared.schemas';
+export declare enum AppOAuthClients_Operations {
+    ROTATE = "rotate",// Generate new secret and invalidate old one
+    REGENERATE = "regenerate"
+}
+type AppOAuthClientsCoreOperations = CoreResourceOperation.READ | CoreResourceOperation.LIST | CoreResourceOperation.SEARCH | CoreResourceOperation.CREATE | CoreResourceOperation.DELETE;
+export declare const appOAuthClientsResourceConfiguration_InitializationFactory: (resourcesRelationships: ResourceRelationship[]) => import("../..").ResourceConfiguration<typeof AppOAuthClients_Operations, AppOAuthClientsCoreOperations, z.ZodObject<{
+    _id: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    name: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    description: z.ZodOptional<z.ZodString>;
+    roles: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodArray<z.ZodUnion<readonly [z.ZodEnum<typeof CORE_APP_ROLES>, z.ZodEnum<typeof import("../..").CORE_ORG_ROLES>, z.ZodString]>>>>;
+    allowedScopes: z.ZodDefault<z.ZodArray<z.ZodString>>;
+    allowedGrants: z.ZodDefault<z.ZodArray<z.ZodEnum<typeof import("./oauth-clients.shared.schemas").OAuthGrantType>>>;
+    redirectUris: z.ZodDefault<z.ZodArray<z.ZodString>>;
+    postLogoutRedirectUris: z.ZodDefault<z.ZodArray<z.ZodString>>;
+    requiresConsent: z.ZodDefault<z.ZodBoolean>;
+    tokenEndpointAuthMethod: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodEnum<typeof import("./oauth-clients.shared.schemas").OAuthTokenEndpointAuthMethod>>>;
+    status: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodEnum<typeof OAuthClientStatus>>>>>;
+    expiresAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>;
+    lastUsedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>>;
+    createdAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodDate>>>>>;
+    updatedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodDate>>>>;
+    hashedSecret: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>>>;
+    secretPrefix: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>;
+    previousHashedSecret: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodString>>>>>;
+    previousSecretPrefix: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodString>>>;
+    previousSecretInvalidationDate: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>;
+    registrationOrigin: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodEnum<typeof import("./oauth-clients.shared.schemas").OAuthClientRegistrationOrigin>>>>>>>;
+    scope: z.ZodLiteral<import("../..").ApiKeyScope.APPLICATION>;
+    applicationId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>>;
+}, z.core.$strip>>;
+export {};
+//# sourceMappingURL=oauth-clients-application.shared.resources-config.schemas.d.ts.map

package/dist/esm/security/oauth-clients/oauth-clients-application.shared.resources-config.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"oauth-clients-application.shared.resources-config.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/security/oauth-clients/oauth-clients-application.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAEL,iBAAiB,EAClB,MAAM,gCAAgC,CAAC;AACxC,OAAO,EAAE,qBAAqB,EAAE,MAAM,mDAAmD,CAAC;AAC1F,OAAO,EAAoD,oBAAoB,EAAE,MAAM,0CAA0C,CAAC;AAOlI,OAAO,EAAE,cAAc,EAAE,MAAM,wCAAwC,CAAC;AAgBxE,oBAAY,0BAA0B;IACpC,MAAM,WAAW,CAAE,6CAA6C;IAChE,UAAU,eAAe;CAC1B;AAED,KAAK,6BAA6B,GAC9B,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,CAAC;AAKjC,eAAO,MAAM,0DAA0D,GAAI,wBAAwB,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;kBAyMvH,CAAC"}