@kernhq/module-hr 0.18.1 → 0.20.0

package/migrations/0012_rosters.sql

@@ -0,0 +1,163 @@
+-- Rosters: which shift a person works on a **date**.
+--
+-- `schedules` is a week that repeats for ever, keyed by weekday name. That is the right shape for an
+-- office and cannot express a factory: 4-on-4-off has no weekly period at all, so there is no
+-- `ScheduleWeek` of any length that describes one. These four tables answer the calendar instead.
+--
+-- * `roster_shifts` — Early, Late, Night. Named rather than inlined into every rotation because
+--   coverage groups by it: "Early" in two rotations has to be one column of one grid.
+-- * `roster_patterns` — a rotation, as a cycle of days and the date `days[0]` falls on. `days` is an
+--   array of arrays of shift ids; an empty entry is a planned rest day and two entries is a split
+--   shift. The cycle length is `jsonb_array_length(days)` and is deliberately not a second column.
+-- * `roster_assignments` — a person on a rotation, effective-dated, with a `cycle_offset` that puts
+--   two crews on one rotation out of phase.
+-- * `roster_overrides` — one day that differs, and nothing else. The whole reason a roster is not a
+--   schedule: a schedule change rewrites every day after it, and somebody covering one Tuesday needs
+--   one Tuesday changed.
+--
+-- **Nothing is expanded into rows.** What somebody works on a date is arithmetic from the anchor,
+-- the offset and the cycle. Generating a year of shifts per person is what makes a roster impossible
+-- to change afterwards: moving a crew forward one day becomes a bulk rewrite of thousands of rows
+-- with no way left to tell which of them a human had already corrected.
+--
+-- Additive throughout — four new tables and no change to anything that exists — so the image before
+-- this one reads the schema unchanged and a rollback needs no dump.
+--
+-- Generated by drizzle-kit from `src/server/schema.ts` and then given `if not exists` on every
+-- statement, plus the two things drizzle cannot express: the exclusion constraint and the RLS
+-- blocks. Drizzle keys applied migrations by content hash, so editing any file in this folder
+-- replays every file in it — and a module migration that throws takes down every module in the host
+-- service at boot, not only this one.
+CREATE TABLE IF NOT EXISTS "mod_hr"."roster_assignments" (
+	"id" uuid PRIMARY KEY DEFAULT uuidv7() NOT NULL,
+	"workspace_id" uuid NOT NULL,
+	"person_id" uuid NOT NULL,
+	"pattern_id" uuid NOT NULL,
+	"effective_from" date NOT NULL,
+	"effective_to" date,
+	"cycle_offset" integer DEFAULT 0 NOT NULL,
+	"created_at" timestamp with time zone DEFAULT now() NOT NULL
+);
+--> statement-breakpoint
+CREATE TABLE IF NOT EXISTS "mod_hr"."roster_overrides" (
+	"id" uuid PRIMARY KEY DEFAULT uuidv7() NOT NULL,
+	"workspace_id" uuid NOT NULL,
+	"person_id" uuid NOT NULL,
+	"business_date" date NOT NULL,
+	"shift_ids" jsonb DEFAULT '[]'::jsonb NOT NULL,
+	"note" text,
+	"created_by" uuid,
+	"created_at" timestamp with time zone DEFAULT now() NOT NULL,
+	"updated_at" timestamp with time zone DEFAULT now() NOT NULL
+);
+--> statement-breakpoint
+CREATE TABLE IF NOT EXISTS "mod_hr"."roster_patterns" (
+	"id" uuid PRIMARY KEY DEFAULT uuidv7() NOT NULL,
+	"workspace_id" uuid NOT NULL,
+	"name" text NOT NULL,
+	"anchor_date" date NOT NULL,
+	"days" jsonb DEFAULT '[]'::jsonb NOT NULL,
+	"archived_at" timestamp with time zone,
+	"created_at" timestamp with time zone DEFAULT now() NOT NULL,
+	"updated_at" timestamp with time zone DEFAULT now() NOT NULL
+);
+--> statement-breakpoint
+CREATE TABLE IF NOT EXISTS "mod_hr"."roster_shifts" (
+	"id" uuid PRIMARY KEY DEFAULT uuidv7() NOT NULL,
+	"workspace_id" uuid NOT NULL,
+	"name" text NOT NULL,
+	"code" text,
+	"start_time" text NOT NULL,
+	"end_time" text NOT NULL,
+	"break_minutes" integer DEFAULT 0 NOT NULL,
+	"grace_in_minutes" integer DEFAULT 0 NOT NULL,
+	"grace_out_minutes" integer DEFAULT 0 NOT NULL,
+	"color" text,
+	"archived_at" timestamp with time zone,
+	"created_at" timestamp with time zone DEFAULT now() NOT NULL,
+	"updated_at" timestamp with time zone DEFAULT now() NOT NULL
+);
+--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS "hr_roster_assign_idx" ON "mod_hr"."roster_assignments" USING btree ("workspace_id","person_id","effective_from");--> statement-breakpoint
+CREATE UNIQUE INDEX IF NOT EXISTS "hr_roster_override_uq" ON "mod_hr"."roster_overrides" USING btree ("workspace_id","person_id","business_date");--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS "hr_roster_patterns_ws_idx" ON "mod_hr"."roster_patterns" USING btree ("workspace_id","archived_at");--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS "hr_roster_shifts_ws_idx" ON "mod_hr"."roster_shifts" USING btree ("workspace_id","archived_at");--> statement-breakpoint
+
+-- ---------------------------------------------------------------------------------------------
+-- Two rotations may not be in force for one person on the same day.
+--
+-- The same constraint `schedule_assignments` waited five migrations for, and here from the day the
+-- table exists, because the failure it prevents is not theoretical: the resolver picks the
+-- assignment in force with `limit 1`, and with two rows in force it takes whichever the executor
+-- hands back first. On `schedule_assignments` that showed up as `scheduled_minutes` changing
+-- between one recomputation and the next on rows a locked payroll period had already been filed
+-- against — see 0006, which had to repair the data before it could add the constraint. There is
+-- nothing to repair here.
+--
+-- The `where` clause carries the same exception 0006 does: `daterange(from, to, '[]')` raises for a
+-- reversed pair rather than returning an empty range, so without it a backdated assignment would
+-- fail with a raw Postgres range error. Such a row is in force on no day at all — `inForceOn` needs
+-- `effective_from <= d` and `effective_to >= d` at once — so it cannot be the second rotation this
+-- constraint exists to prevent.
+--
+-- `add constraint` has no `if not exists`, hence the catalogue check. `btree_gist` is created in
+-- 0000, which is what lets a uuid sit beside a range under gist; a module reaching for a gist
+-- exclusion constraint without it fails on any clean database with "data type uuid has no default
+-- operator class", during the module's own migration, so the service does not start.
+do $$
+begin
+  if not exists (
+    select 1
+      from pg_constraint c
+      join pg_class t on t.oid = c.conrelid
+      join pg_namespace n on n.oid = t.relnamespace
+     where n.nspname = 'mod_hr'
+       and t.relname = 'roster_assignments'
+       and c.conname = 'hr_roster_assign_no_overlap'
+  ) then
+    alter table "mod_hr"."roster_assignments"
+      add constraint "hr_roster_assign_no_overlap"
+      exclude using gist (
+        "workspace_id" with =,
+        "person_id" with =,
+        daterange("effective_from", "effective_to", '[]') with &&
+      ) where ("effective_to" is null or "effective_to" >= "effective_from");
+  end if;
+end $$;--> statement-breakpoint
+
+-- ---------------------------------------------------------------------------------------------
+-- Row-level security for the four new tenant tables, in the same shape as 0001 and for the same
+-- reason: the API checks membership and permission first, and this is what is left when a query
+-- reaches the database another way. `create policy` has no `if not exists` at all, so each one is
+-- preceded by a `drop policy if exists` — without that pair, replaying this file throws.
+alter table "mod_hr"."roster_shifts" enable row level security;--> statement-breakpoint
+alter table "mod_hr"."roster_shifts" force row level security;--> statement-breakpoint
+drop policy if exists "roster_shifts_ws_isolation" on "mod_hr"."roster_shifts";
+--> statement-breakpoint
+create policy "roster_shifts_ws_isolation" on "mod_hr"."roster_shifts"
+  using (workspace_id::text = current_setting('app.workspace_id', true))
+  with check (workspace_id::text = current_setting('app.workspace_id', true));--> statement-breakpoint
+
+alter table "mod_hr"."roster_patterns" enable row level security;--> statement-breakpoint
+alter table "mod_hr"."roster_patterns" force row level security;--> statement-breakpoint
+drop policy if exists "roster_patterns_ws_isolation" on "mod_hr"."roster_patterns";
+--> statement-breakpoint
+create policy "roster_patterns_ws_isolation" on "mod_hr"."roster_patterns"
+  using (workspace_id::text = current_setting('app.workspace_id', true))
+  with check (workspace_id::text = current_setting('app.workspace_id', true));--> statement-breakpoint
+
+alter table "mod_hr"."roster_assignments" enable row level security;--> statement-breakpoint
+alter table "mod_hr"."roster_assignments" force row level security;--> statement-breakpoint
+drop policy if exists "roster_assignments_ws_isolation" on "mod_hr"."roster_assignments";
+--> statement-breakpoint
+create policy "roster_assignments_ws_isolation" on "mod_hr"."roster_assignments"
+  using (workspace_id::text = current_setting('app.workspace_id', true))
+  with check (workspace_id::text = current_setting('app.workspace_id', true));--> statement-breakpoint
+
+alter table "mod_hr"."roster_overrides" enable row level security;--> statement-breakpoint
+alter table "mod_hr"."roster_overrides" force row level security;--> statement-breakpoint
+drop policy if exists "roster_overrides_ws_isolation" on "mod_hr"."roster_overrides";
+--> statement-breakpoint
+create policy "roster_overrides_ws_isolation" on "mod_hr"."roster_overrides"
+  using (workspace_id::text = current_setting('app.workspace_id', true))
+  with check (workspace_id::text = current_setting('app.workspace_id', true));