Catering tables: the spreadsheet becomes data the bakery can edit

The goodie box and catering prices arrived as a spreadsheet — Office, Parties and Weddings, each a few columns of sizes and prices with lines of baked goods underneath. This puts it behind /api/catering and makes every part of it editable at /admin, because the prices move and the spreadsheet's own last line says the tables are "mostly just an idea for people". A package is one table, its tiers are the columns, its rows are the lines, and a line holds one value per column. That alignment is why this is an aggregate rather than three tables edited separately: drop the middle column on its own and every remaining entry shifts one place left, so the Large box advertises the Medium box's contents at the Large price and nothing looks broken. CateringPackage#arrange takes a whole table, renumbers positions from the order it arrived in, and refuses an arrangement whose lines and columns disagree. Money owns prices — what "24", "$24" or "24.50" means and how it prints — so the browser never formats money and never multiplies it by 100 in floating point. Cents in the column, "$24" in the response. An empty price is "ask us", not zero. Seeded from the bakery's own wording. Shorthand is expanded ("4 dz cc or sc") and typos fixed, since customers read these lines; in the wedding table the labels and the values are offset in the source spreadsheet, so they are carried over literally and can be renamed in the admin. The lines that are named but never quantified keep their blank cells: dropping the blanks would shorten the line and shift everything after it. The public response leaves out a table with no columns or no lines — adding a table and filling it in are two separate acts, and the gap between them shouldn't put a bare heading on the live page. No public page renders any of this yet; this is the backend and the editor for it. Admin endpoints are @ConditionalOnProperty on SECURITY_MODE=OIDC like the rest, so a deployment with no identity provider has no price writes. 18 new tests: the seeded spreadsheet, the alignment invariant, money in both directions, and the HTTP surface the screen actually calls (including that /packages/order isn't read as a table id, and that a refusal arrives as a ProblemDetail sentence). Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-26 15:13:39 -05:00
parent d5103e44b9
commit 748b1cd59b
20 changed files with 2170 additions and 51 deletions
@@ -124,3 +124,75 @@ export const reorderCategories = (ids: number[]) =>

 export const deleteCategory = (id: number) =>
  send<{ ok: boolean }>(`/api/admin/categories/${id}`, 'DELETE');
+
+// --- goodie boxes & catering ------------------------------------------------
+
+/**
+ * A column of a catering table. `price` is already written the way it should be read ("$24") — the
+ * server owns money, both what a typed price means and how it prints — and is null for a column that
+ * doesn't state one. `id` is null only for a column the editor has just added and not yet saved.
+ */
+export interface CateringTier {
+  id: number | null;
+  label: string;
+  price: string | null;
+}
+
+/** A line of a catering table, with one entry per column, in column order — blanks included. */
+export interface CateringRow {
+  id: number | null;
+  label: string;
+  values: string[];
+}
+
+/** One table: "Office", "Parties", "Weddings". */
+export interface CateringTable {
+  id: number;
+  name: string;
+  blurb: string | null;
+  tiers: CateringTier[];
+  rows: CateringRow[];
+  /** The rules under this table: minimums, what can't be mixed. */
+  notes: string[];
+}
+
+export interface CateringMenu {
+  packages: CateringTable[];
+  /** Terms that apply to the page rather than to any one table. */
+  notes: string[];
+}
+
+/**
+ * A table as the editor left it, sent whole. It has to be whole: a column and the values beneath it
+ * only mean anything together, so moving or removing one has to carry its entries with it. The
+ * server rejects any table whose lines and columns disagree.
+ */
+export interface CateringTableEdit {
+  name: string;
+  blurb: string | null;
+  tiers: { id: number | null; label: string; price: string }[];
+  rows: { id: number | null; label: string; values: string[] }[];
+  notes: string[];
+}
+
+/** What a customer sees: finished tables only. */
+export const fetchCatering = () => get<CateringMenu>('/api/catering');
+
+/** What the editor sees: the same tables, including any they haven't finished filling in. */
+export const adminCatering = () => get<CateringMenu>('/api/admin/catering');
+
+export const addCateringTable = (name: string) =>
+  send<CateringTable>('/api/admin/catering/packages', 'POST', { name });
+
+export const saveCateringTable = (id: number, table: CateringTableEdit) =>
+  send<CateringTable>(`/api/admin/catering/packages/${id}`, 'PUT', table);
+
+export const deleteCateringTable = (id: number) =>
+  send<{ ok: boolean }>(`/api/admin/catering/packages/${id}`, 'DELETE');
+
+export const reorderCateringTables = (ids: number[]) =>
+  send<CateringTable[]>('/api/admin/catering/packages/order', 'PUT', { ids });
+
+/** The page's own footnotes: the full list, so removing one is an omission. */
+export const saveCateringNotes = (notes: string[]) =>
+  send<string[]>('/api/admin/catering/notes', 'PUT', notes);