@sanity/workflow-studio-plugin 0.24.0 → 0.26.0

package/CHANGELOG.md

@@ -1,5 +1,60 @@
 # @sanity/workflow-studio-plugin
 
+## 0.26.0
+
+### Patch Changes
+
+- @sanity/workflow-components@0.26.0
+  - @sanity/workflow-diagram@0.26.0
+  - @sanity/workflow-engine@0.26.0
+  - @sanity/workflow-react@0.26.0
+  - @sanity/workflow-studio@0.26.0
+
+## 0.25.0
+
+### Minor Changes
+
+- e4c74be: Two new UI telemetry events cover the abort gesture, pairing the way the start dialog's do: `Editorial Workflows Studio Plugin Abort Dialog Opened` and `Editorial Workflows Studio Plugin Abort Dialog Submitted`, so the gap between them is how often an editor opens an irreversible verb's confirm and backs out. The submitted event carries an `outcome` of `aborted`, `already-settled` or `unconfirmed` rather than a success flag — an instance that reached a terminal state while the confirm was open is a successful no-op, and a rejection proves only that the gesture didn't finish, since the engine commits the abort before draining condemned children. The attempt emits, so a retry after a rejection emits again, while a confirm held shut by a blank reason emits nothing. Neither event carries a surface: abort is confined to the instance detail view.
+
+  Every payload enum in the plugin's event catalog is now a tuple its type derives from, collected in `PAYLOAD_DOMAINS`, and the vocabulary pin test freezes those values beside the event names and versions. Downstream groups and filters on payload values, so renaming or removing one breaks a query as surely as an edited event name — the catalog states that changing a domain bumps the event's `version`, and the pin puts that step in the diff.
+
+- 469cb76: **BREAKING:** the activity row's date control speaks only for a declared deadline (`dueDate` / `dueDatetime`). An activity whose only dates are plain `date` / `datetime` shows nothing in the row's date slot — no editable chip, and no muted committed date either; those fields stay titled in the activity's detail dialog. Rows that previously carried a chip for a plain date lose it. The control is an unlabeled calendar glyph with no room to say which field it picked, and deploy caps a scope at one due-\* entry, so only that kind can stand for a row's date without a caption. The Workflows tool's Date filter is unaffected — it matches ANY date-family value a task carries, which is the one place "does a date on this row fall on this day" is genuinely the question.
+
+  Every activity row surface carries the control: the Workflows tab's stage panel, the tool's instance detail, the For me tab, and the tool's task rows. The row component owns both inline controls — date and assignee — from one shared per-row derivation, so a surface cannot offer an editor different affordances for the same activity depending on where they meet it.
+
+- cd00bc2: **BREAKING:** Most of the Workflows tool's addresses change, and existing bookmarks break in two different ways. The retired tab segments `…/workflows/definitions`, `…/workflows/tasks` and `…/workflows/documents` still reach the tool: they name no page, so they render the landing and are replaced with its address. The two-segment deep links — a workflow's board at `…/workflows/documents/<name>` and a definition's detail at `…/workflows/definition/<name>` — match no route at all, so the tool never opens on them. Two addresses are unchanged: **For me** (`…/workflows/for-me`) and a run's detail (`…/workflows/instance/<id>`).
+
+  Reshape the tool around the workflow: the deployed catalog becomes the **Workflows** landing tab at `/workflows/overview`, the task list keeps its content under the label **All documents** at `/workflows/all-documents`, and each workflow owns its own pages, switched by a strip on the page itself — its documents over its stages at `/workflows/overview/<name>` and its definition at `/workflows/overview/<name>/definition`. A workflow's pages nest under the landing segment, so a workflow named after a tab addresses its own page rather than the tab.
+
+  Every page now has exactly one address: the landing writes its own segment like any other tab, and a URL naming no page shows the landing while replacing the address. The tool header drops its title row — the tab strip and the start button share one row.
+
+  The landing lists workflows as cards in a fluid grid rather than table rows, and a workflow's page carries its own header: the workflow picker naming the page, over the strip switching between the workflow's documents and its definition. An address naming no deployed workflow says so and points at the picker; a Studio with nothing deployed at all says that instead, since the picker has nothing to offer.
+
+  A workflow's documents page lays its runs out over the stages as columns — one lane per stage, divided by hairlines on a muted ground, with fades marking board that continues past either edge. A card now SELECTS rather than links out: it carries the document's title and how many of that run's own activities are still open, and selecting one opens a **Workflow details** panel beside the board, whose sections — the document, the stages, managing the workflow, and its history — each carry a heading. Within a page, nothing but the panel's own close clears a selection; moving to another of the workflow's pages starts with nothing open.
+
+  The panel slides in from the page's edge as the board gives way, and out again the same way. Its left edge is a grip: drag it to resize between 320px and 720px (arrow keys and Home/End when the edge has focus), or click it to close. The width is remembered per engine resource. A window resize leaves it alone unless the window becomes narrower than the panel, in which case the panel takes the whole row rather than overflowing it with its close button off the edge; the reader's own width returns when the room does. A reader whose system asks for reduced motion gets the panel without the slide.
+
+  A run's history feed now rests at its newest six entries, with the remainder behind **Show all history**, and every history row reads muted including the actor's name. This applies to the instance detail wherever it is opened — the panel above and the unchanged `…/workflows/instance/<id>` address alike.
+
+  A card's count is that run's own open activities. Work inside a sub-workflow is not included — a spawned child is its own run under its own definition, and a page reads one workflow.
+
+  Telemetry: `Tool Opened` is version 2 — the `tab` domain is the reshaped strip's (`overview`, `all-documents`, `for-me`), retiring `definitions`, `documents`, `tasks` and `not-found` while `for-me` carries over unchanged; `Board Workflow Selected` is version 2 (`via` dropped, since a page's address always names its workflow); `Document Link Clicked` is version 2, where the `source` value `board-card` becomes `detail-subject` — a card no longer carries a document link, and the affordance still emitting is the instance detail's subject preview. `Instance Detail Viewed` is unchanged in shape but now also fires when a card is selected, since the panel renders that same detail. `Board Layout Changed` is retired along with its `boardLayout` payload domain: the documents page is columns-only, so there is no layout to switch. Its stored preference key (`sanity.workflows.tool.board-layout:<engine resource>`) is no longer read; nothing clears it from a reader's browser.
+
+### Patch Changes
+
+- 884a3c4: The start dialog's Start-button gate and "(Required)" label now honor a definition field's own `required` flag instead of gating every single-value input-sourced entry unconditionally. Previously, an optional entry (for example a `release.ref` seeded conditionally through `spawn.with`) showed "(Required)" and held Start disabled even though the engine itself only enforces entries declared `required: true` — this made the dialog stricter than an actual start, with no way to author around it. The gate now matches which entries the engine treats as required, including for collection-kind entries (`array`, `assignees`, `doc.refs`): a collection marked `required: true` gates until it has at least one row, the same selection the engine's own `missingRequiredInputs` makes.
+
+  This widens what Start allows: any `input`-sourced entry declared without `required: true` no longer gates Start in any start dialog. The notable case is `subject` — two in-repo reference definitions in `@sanity/workflow-examples` (a private, unpublished package), `url-draft` and `editable-assignment`, declare `subject` `input`-sourced with no `required`, so in the Workflows tool's workflow-first start mode, Start is now enabled with no document picked and the instance commits without a subject. A `subject` entry declared this way no longer gates Start; declare it `required: true` to keep the dialog blocking until a document is picked.
+
+- 2eaadb3: The Workflows tool's Documents tab now opens on the workflow you had open. Selecting Documents from a definition's page addresses that definition's board instead of dropping the selection and landing on the first deployed workflow by title.
+- Updated dependencies [177d600]
+- Updated dependencies [fc12989]
+  - @sanity/workflow-engine@0.25.0
+  - @sanity/workflow-components@0.25.0
+  - @sanity/workflow-diagram@0.25.0
+  - @sanity/workflow-react@0.25.0
+  - @sanity/workflow-studio@0.25.0
+
 ## 0.24.0
 
 ### Minor Changes

package/README.md

@@ -11,14 +11,16 @@ UI: a **workflow strip** above the editor form of mapped documents (the
 current stage, your task count, and a **Start workflow** button), and a
 **Workflows tab** next to the editor with the stage's activities and to-dos,
 where they fire actions, and a **Workflows tool** in the Studio navbar — the
-open tasks across the newest workflow instances (capped), the user's own cut
-of them, the deployed definitions catalog, one chosen workflow's documents
-grouped by stage (as side-by-side columns or a stacked list, at its own
-shareable address), and deep-linkable per-instance and per-definition detail
-views (the instance detail carries the full history feed). That detail view is also where a running workflow can be stopped: an
-**Abort workflow** button below the stage card, against a reason recorded in
-the workflow's history. Aborting is open to anyone who can act on the
-instance, and cannot be undone.
+deployed workflows as a landing catalog, the open tasks across the newest
+workflow instances (capped), the user's own cut of them, and a page per
+workflow carrying that workflow's documents laid out over its stages as
+side-by-side columns, beside its definition. Every one of those is a
+shareable address, as is the per-instance detail, whose history feed rests at
+its newest entries with the rest behind **Show all history**. The instance
+detail is also where a running workflow can be stopped: an **Abort workflow**
+button below the stage card, against a reason recorded in the workflow's
+history. Aborting is open to anyone who can act on the instance, and cannot be
+undone.
 
 Four ideas cover everything in this guide: