@favish/staffbase-utils 0.16.0 → 0.17.0

package/dist/src/types/pages/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../src/types/pages/index.ts"],"names":[],"mappings":"AAAA,YAAY,EAAE,iBAAiB,EAAE,MAAM,qBAAqB,CAAA;AAC5D,YAAY,EAAE,IAAI,EAAE,MAAM,QAAQ,CAAA;AAClC,YAAY,EAAE,UAAU,EAAE,MAAM,cAAc,CAAA;AAC9C,YAAY,EAAE,WAAW,EAAE,MAAM,eAAe,CAAA;AAChD,YAAY,EAAE,iBAAiB,EAAE,MAAM,qBAAqB,CAAA"}

package/dist/src/types/user/CreateUserBody.d.ts

@@ -0,0 +1,11 @@
+import { components } from './generated/userApi';
+/**
+ * Request body for creating a Staffbase user (`POST /users`).
+ *
+ * Thin alias over the machine-generated user API schema so the public name
+ * stays stable even if `generated/userApi.ts` is regenerated. The write side of
+ * the spec is properly schematized, so this is sourced directly from codegen
+ * (run the user codegen script to refresh).
+ */
+export type CreateUserBody = components['schemas']['CreateUser'];
+//# sourceMappingURL=CreateUserBody.d.ts.map

package/dist/src/types/user/CreateUserBody.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"CreateUserBody.d.ts","sourceRoot":"","sources":["../../../../src/types/user/CreateUserBody.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,qBAAqB,CAAA;AAErD;;;;;;;GAOG;AACH,MAAM,MAAM,cAAc,GAAG,UAAU,CAAC,SAAS,CAAC,CAAC,YAAY,CAAC,CAAA"}

package/dist/src/types/user/UpdateUserBody.d.ts

@@ -0,0 +1,11 @@
+import { components } from './generated/userApi';
+/**
+ * Request body for updating a Staffbase user (`PUT /users/{id}`).
+ *
+ * Thin alias over the machine-generated user API schema so the public name
+ * stays stable even if `generated/userApi.ts` is regenerated. The write side of
+ * the spec is properly schematized, so this is sourced directly from codegen
+ * (run the user codegen script to refresh).
+ */
+export type UpdateUserBody = components['schemas']['UpdateUser'];
+//# sourceMappingURL=UpdateUserBody.d.ts.map

package/dist/src/types/user/UpdateUserBody.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UpdateUserBody.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UpdateUserBody.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,qBAAqB,CAAA;AAErD;;;;;;;GAOG;AACH,MAAM,MAAM,cAAc,GAAG,UAAU,CAAC,SAAS,CAAC,CAAC,YAAY,CAAC,CAAA"}

package/dist/src/types/user/User.d.ts

@@ -0,0 +1,65 @@
+import { UserAvatar } from './UserAvatar';
+import { UserConfig } from './UserConfig';
+import { UserCreation } from './UserCreation';
+import { UserEmail } from './UserEmail';
+import { UserName } from './UserName';
+import { UserProfile } from './UserProfile';
+import { UserRecoveryCode } from './UserRecoveryCode';
+import { UserRole } from './UserRole';
+import { UserSecret } from './UserSecret';
+/**
+ * A Staffbase user as returned by the user read endpoints (`GET /api/users`
+ * list items and `GET /api/users/{id}`).
+ *
+ * Curated, not machine-generated. The official user OpenAPI spec carries two
+ * read shapes and the runtime endpoint matches NEITHER cleanly: it overlaps the
+ * spec `User` schema on only 7 of 11 fields, but matches `SingleUserWithAvatar`
+ * on all 20 of its fields AND returns extra fields the spec never documents
+ * (`branchRole`, `creation`, `entityType`, `recoveryCode`, `secret`,
+ * `userName`, `tags`, plus structured `emails`/`userName` objects). This type
+ * is therefore grounded in an exhaustive prod sweep rather than codegen.
+ *
+ * Required/optional was verified against a sweep of the full prod population
+ * (49,215 users) plus single-reads: `avatar` was absent on ~3/300 sampled,
+ * `secret` on ~8/300, `recoveryCode` on ~3/300. The full-population sweep also
+ * showed `userName` and `groupIDs` missing on some users, `publicEmailAddress`
+ * occasionally `null`, and a long tail of rare omissions (`externalID` 5/49215,
+ * `tags` 9/49215) - all typed optional accordingly.
+ *
+ * Wire-format notes (verbatim): `externalID` uses a capital `ID`; `userName`
+ * and `emails[]` are objects, not bare strings; `recoveryCode`/`secret` are
+ * objects on read (strings on write); `department`/`location`/`position` and
+ * `publicEmailAddress` are nullable; `phoneNumber` and `mandatoryGroupIDs` were
+ * observed only as `null` across the whole population (typed as a union with
+ * the spec/profile string/array form).
+ */
+export interface User {
+    id: string;
+    firstName: string;
+    lastName: string;
+    userName?: UserName;
+    emails: UserEmail[];
+    publicEmailAddress: string | null;
+    phoneNumber: string | null;
+    externalID?: string;
+    entityType: string;
+    status: string;
+    activated: string;
+    created: string;
+    updated: string;
+    creation: UserCreation;
+    role: UserRole;
+    branchRole: string;
+    config: UserConfig;
+    profile: UserProfile;
+    department: string | null;
+    location: string | null;
+    position: string | null;
+    groupIDs?: string[];
+    mandatoryGroupIDs: string[] | null;
+    tags?: string[];
+    avatar?: UserAvatar;
+    secret?: UserSecret;
+    recoveryCode?: UserRecoveryCode;
+}
+//# sourceMappingURL=User.d.ts.map

package/dist/src/types/user/User.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"User.d.ts","sourceRoot":"","sources":["../../../../src/types/user/User.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,cAAc,CAAA;AAC9C,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,cAAc,CAAA;AAC9C,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,gBAAgB,CAAA;AAClD,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAA;AAC5C,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,YAAY,CAAA;AAC1C,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,eAAe,CAAA;AAChD,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,oBAAoB,CAAA;AAC1D,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,YAAY,CAAA;AAC1C,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,cAAc,CAAA;AAE9C;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,MAAM,WAAW,IAAI;IACnB,EAAE,EAAE,MAAM,CAAA;IACV,SAAS,EAAE,MAAM,CAAA;IACjB,QAAQ,EAAE,MAAM,CAAA;IAChB,QAAQ,CAAC,EAAE,QAAQ,CAAA;IACnB,MAAM,EAAE,SAAS,EAAE,CAAA;IACnB,kBAAkB,EAAE,MAAM,GAAG,IAAI,CAAA;IACjC,WAAW,EAAE,MAAM,GAAG,IAAI,CAAA;IAC1B,UAAU,CAAC,EAAE,MAAM,CAAA;IACnB,UAAU,EAAE,MAAM,CAAA;IAClB,MAAM,EAAE,MAAM,CAAA;IACd,SAAS,EAAE,MAAM,CAAA;IACjB,OAAO,EAAE,MAAM,CAAA;IACf,OAAO,EAAE,MAAM,CAAA;IACf,QAAQ,EAAE,YAAY,CAAA;IACtB,IAAI,EAAE,QAAQ,CAAA;IACd,UAAU,EAAE,MAAM,CAAA;IAClB,MAAM,EAAE,UAAU,CAAA;IAClB,OAAO,EAAE,WAAW,CAAA;IACpB,UAAU,EAAE,MAAM,GAAG,IAAI,CAAA;IACzB,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAA;IACvB,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAA;IACvB,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAA;IACnB,iBAAiB,EAAE,MAAM,EAAE,GAAG,IAAI,CAAA;IAClC,IAAI,CAAC,EAAE,MAAM,EAAE,CAAA;IACf,MAAM,CAAC,EAAE,UAAU,CAAA;IACnB,MAAM,CAAC,EAAE,UAAU,CAAA;IACnB,YAAY,CAAC,EAAE,gBAAgB,CAAA;CAChC"}

package/dist/src/types/user/UserAvatar.d.ts

@@ -0,0 +1,19 @@
+import { UserAvatarVariant } from './UserAvatarVariant';
+/**
+ * The rendition set of a user avatar (or profile header image) returned by the
+ * Staffbase user read endpoints.
+ *
+ * Grounded in a prod sweep (6000 users): when present, the `avatar` object is
+ * either the full rendition set (`original`/`icon`/`thumb`, sometimes with
+ * `publicID`) or an empty object `{}` (a placeholder for users with no uploaded
+ * avatar). All members are therefore optional. `publicID` accompanies only the
+ * subset created through the newer upload pipeline. Each rendition reuses
+ * {@link UserAvatarVariant}.
+ */
+export interface UserAvatar {
+    original?: UserAvatarVariant;
+    icon?: UserAvatarVariant;
+    thumb?: UserAvatarVariant;
+    publicID?: string;
+}
+//# sourceMappingURL=UserAvatar.d.ts.map

package/dist/src/types/user/UserAvatar.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserAvatar.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserAvatar.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,qBAAqB,CAAA;AAE5D;;;;;;;;;;GAUG;AACH,MAAM,WAAW,UAAU;IACzB,QAAQ,CAAC,EAAE,iBAAiB,CAAA;IAC5B,IAAI,CAAC,EAAE,iBAAiB,CAAA;IACxB,KAAK,CAAC,EAAE,iBAAiB,CAAA;IACzB,QAAQ,CAAC,EAAE,MAAM,CAAA;CAClB"}

package/dist/src/types/user/UserAvatarVariant.d.ts

@@ -0,0 +1,23 @@
+/**
+ * A single rendition of a user avatar (or profile header image) as returned by
+ * the Staffbase user read endpoints (`GET /api/users`, `GET /api/users/{id}`).
+ *
+ * Grounded in an exhaustive prod sweep (2000 users): `url`, `format` and
+ * `mimeType` are present on every observed variant; `format` and `mimeType` are
+ * frequently `null` (an upload without a detected format). `width`/`height` are
+ * always present on the `original` rendition but optional on `icon`/`thumb`
+ * (absent on roughly half of them). `size` (bytes) is only ever present on the
+ * `original` rendition.
+ *
+ * Distinct from the news `ArticleImageVariant`, which requires `width`/`height`
+ * on all renditions; the user avatar shape leaves them optional.
+ */
+export interface UserAvatarVariant {
+    url: string;
+    format: string | null;
+    mimeType: string | null;
+    width?: number;
+    height?: number;
+    size?: number;
+}
+//# sourceMappingURL=UserAvatarVariant.d.ts.map

package/dist/src/types/user/UserAvatarVariant.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserAvatarVariant.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserAvatarVariant.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AACH,MAAM,WAAW,iBAAiB;IAChC,GAAG,EAAE,MAAM,CAAA;IACX,MAAM,EAAE,MAAM,GAAG,IAAI,CAAA;IACrB,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAA;IACvB,KAAK,CAAC,EAAE,MAAM,CAAA;IACd,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,IAAI,CAAC,EAAE,MAAM,CAAA;CACd"}

package/dist/src/types/user/UserConfig.d.ts

@@ -0,0 +1,11 @@
+/**
+ * Per-user configuration block returned by the Staffbase user read endpoints.
+ *
+ * Grounded in a prod sweep (2000 users): every user carried a `config` object
+ * with a `locale` string (e.g. `en_US`). Matches the spec
+ * `SingleUserWithAvatar.config` shape.
+ */
+export interface UserConfig {
+    locale: string;
+}
+//# sourceMappingURL=UserConfig.d.ts.map

package/dist/src/types/user/UserConfig.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserConfig.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserConfig.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,MAAM,WAAW,UAAU;IACzB,MAAM,EAAE,MAAM,CAAA;CACf"}

package/dist/src/types/user/UserCreation.d.ts

@@ -0,0 +1,16 @@
+/**
+ * Provenance of a Staffbase user account, returned by the user read endpoints.
+ *
+ * Grounded in a prod sweep: `type` was present on every user (e.g. how the
+ * account was created). `invitorID`/`invitorType` identify the actor that
+ * invited the user and were present on almost every account (absent only on
+ * users created without an explicit inviter). `ssoConfigID` appears only on
+ * users provisioned through an SSO configuration. Not documented by the spec.
+ */
+export interface UserCreation {
+    type: string;
+    invitorID?: string;
+    invitorType?: string;
+    ssoConfigID?: string;
+}
+//# sourceMappingURL=UserCreation.d.ts.map

package/dist/src/types/user/UserCreation.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserCreation.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserCreation.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AACH,MAAM,WAAW,YAAY;IAC3B,IAAI,EAAE,MAAM,CAAA;IACZ,SAAS,CAAC,EAAE,MAAM,CAAA;IAClB,WAAW,CAAC,EAAE,MAAM,CAAA;IACpB,WAAW,CAAC,EAAE,MAAM,CAAA;CACrB"}

package/dist/src/types/user/UserEmail.d.ts

@@ -0,0 +1,15 @@
+/**
+ * One email entry of a Staffbase user, as embedded in the `emails` array of the
+ * user read endpoints.
+ *
+ * Grounded in a full-population prod sweep (49,215 users): entries carry
+ * `primary` and `providerID`, where `providerID` identifies the source that
+ * supplied the address (e.g. the SSO/identity provider or `staffbase`). `value`
+ * is optional - one entry in the whole population lacked it.
+ */
+export interface UserEmail {
+    value?: string;
+    primary: boolean;
+    providerID: string;
+}
+//# sourceMappingURL=UserEmail.d.ts.map

package/dist/src/types/user/UserEmail.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserEmail.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserEmail.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AACH,MAAM,WAAW,SAAS;IACxB,KAAK,CAAC,EAAE,MAAM,CAAA;IACd,OAAO,EAAE,OAAO,CAAA;IAChB,UAAU,EAAE,MAAM,CAAA;CACnB"}

package/dist/src/types/user/UserName.d.ts

@@ -0,0 +1,13 @@
+/**
+ * The structured user name returned by the Staffbase user read endpoints.
+ *
+ * Unlike the write side (where `userName` is a plain string), the read shape is
+ * an object. Grounded in a prod sweep (2000 users): every user carried both
+ * `value` and `providerID`, where `providerID` identifies the source that
+ * supplied the user name (e.g. the SSO/identity provider or `staffbase`).
+ */
+export interface UserName {
+    value: string;
+    providerID: string;
+}
+//# sourceMappingURL=UserName.d.ts.map

package/dist/src/types/user/UserName.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserName.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserName.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,MAAM,WAAW,QAAQ;IACvB,KAAK,EAAE,MAAM,CAAA;IACb,UAAU,EAAE,MAAM,CAAA;CACnB"}

package/dist/src/types/user/UserProfile.d.ts

@@ -0,0 +1,28 @@
+import { UserAvatar } from './UserAvatar';
+/**
+ * The profile block of a Staffbase user, returned by the user read endpoints.
+ *
+ * The Staffbase user model lets each tenant define arbitrary profile fields, so
+ * this is an open record rather than a fixed shape. Grounded in a prod sweep
+ * (2000 users): the great majority of fields are tenant-defined string
+ * attributes (department/job/location codes, etc.), so the index signature
+ * carries `string`. Two structured fields recur and are typed explicitly:
+ * `avatar` and `profileHeaderImage`, both {@link UserAvatar} rendition sets.
+ *
+ * The well-known string fields below mirror the spec `UserProfile` (the values
+ * the platform mirrors from the top-level user fields). All are optional - they
+ * appear only when populated for a given user/tenant.
+ */
+export interface UserProfile {
+    avatar?: UserAvatar;
+    profileHeaderImage?: UserAvatar;
+    firstName?: string;
+    lastName?: string;
+    department?: string;
+    location?: string;
+    position?: string;
+    phoneNumber?: string;
+    publicEmailAddress?: string;
+    [field: string]: string | UserAvatar | undefined;
+}
+//# sourceMappingURL=UserProfile.d.ts.map

package/dist/src/types/user/UserProfile.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserProfile.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserProfile.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,cAAc,CAAA;AAE9C;;;;;;;;;;;;;GAaG;AACH,MAAM,WAAW,WAAW;IAC1B,MAAM,CAAC,EAAE,UAAU,CAAA;IACnB,kBAAkB,CAAC,EAAE,UAAU,CAAA;IAC/B,SAAS,CAAC,EAAE,MAAM,CAAA;IAClB,QAAQ,CAAC,EAAE,MAAM,CAAA;IACjB,UAAU,CAAC,EAAE,MAAM,CAAA;IACnB,QAAQ,CAAC,EAAE,MAAM,CAAA;IACjB,QAAQ,CAAC,EAAE,MAAM,CAAA;IACjB,WAAW,CAAC,EAAE,MAAM,CAAA;IACpB,kBAAkB,CAAC,EAAE,MAAM,CAAA;IAC3B,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,GAAG,UAAU,GAAG,SAAS,CAAA;CACjD"}

package/dist/src/types/user/UserRecoveryCode.d.ts

@@ -0,0 +1,17 @@
+/**
+ * The account-recovery code descriptor of a Staffbase user, returned by the
+ * user read endpoints only for users that have one set.
+ *
+ * SENSITIVE: `plain` is the recovery code value - never log it. Grounded in a
+ * prod sweep: `recoveryCode` appeared on a small minority of users (~3 of 300),
+ * always carrying `plain`; `expires` (a unix-millis expiry) was present on a
+ * subset.
+ *
+ * Note: on the write side (`CreateUser`/`UpdateUser`) `recoveryCode` is a plain
+ * string; the read shape is this object.
+ */
+export interface UserRecoveryCode {
+    plain: string;
+    expires?: number;
+}
+//# sourceMappingURL=UserRecoveryCode.d.ts.map

package/dist/src/types/user/UserRecoveryCode.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserRecoveryCode.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserRecoveryCode.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,MAAM,WAAW,gBAAgB;IAC/B,KAAK,EAAE,MAAM,CAAA;IACb,OAAO,CAAC,EAAE,MAAM,CAAA;CACjB"}

package/dist/src/types/user/UserRole.d.ts

@@ -0,0 +1,12 @@
+/**
+ * The role descriptor of a Staffbase user, as embedded in the user read
+ * endpoints.
+ *
+ * Grounded in a prod sweep (2000 users): every user carried a `role` object
+ * with a `type` string (e.g. `admin`, `user`). Matches the spec
+ * `SingleUserWithAvatar.role` shape.
+ */
+export interface UserRole {
+    type: string;
+}
+//# sourceMappingURL=UserRole.d.ts.map

package/dist/src/types/user/UserRole.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserRole.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserRole.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,MAAM,WAAW,QAAQ;IACvB,IAAI,EAAE,MAAM,CAAA;CACb"}

package/dist/src/types/user/UserSecret.d.ts

@@ -0,0 +1,20 @@
+/**
+ * The access-code / secret descriptor of a Staffbase user, returned by the user
+ * read endpoints only for users that have one set.
+ *
+ * SENSITIVE: this is account-recovery material - never log it. Grounded in a
+ * prod sweep: `secret` appeared on a small minority of users (~8 of 300). The
+ * read shape never exposes the secret value itself; the bulk of items carried
+ * just `expires` (a unix-millis expiry). A single-read additionally exposed a
+ * `links.recovery` HATEOAS-style link, modeled here as optional.
+ */
+export interface UserSecret {
+    expires: number;
+    links?: {
+        recovery?: {
+            href: string;
+            method: string;
+        };
+    };
+}
+//# sourceMappingURL=UserSecret.d.ts.map

package/dist/src/types/user/UserSecret.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserSecret.d.ts","sourceRoot":"","sources":["../../../../src/types/user/UserSecret.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AACH,MAAM,WAAW,UAAU;IACzB,OAAO,EAAE,MAAM,CAAA;IACf,KAAK,CAAC,EAAE;QACN,QAAQ,CAAC,EAAE;YACT,IAAI,EAAE,MAAM,CAAA;YACZ,MAAM,EAAE,MAAM,CAAA;SACf,CAAA;KACF,CAAA;CACF"}