feat(content-drive): preview a workflow action's items before executing

[rjvelazco]

Partially addresses #36819.

Adds the drill-down half of that issue: picking a workflow action now opens a preview of the contentlets it is about to run on, with a checkbox per row, so the payload can be reviewed and trimmed before firing. The execution-results half (per-item spinner / success / error with retry) is not in this PR — see Additional Info.

Proposed Changes

• Preview step before firing a workflow action. Selecting an action and hitting Continue opens a 4-column table (checkbox / Title / Status / Type) of the contentlets it applies to. Execute then fires only the rows still checked. Quick actions are unchanged — they still fire on click with the existing confirm.
• Firing now honours the preview. Workflow actions previously sent the entire selection and relied on the backend's skippedCount. They now send only the checked inodes, which also makes them consistent with quick actions (already sending just their eligible subset).
• Per-action eligibility resolved by content type. The bulk endpoint reports counts but never says which contentlets an action matches, so the preview used to list every selected item — a Blog action showing a VtlInclude row the server was always going to skip. Since workflow schemes are assigned per content type, the lookup now runs once per content type in the selection and each action records the types that can run it. Cost is bounded by distinct content types (typically 1–2), not by contentlet count, and the requests run in parallel.
• One dialog header. The shared dialog's header lives in the shell, so the preview rendering its own title produced a visibly duplicated header. The body now publishes a drill-down header through the store (dialogDrillDown), and the shell's single header retitles to the action name with a count that tracks the checked rows. Only the back control stays in the body, where it can disable itself while an action is in flight.
• Long titles truncate. A long title widened the table past the dialog and pushed the Type column behind a horizontal scrollbar. Fixed table layout plus min-w-0 on the title span; full text kept as the hover title.

Reuses existing building blocks rather than adding new ones — DotContentletStatusBadgeComponent and DotContentThumbnailComponent from @dotcms/ui, PrimeNG table checkboxes, and content-drive's existing 20-rows-per-page convention.

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Additional Info

Out of scope here — the other half of #36819. No per-item execution results. Execute still fires, toasts, refreshes the grid and closes the dialog. Adding per-row status/retry needs a decision on how per-item outcomes are reported (the synchronous bulkFire returns aggregate counts; the SSE _bulkfire endpoint streams progress but needs a shim, since native EventSource cannot POST a body). Worth splitting into its own issue.

Known limitation: scheme-level, not step-level. Content-type grouping makes eligibility exact at scheme level, but two contentlets of the same type can sit on different workflow steps and only one step may expose the action. The endpoint still won't say which. The action's count remains the authority, so the preview keeps a partial-match warning that fires only on that genuine step-level gap. Making rows individually accurate needs a backend change (returning matching contentlet ids per action).

Rows are keyed on inode, not identifier as the main grid does. Language variants of one contentlet share an identifier but have distinct inodes, and inodes are what gets fired — keying on identifier would collapse two variants into one selection entry. Pinned by a test.

Reviewers: new i18n keys need a dotCMS restart. Language.properties is read by the backend at startup, so the five new content-drive.action-center.* keys render as raw keys against an already-running instance until it restarts (or the language cache is flushed). Not a frontend bug.

One commit is a revert. bd8560ffbc reverts 0304def518, a Vue-template reformatting commit that had reformatted 29 unrelated libs/sdk/vue files against the repo's Prettier config (prettier --check flagged all 29; clean after the revert). The two cancel out, so they contribute nothing to this PR's diff. Root cause worth noting separately: lint-staged.config.mjs globs cover ts,js,mjs,cjs,tsx,jsx and json,html,css,scss,md,yaml,yml — .vue is in neither, so the pre-commit hook never formats Vue files while an unscoped nx format:write does.

Branch history is noisy. It carries the pre-squash commits of #36821 plus a merge, all redundant with main's squashed d595cd8e3c. The diff is unaffected (15 files, all listed above); only the commit list is long.

Verification

pnpm nx test portlets-content-drive   # 939/939, 30 suites
pnpm nx test data-access              # 751 passed, 11 skipped
pnpm nx lint portlets-content-drive   # clean
pnpm nx format:check                  # clean
pnpm nx build dotcms-ui               # AOT build passes (templates type-check)

Also exercised manually against a local backend on Angular 22 / TypeScript 6.0: mixed-type selection, unchecking rows, >20-item pagination, back navigation, and that quick actions still fire on a single click.

Videos

video.mov

video-2.mov

[claude]

Claude finished @rjvelazco's task in 4m 30s —— View job

---

Code Review — workflow action preview

Reviewed the full diff (frontend only): action-center.ts utils, the action-center component + template, the new preview component, the shell header plumbing, withDialog store feature, the models, and the new i18n keys. Traced the merge/eligibility logic and the drill-down header flow end to end.

New Issues

No bugs found. The changes are internally consistent and the edge cases I checked hold up:

• Payload/count coupling is sound. onExecuteWorkflowAction now fires $includedItems().map(i => i.inode) (dot-content-drive-action-center.component.ts:411), and the preview's checked set is seeded from $previewItems() — the same content-type-narrowed list the header count is derived from. No drift between what's shown and what's fired.
• $actionCenterCount handles the all-unchecked case correctly (dot-content-drive-shell.component.ts:245): dialogDrillDown()?.itemCount ?? … — 0 is not nullish, so an empty preview renders "0 items selected" rather than falling back to the full selection count.
• Drill-down lifecycle is clean. setDialog/closeDialog both clear dialogDrillDown (withDialog.ts:24-29), and onBackToActions clears it too. The action-center component is destroyed on dialog hide, so $view resets to 'actions' on reopen.
• mergeActionCenterSchemes count summing is correct — each contentlet belongs to exactly one content-type group, so summing scheme/action counts across groups reproduces a single combined lookup.
• Removed key content-drive.action-center.execute-workflow has no remaining references in core-web (confirmed the only other hits are the unrelated Unable-to-execute-workflows backend key). The five new keys are present in Language.properties.

Notes (non-blocking, already documented)

• 🟡 The partial-match warning (dot-content-drive-action-center.component.html:290) compares $previewCount() > action.count. When approximateCount is true, action.count is an upper bound (≤), so the warning both (a) may not fire when skips actually occur and (b) uses that upper-bound count as {0} in the message, which can overstate. This is the exact scheme-vs-step-level limitation the PR body calls out and the ≤ count UI already signals it elsewhere — flagging only so it's on record, not as a regression.

Test coverage

The suite is thorough. The scheme-switch deselection (onOpenSchemeChange), the drill-down header state, and the inode-vs-identifier keying are all pinned by tests added in fa5b21b9. This addresses the gaps raised in the earlier unit-test review on this PR.

Verdict: No blocking issues. Frontend-only change; backend @Schema/REST rules and Maven/version conventions don't apply here. New i18n keys require a dotCMS restart to render (correctly noted in the PR body).

• issue-36819-content-drive-action-center-per-item-drill-down-with-execution-results

[rjvelazco]

@claude review this PR and check what unit test are valid, what can be removed and propuse new unit tests

[claude]

Claude finished @rjvelazco's task in 6m 43s —— View job

---

Unit test review — dot-content-drive Action Center preview

• Gather context (PR diff, CLAUDE.md, changed files)
• Read dot-content-drive-action-preview component + spec (new)
• Read dot-content-drive-action-center component + spec
• Read utils/action-center.ts + spec
• Read shell component + spec, withDialog.ts, models.ts
• Identify valid vs. redundant/removable tests
• Propose new test cases for gaps

I read all 15 changed files end to end (component + template + spec pairs) and compared coverage against implementation branches. Overall: the test suite is thorough and well-targeted — most tests assert observable behavior (DOM/output) rather than internals, and several tests exist specifically to pin regressions the PR description calls out (inode-vs-identifier keying, count/payload drift, per-content-type eligibility). I found no tests worth removing as redundant. I did find real coverage gaps.

Valid, worth keeping (no action needed)

• dot-content-drive-action-preview.component.spec.ts — clean, single-purpose, and the "language variants stay distinct rows" test (dot-content-drive-action-preview.component.spec.ts:163-186) is a good regression pin for the inode-keying decision called out in the PR body.
• action-center.spec.ts (utils) — mergeActionCenterSchemes/groupByContentType/eligibleContentlets are pure functions with thorough branch coverage (union of content types, sum of counts, approximate-count propagation, empty-groups fallback). No changes needed.
• dot-content-drive-action-center.component.spec.ts — the "fire exactly as many inodes as the row advertises" (:356-371) and "keep the fired payload in step with the count shown on the button" (:531-542) tests are good: they assert the displayed count and the fired payload came from the same computation, guarding against exactly the count/payload drift bug the PR fixes for quick actions and preview.

I don't see any test in this diff that duplicates another or tests implementation detail that should be removed — nothing stood out as safe to delete without losing signal.

Gaps — new tests worth adding

1. onOpenSchemeChange deselection branch is completely untested (dot-content-drive-action-center.component.ts:438-452). Collapsing a scheme panel, or switching to a different one, clears $selectedActionId if the previously-armed action isn't in the newly-opened scheme. No spec calls onOpenSchemeChange or emits (valueChange) on p-accordion. Worth two tests: (a) selecting an action in scheme A, then opening scheme B → $selectedActionId() becomes null and Continue/Execute disable; (b) re-opening the same scheme (or a [scheme.id] array value, since PrimeNG can emit an array) keeps the action armed.

2. The shell's drill-down header override ($actionCenterHeader / $actionCenterCount) is wired into the mock but never exercised (dot-content-drive-shell.component.spec.ts:95,150,182). dialogDrillDownSignal is declared and passed to the mocked store, but no test ever calls .set() on it. So the actual behavior this PR adds to the shell — "when the body publishes a drill-down, the one dialog header retitles to the action name and count" — has zero direct coverage at the shell level (it's only verified indirectly via the action-center component's store.setDialogDrillDown call args, which doesn't confirm the shell renders it). Suggested tests:

   • Set dialogDrillDownSignal.set({ header: 'Send for Review', itemCount: 2 }) → assert [data-testId="dialog-header"] renders 'Send for Review' and the sub-header renders the count, not the plain selection count.
   • Clear it back to undefined → header falls back to $activeDialog()?.header / $actionCenterSelectionCount().

3. withDialog.spec.ts has no test for the two new methods it just gained (withDialog.ts:31-38). The spec still only covers setDialog/closeDialog from before this PR; setDialogDrillDown and clearDialogDrillDown — plus the "a fresh setDialog call clears any prior drill-down" and "closeDialog clears drill-down too" behaviors — aren't asserted anywhere. Given this is the actual state-holding logic behind gap Test Branch and Commit #2, this is the cheapest, most direct place to close it:

   it('should set the drill-down header', () => {
       store.setDialogDrillDown({ header: 'Send for Review', itemCount: 2 });
       expect(store.dialogDrillDown()).toEqual({ header: 'Send for Review', itemCount: 2 });
   });
   
   it('should clear the drill-down header', () => {
       store.setDialogDrillDown({ header: 'Send for Review', itemCount: 2 });
       store.clearDialogDrillDown();
       expect(store.dialogDrillDown()).toBeUndefined();
   });
   
   it('should clear a stale drill-down when a new dialog opens', () => {
       store.setDialogDrillDown({ header: 'Send for Review', itemCount: 2 });
       store.setDialog(mockDialog);
       expect(store.dialogDrillDown()).toBeUndefined();
   });
   
   it('should clear the drill-down on close', () => {
       store.setDialogDrillDown({ header: 'Send for Review', itemCount: 2 });
       store.closeDialog();
       expect(store.dialogDrillDown()).toBeUndefined();
   });

4. Minor: PrimeNG's p-accordion valueChange can emit a single value or an array (the component signature already accounts for string[] | number[]), but no test feeds onOpenSchemeChange an array — only the plain string path is exercised implicitly through the DOM in existing tests. Worth one direct unit test calling spectator.component['onOpenSchemeChange'](['editorial']) to confirm the array-unwrapping branch (value[0]?.toString()) actually works, since accordion's real emission shape isn't simulated by clicking in JSDOM.

5. onContinueToPreview's early-return when previewItems is empty (dot-content-drive-action-center.component.ts:365-367) has no direct test. It's a real branch: eligibleContentlets can return [] if an action's contentTypes resolved but none match the current selection (e.g., selection changed between load and click). Suggested: mock $selectedAction/selection so $previewItems() is [], call onContinueToPreview(), assert $view() stays 'actions' and setDialogDrillDown is not called.

Suggested fixes

Add missing tests →

Summary

No tests need to be removed — the suite is well-scoped and pins the right regressions. The gaps all cluster around the drill-down header plumbing (store → shell) and the scheme-switch deselection logic: both are real behavior added in this PR that's currently only indirectly exercised (via mock call assertions on the action-center side) rather than directly verified at the layer that owns the behavior (the store feature and the shell). None of these are release-blocking — the manual verification in the PR description covers the same paths — but they're the cheapest places to close the loop before the SSE/execution-results follow-up work builds on top of this dialog state.