KIZAMI

Appearance

Documentation

Documentation / @kizami/db / getOrCreateTenantWorkPolicyByKind

Function: getOrCreateTenantWorkPolicyByKind() ​

getOrCreateTenantWorkPolicyByKind(db, params): Promise<{ createdAt: number; id: string; name: string; tenantId: string; }>

Defined in: packages/db/src/queries/work-policies.ts:142

テナントの work_policy を「kind(制度種別)」で検索し、無ければ新規作成する (メンバー個別の労働時間制割当、2026-08-23 追加)。

getOrCreateTenantWorkPolicy(上記、名前ベース)との関係: v0.1〜v0.2 は「テナントに ポリシー CRUD UI を持たせない」方針のため、個別割当も専用 UI を新設せず「kind ごとに 高々1本の共有ポリシーを get-or-create し、割当は kind の選択として表現する」設計にした (docs 上の判断点)。名前ベースの既存関数は GET/POST /settings/work-policy 専用のまま残し (そちらは「テナントに work_policy が1件」という前提を崩さない)、本関数はそれとは別に 「kind ごとに1件」という新しい前提を持つ。両者が同じ work_policies 行を指す運用も起こり うる(例: flex は既存の "標準" ポリシーの最新版がたまたま flex ならそのまま再利用される)。 これは意図的な仕様であり、"標準" ポリシーの kind を GET/POST /settings/work-policy 側で 後から切り替えると、本関数経由で flex 割当されたユーザーにも影響する (work_policy_versions.kind は版であり、ポリシーIDに紐づく全ユーザー共通のため)。

「どの work_policy が指定 kind に対応するか」の判定は、work_policy ごとの最新版 (effectiveFrom が最大の行)の kind で行う(現在の実効値ではなく最新版 — 将来日の版が 既にあればそれを指すのが自然なため。買い切り関数なので日付境界の解決は不要)。

無ければ work_policies 行 + 初版(work_policy_versions、effectiveFrom = "1970-01-01" の 起点版)を作る。getOrCreateTenantWorkPolicy と異なり初版までこの関数が作る理由: 呼び出し側(POST /members/:id/work-policy)は「割当は必ずどこかの日付から有効」を前提に 即座に assignUserWorkPolicy を呼ぶため、版が無いまま返すと buildSettingsTimeline が 解決不能で例外になる(既存の getOrCreateTenantWorkPolicy はその後に呼び出し側が明示的に insertWorkPolicyVersion を呼ぶ前提の薄い get-or-create だが、本関数は「割当可能な状態」まで 一括で保証する)。起点日を "1970-01-01" にするのは、既存のシード・テストが使う起点日と同じ 規約に合わせるため(どんな過去日の照会が来ても必ず解決できる)。

Parameters ​

db ​

Database | SQLiteTransaction<"async", ResultSet, schema, ExtractTablesWithRelations<schema>>

params ​

GetOrCreateTenantWorkPolicyByKindParams

Returns ​

Promise<{ createdAt: number; id: string; name: string; tenantId: string; }>