v0.2.0:15 — Multi-draft tier authoring + custom durations on draft cards

Two papercut fixes for the policy create flow:

1. Multi-draft survival. Previously, committing one draft tier card
   triggered a full grid reload via onMutate(), wiping any sibling
   drafts the operator had open. Now the commit callback receives the
   saved policy and replaces ONLY that draft's grid slot with a
   finalized tier card — sibling drafts keep their input state intact.
   Author Creator / Pro / Patron in parallel and click Create on each
   as it's ready, in any order.

2. Custom duration on draft cards. The Duration dropdown gains a
   "Custom (days)" option at the bottom; selecting it reveals a number
   input. On submit, days * 86400 = seconds is what gets sent. Matches
   the Edit-policy modal's existing custom pattern (which is in raw
   seconds); the draft uses days because day-based input is friendlier
   for the cadences operators actually pick.

UI-only release. No daemon code changes, no schema.
This commit is contained in:
Grant
2026-05-11 11:38:47 -05:00
parent 519fa1a8e6
commit 2789d1da1f
2 changed files with 51 additions and 7 deletions
+11 -1
View File
@@ -58,6 +58,16 @@ const RELEASE_NOTES = [
// in RELEASE_NOTES above (the milestone). Subsequent revisions
// append here.
const ROUTINE_NOTES = [
'0.2.0:15 — **Multi-draft tier authoring + custom durations on draft cards.** Small admin-UI release that fixes two papercuts from authoring fresh policies side-by-side.',
'',
'**Multi-draft survival.** Previously, committing one draft tier (clicking Create on a side-by-side draft card) reloaded the whole Policies tab — which wiped any other drafts the operator had open. Now the commit replaces ONLY that draft\'s grid slot with a finalized tier card; sibling drafts keep their in-progress input state untouched. Author Creator, Pro, Patron in parallel and click Create on each as it\'s ready, in any order.',
'',
'**Custom duration on draft cards.** The Duration dropdown on the draft tier card now has a "Custom (days)" option at the bottom. Selecting it reveals a number input; on submit, days × 86400 seconds is what gets sent. Matches the same pattern the Edit-policy modal has had (in raw seconds) — bringing it to the create flow so operators don\'t have to "create then immediately edit" for non-standard durations.',
'',
'**Test count: 87** (UI-only release).',
'',
'**Upgrade path.** v0.2.0:14 → v0.2.0:15 is a drop-in. No schema, no SDK, no behavior change for buyers.',
'',
'0.2.0:14 — **Product entitlements catalog bug fix + drag-and-drop tier ordering.** One real bug fix that was silently breaking operator workflows, plus a UX rework of how tier ranks get set.',
'',
'**Bug fix: product entitlements catalog reads.** Every SELECT against the `products` table in repo.rs was missing the `entitlements_catalog_json` column. The PATCH handler wrote the catalog correctly, but every read returned it as null — so admin UI edits silently appeared to drop on the floor (operator adds entitlements, clicks Save, re-opens the editor, entitlements are gone). The data was always in the DB; only the API was blind to it. Now all four product SELECTs include the column. Net effect: catalog edits persist correctly; the bubble-picker on policy create / edit forms populates from the parent product\'s catalog.',
@@ -290,7 +300,7 @@ const ROUTINE_NOTES = [
].join('\n\n')
export const v0_2_0 = VersionInfo.of({
version: '0.2.0:14',
version: '0.2.0:15',
releaseNotes: { en_US: ROUTINE_NOTES },
// No on-disk transformation needed — v0.2.0:0 is a label change.
// SQLite-level migrations live separately under