@sanity/workflow-studio-plugin 0.29.0 → 0.31.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,129 @@
1
1
  # @sanity/workflow-studio-plugin
2
2
 
3
+ ## 0.31.0
4
+
5
+ ### Minor Changes
6
+
7
+ - ae876ad: The Workflows tool Overview table and board cards now say how late a run is instead of only that it is late. A run with one overdue task shows a calendar glyph and a compact span in caution — `4d` — and a run with several shows the count instead (`3 tasks`). Hovering the mark opens the same stage-tasks panel the row's people open when a listed human task is late, and that panel now carries the same calendar and span beside each task title, so the row's figure can be traced to the task it counts. Lateness that sits on an automation has no row in that panel, even if other human tasks are still open, and keeps a sentence: `3 tasks overdue — the longest by 4d`.
8
+
9
+ A run that cannot continue now wears a critical disc rather than a bare outline glyph, and its hover text names the cause instead of restating that the document is blocked: a task sent back is quoted by title, an automation that reported a failure reads `Automation “Notify legal” failed`, and one that was claimed and never reported back reads `Automation “Notify legal” didn’t finish` — the two are no longer told as the same fault.
10
+
11
+ The Tasks column now fits as many assignee groups as the column is actually wide enough for, rather than always three, and keeps room for the `+N` counter. Previously a row whose tasks were held by several people pushed the counter past the column's edge, where it lost its number and left a stray `+` sitting against the next column; a wide window now also fills the column it was given instead of stopping at three groups.
12
+
13
+ **No upgrade action required.** Both marks are derived from the same committed instance state as before; no definition, stored field, or configuration changes.
14
+
15
+ **Docs impact:** Update the Workflows tool guide wherever it pictures or describes the Overview attention column and the board cards' marks — the overdue mark is now a calendar with a span rather than a warning triangle, it opens the stage-tasks panel, and the blocked mark names its cause.
16
+
17
+ - b593a51: The Workflows tool Overview Open runs table labels its people column **Tasks**, and each cell (and each board card) groups holders by the current stage's human activities instead of flattening them into one stack. Overlap means one task, a gap means the next, a dashed circle with a person glyph means nobody is holding that task, and hover lists every task in the stage. Inside a mixed group, role squares sit before people.
18
+
19
+ Automated activities are left out of the cell only when the deployed workflow the run is pinned to says so. A run pinned to an older version, or one whose workflow the catalog no longer carries, shows all of its open activities as tasks rather than risking a hidden one.
20
+
21
+ The run scope picker beside the workflow picker now rests on the surrounding surface — white in a light scheme, the panel colour in a dark one — instead of a filled grey chip, and keeps its outline and hover feedback.
22
+
23
+ **No upgrade action required.**
24
+
25
+ **Docs impact:** Update the Workflows tool guide wherever it names the Overview Assignees column or implies a run itself has assignees.
26
+
27
+ - 7832486: The Workflows tool Open runs header now keeps the applied filter chips and **Clear filters** at the right of the row, next to the **Add filter** button and the Table/Board toggle, instead of at the left beside the workflow and scope pickers. The workflow picker and the open/closed scope picker stay on the left. Applied filters grow leftward from the **Add filter** button, so adding a chip no longer moves that button, and a row too wide for the viewport wraps the filter group rather than pushing the pickers off the line.
28
+
29
+ **No upgrade action required.** Filter behaviour, the saved view, and the URL parameters that address a filtered view are unchanged.
30
+
31
+ **Docs impact:** Update any Workflows tool guide screenshot or prose that places the applied filters beside the workflow picker at the left of the Open runs header.
32
+
33
+ ### Patch Changes
34
+
35
+ - ff72ece: Reader-model errors and the Studio Workflows tool now link to the canonical `/docs/workflows` documentation routes.
36
+
37
+ **No upgrade action required.** Permanent redirects preserve the former `/docs/editorial-workflows` URLs.
38
+
39
+ **Docs impact:** Publish the Workflows documentation at `/docs/workflows` and retain permanent redirects from every previously published `/docs/editorial-workflows` route.
40
+
41
+ - Updated dependencies [ff72ece]
42
+ - @sanity/workflow-engine@0.31.0
43
+ - @sanity/workflow-components@0.31.0
44
+ - @sanity/workflow-diagram@0.31.0
45
+ - @sanity/workflow-react@0.31.0
46
+ - @sanity/workflow-studio@0.31.0
47
+
48
+ ## 0.30.0
49
+
50
+ ### Minor Changes
51
+
52
+ - 21bb1d2: The Workflows tool Overview's **Add filter** button moves to the right of the filter row, beside the Table | Board toggle. It used to sit after the filter chips, so every applied or removed clause changed how far along the row it was drawn and the button walked out from under the pointer that had just used it; from its fixed right-hand cluster it stays put however many chips are applied. **Clear filters** stays with the chips it clears, on the left of the row.
53
+
54
+ **No upgrade action required.** Only the control's position changes — filter behaviour, the chips, and the `filters` address param are untouched.
55
+
56
+ **Docs impact:** Refresh Workflows tool guide screenshots and any prose that places Add filter after the filter chips.
57
+
58
+ - c5cc006: **BREAKING:** The Workflows tool Overview's run lifecycle is **Open runs** / **Closed runs**, not Active / Concluded. Closed writes `scope=closed` in the address; open stays the omitted default. Former `scope=concluded` (and any other unrecognized scope value) opens Open runs — it is not kept as an alias. The closed table's ended-date column is **Closed**. For me counts **open runs**. The Definitions catalog's count column is **Open runs**. Tasks on For me stay Open / Completed.
59
+
60
+ Re-copy any shared Closed-run links after upgrade. Open-run links that omitted `scope` keep working.
61
+
62
+ **Docs impact:** Update the Workflows tool guide wherever it names Active / Concluded or `scope=concluded`.
63
+
64
+ - a3a8dc0: Assignee tooltips tell duplicate display names apart by login provider: when two members share a name, each gets a "(Google)" / "(GitHub)" / "(SAML/SSO)" suffix in the run table's assignee hints and the activity rows' member lists — a unique name stays bare, and a provider without a display title shows its raw value. `@sanity/workflow-components` gains the `providerTitle(provider)` export backing this: the provider's display name from the same classification the avatar badge draws, `undefined` for providers with no mark. **No upgrade action required.**
65
+
66
+ **Docs impact:** None — tooltip presentation detail below the documented surface; `providerTitle` joins the components reference if that package's API is documented.
67
+
68
+ - 90207dc: **BREAKING:** `assertReaderModelAcknowledgement` now requires `{requiredMinReaderModel, context?}` instead of a context string, and `ReaderModelAcknowledgementError` accepts its optional context through `{context}`. The Blueprint package's `AcknowledgedDeployment` type moves to the engine as `AcknowledgedWorkflowDeployment`; update imports and use that shared name. Assignment-valued fields can now declare a non-empty `roles` list that limits newly written assignees. Existing fields without `roles` stay unconstrained, retain reader floor 4, and continue deploying with `expectedMinReaderModel: 4`; installing this release requires no coordinated rollout or configuration change.
69
+
70
+ Before adding `roles`, upgrade every Studio, CLI, MCP server, Function, and other runtime that shares the affected workflow resource, then change that deployment's literal `expectedMinReaderModel` to `8`. MCP deployments pass the same reviewed literal as the optional `expectedMinReaderModel` tool argument. Definitions and instances carrying the facet require reader model 8. User assignees qualify through direct roles or the definition's role aliases, while collective role assignees must literally match one configured role. Studio assignment controls, including manual start, auto-start, and assignees nested in to-do rows, offer only eligible choices while retaining stale current values so editors can remove or replace them. Constrained pickers name the active eligible roles and distinguish an empty eligible set from a search with no matches. Top-level plural and composite edits retain no more occurrences of a stale assignment at each declared assignment location than the previous value contained; removal and reordering therefore work, while an added copy is a new assignment and must qualify. Direct singular replacements and every assignment present in an `updateWhere` fragment remain strict. Each engine verb uses one member-directory snapshot across retries, cascade hops, and spawned children, then the next verb reads current membership.
71
+
72
+ Malformed project-member and project-user directory responses now fail loudly instead of treating bad rows or role records as missing users, and actor resolution reports those failures as `inaccessible`, so integrations can distinguish directory failures from absent membership.
73
+
74
+ CLI `start` and `definition delete` no longer apply the definition-submission acknowledgement gate; deploy, check, dry-run, definition diff, Blueprint provision, and engine definition APIs still validate the selected definitions' required floor.
75
+
76
+ No reader-fleet rollout or deployment-literal change is required for existing definitions that do not use `roles`.
77
+
78
+ **Docs impact:** Update the assignment field reference and authoring examples for `roles`, distinguish eligibility from editability, action permission, and literal queue ownership, and add the model-8 conditional adoption sequence to the prerelease rollout guide.
79
+
80
+ - a3a8dc0: **BREAKING:** The Workflows tool's information architecture is reshaped around work. The old contract — a definitions-catalog landing ("Workflows"), an "All documents" task list, and a dedicated per-run page at `/instance/<id>` — is replaced. The tool now lands on **Overview**, a cross-workflow run table: one row per run across every workflow, sortable columns, a trailing attention column naming Blocked and Overdue runs, a workflow picker plus composable filter clauses over assignee (Unassigned and Current user are among its values — Current user is stored as an alias and resolved to whoever views the address), stage (offered while the picker scopes one workflow), release (No release is one of its values, matched against the run’s pinned Content Release perspective), and attention, every clause rendered as a segmented chip — facet, a chosen operator (is, is not, is any of, is none of) deciding whether its checkmarked value list picks one value or toggles many, per-value counts, clear — edited in place, plus a count line naming the displayed blocked and overdue counts as one-click filters, and an Open/Closed scope whose closed rows name their outcome — the terminal stage they finished in, or Aborted. A Table | Board display toggle rides the row's far edge: picking Board scopes the view to one deployed workflow (the picker's first when unscoped) and lays that workflow's runs on its stage board, sharing the table's selection and detail panel, with the display carried in the address (`display=board`). **For me** becomes the reader's own run table — the same columns, cut to runs where the reader holds open work directly or through a role, with no picker or filter chrome. **Definitions** hosts the deployed catalog as a table — workflow title and description, deploy stamp, version, an open-run count linking to the Overview scoped to that workflow, and a trailing issue glyph — replacing the card grid and its assigned-to-you banding, and a workflow's page moves from `/overview/<name>` to `/definitions/<name>` as a single definition page — facts, stage diagram, setup issues — whose open-count row is a door to the Overview filtered to that workflow. The workflow page's separate Documents board page and its page strip retire; the Overview's Board display is the board's home.
81
+
82
+ A run no longer has a page of its own: selecting a row on either tab opens the run's detail in a sliding, drag-resizable panel beside the list, with previous/next controls walking the displayed order, an expand-to-dialog control, and the selection carried in the address (`run=`), so a shared link opens on its run, in place. The whole view lives in the tool's search params, named as full words — `workflow`, `filters`, `display`, `run`, and `scope` — so a copied address reproduces the exact cut, and a param the tool does not recognize reads as the default view. The `workflow` intent still deep-links a run; it resolves to the Overview with that run selected, adopting the run's own lifecycle scope — a link to a closed or aborted run opens the Closed view with it selected. Bookmarks to `/all-documents` or `/instance/<id>` land on the Overview. The task list's orphan handling retires with it: the tool no longer detects instances whose subject documents were deleted or offers to settle them in bulk — a document-delete Function (see the cookbook's deleted-subject recipe) remains the reliable path.
83
+
84
+ **No upgrade action required** beyond re-saving bookmarks: plugin configuration and exports are unchanged. The "Tool Opened" telemetry event bumps to version 3 — `overview` changes referent from the catalog to the run table, `definitions` returns naming the catalog, and `all-documents` retires, so `overview` counts are not one series across versions 2 and 3. "Board Workflow Selected" bumps to version 3: its emission moves to the Overview's board display, so its counts are likewise not one series across versions 2 and 3. "Task Filters Applied" retires with the task list and emits nothing from this version on. "Action Control Used" (version 3), "Field Control Used" (version 2), and "Activity Dialog Opened" (version 2) drop the retired `tool-task-list` value from their surface domains — each is likewise not one series across versions. "Document Link Clicked" (version 3) drops the retired `detail-title` and `doc-ref-chip` sources — the panel's title line no longer hosts a document chip, and the run surfaces' document faces render without linking.
85
+
86
+ **Docs impact:** The Workflows tool guide needs a rewrite around the new shape (an Overview | For me strip, with Definitions behind the title row's overflow and breadcrumb), the panel-based run detail replacing the instance page, and shareable filtered/selected addresses; screenshots of the catalog landing and the All documents tab are stale.
87
+
88
+ - a3a8dc0: The Workflows tool now reaches every run. The Overview table, the board, and the Definitions catalog read the progressively-hydrated preview stream instead of a 200-instance capped read: lists fill page by page until the whole partition is held (a "Loading workflows…" note discloses the gap while counts are still a floor), then stay fresh from the shared change feed. Display strings join from the deployed catalog rather than each run's pinned snapshot, so a workflow absent from the catalog shows raw names. The board cuts the shared stream client-side, retiring its per-workflow capped read and cap note. `workflowStudioPlugin` accepts `previewHydration: {pageSize?, interPageDelayMs?}` to tune or simulate hydration, `@sanity/workflow-studio` exports the `useWorkflowInstancePreviews` wrapper, and `useInstancePreviews` (workflow-react) accepts `interPageDelayMs`, a development throttle between hydration pages. No upgrade action required.
89
+
90
+ **Docs impact:** The Workflows-tool guide should drop the capped-read caveat and describe progressive hydration (counts grow until the stream drains); the plugin configuration reference gains `previewHydration`; the Studio adapter reference gains `useWorkflowInstancePreviews`; the reactive-core reference gains `interPageDelayMs` beside `useInstancePreviews`.
91
+
92
+ - a3a8dc0: The Workflows tool's run table and board lanes render virtualized: only the rows and cards near the viewport mount, with the remainder carried as scroll height, so scrolling long lists stays smooth as row counts grow. The table keeps its sticky header and semantic markup, scrolling inside its own viewport-bound container; each board lane windows its own card list. **No upgrade action required.**
93
+
94
+ **Docs impact:** None — rendering internals below the documented surface.
95
+
96
+ - b0b1550: **BREAKING:** Product-prefixed telemetry events now use `Workflows <event>` instead of `Editorial Workflows <event>`; `EditorialWorkflowsResource` is replaced by `WorkflowsResource`; and `defineWorkflows` now generates `workflows-<deployment name>` resource names instead of `editorial-workflows-<deployment name>`. Telemetry consumers matching the previous literals stop receiving events until updated, TypeScript consumers importing the previous Blueprint interface no longer compile, and an existing Blueprint stack that relies on the generated name treats the new default as a different resource identity.
97
+
98
+ Update telemetry dashboards, schemas, alerts, and queries to match the `Workflows` prefix; event suffixes, payloads, and versions are unchanged. Replace Blueprint imports with `WorkflowsResource`. Before deploying an existing Blueprint stack, either pass its recorded resource name explicitly or plan the detach-and-create migration to the new default. Workflows request-tag families and billing classification are unchanged.
99
+
100
+ Other user-facing package copy now uses the Workflows product name. No upgrade action is required for consumers that do not match telemetry event names or use the Blueprint package.
101
+
102
+ **Docs impact:** Rename the product throughout the public documentation, move the docs section to `/docs/workflows/*` with permanent redirects from every `/docs/editorial-workflows/*` path, and document the telemetry-prefix, `WorkflowsResource`, and Blueprint resource-name migrations in the telemetry reference, Blueprint guide, and release notes.
103
+
104
+ ### Patch Changes
105
+
106
+ - a8d4c90: The Workflows tool filter menus now darken an unchecked checkbox's outline when the pointer is over the box itself, so that click is distinguishable from clicking the rest of the row (which closes the menu). Empty boxes still appear only on row hover or when the value is already applied.
107
+
108
+ **No upgrade action required.**
109
+
110
+ **Docs impact:** None — this is a hover affordance on an existing filter control, not a new filter capability.
111
+
112
+ - Updated dependencies [a3a8dc0]
113
+ - Updated dependencies [210ca63]
114
+ - Updated dependencies [a3a8dc0]
115
+ - Updated dependencies [a3a8dc0]
116
+ - Updated dependencies [a3a8dc0]
117
+ - Updated dependencies [a3a8dc0]
118
+ - Updated dependencies [90207dc]
119
+ - Updated dependencies [a3a8dc0]
120
+ - Updated dependencies [b0b1550]
121
+ - @sanity/workflow-components@0.30.0
122
+ - @sanity/workflow-engine@0.30.0
123
+ - @sanity/workflow-react@0.30.0
124
+ - @sanity/workflow-studio@0.30.0
125
+ - @sanity/workflow-diagram@0.30.0
126
+
3
127
  ## 0.29.0
4
128
 
5
129
  ### Minor Changes
package/README.md CHANGED
@@ -4,22 +4,23 @@
4
4
  > consumer setup for when the package is published. Every
5
5
  > `@sanity/workflow-*` package is pre-1.0; APIs may change.
6
6
 
7
- Editorial workflows inside Sanity Studio. You describe a workflow in code —
7
+ Workflows inside Sanity Studio. You describe a workflow in code —
8
8
  stages like _Drafting → Review → Approved_, and the actions that move work
9
9
  between them — deploy it to your dataset, and this plugin gives editors the
10
10
  UI: a **workflow strip** above the editor form of mapped documents (the
11
11
  current stage, your task count, and a **Start workflow** button), and a
12
12
  **Workflows tab** next to the editor with the stage's activities and to-dos,
13
- where they fire actions, and a **Workflows tool** in the Studio navbar — the
14
- deployed workflows as a landing catalog, the open tasks across the newest
15
- workflow instances (capped), the user's own cut of them, and a page per
16
- workflow carrying that workflow's documents laid out over its stages as
17
- side-by-side columns, beside its definition. Every one of those is a
18
- shareable address, as is the per-instance detail, whose history feed rests at
19
- its newest entries with the rest behind **Show all history**. The instance
20
- detail is also where a running workflow can be stopped: an **Abort workflow**
21
- button below the stage card, against a reason recorded in the workflow's
22
- history. Aborting is open to anyone who can act on the instance, and cannot be
13
+ where they fire actions, and a **Workflows tool** in the Studio navbar — an
14
+ **Overview** run table across every workflow (filterable by workflow,
15
+ assignee, stage, release, and attention, with a Table | Board display
16
+ toggle), a **For me** tab cutting the same table to the reader's own work,
17
+ and a **Definitions** catalog behind the title row, each definition with its
18
+ own page. Every one of those is a shareable address, run selection included:
19
+ a selected row opens the run's detail in a panel beside the list, whose
20
+ history feed rests at its newest entries with the rest behind **Show all
21
+ history**. The panel is also where a running workflow can be stopped: an
22
+ **Abort workflow** button below the stage card, against a reason recorded in
23
+ the workflow's history. Aborting is open to anyone who can act on the instance, and cannot be
23
24
  undone.
24
25
 
25
26
  Four ideas cover everything in this guide:
@@ -373,11 +374,10 @@ runtimes are safe: ticks are idempotent, pending effects carry claims, and
373
374
 
374
375
  A third function is worth considering: deleting a document does not cascade
375
376
  into its workflows, so instances whose documents are gone stay in-flight
376
- until something settles them. The Workflows tool detects these and offers
377
- to settle them all, but that needs an editor looking; a document-delete
377
+ until something settles them. A document-delete
378
378
  function settles them the moment the deletion happens, on the robot token —
379
379
  see the cookbook recipe
380
- [Handle a deleted subject document](https://www.sanity.io/docs/editorial-workflows/cookbook-handle-deleted-subject).
380
+ [Handle a deleted subject document](https://www.sanity.io/docs/workflows/cookbook-handle-deleted-subject).
381
381
 
382
382
  ## Limitations
383
383