[EPIC] CD: Workflow Actions

Description

Content Drive needs to expose the same workflow capabilities editors rely on elsewhere in the product: the default actions (publish, unpublish, archive, delete…) and the actions defined by each content type's workflow schemes. Today those are only partly reachable, so a user browsing Content Drive has to leave it to move content through a workflow.

Workflow actions surface in three contexts, and they have meaningfully different requirements:

Context	Trigger	What shows	Source
Single item	Right click a row, or the row's ... menu	Default + workflow actions applicable to that item, in that order	GET /api/v1/workflow/contentlet/{inode}/actions?renderMode=LISTING
Selection (1 item)	Command bar, driven by the selection	Default actions as secondary buttons; overflow into a "more" menu when they don't fit	selection state + system-action mappings
Selection (2+ items)	Command bar → Action Center dialog	Quick Actions plus workflow actions grouped by scheme, each with a count of how many selected items it applies to	POST /api/v1/workflow/contentlet/actions/bulk

The multi-select case is where this stops being a presentation problem. Counts matter, because an action rarely applies to the whole selection, and a flat button cannot express "this applies to 2 of your 5 items". That is why 2+ items opens a dialog rather than adding more buttons.

Original framing, preserved: the command bar should show as primary buttons only actions that apply to the whole view (namely NEW). Everything else is tied to the selection and shown as secondary buttons — default actions first, then workflow actions — with an overflow "more" menu when they don't fit. Right-clicking a row, or using its ... button, shows only the actions applicable to that item, in the same order. This should land before first launch.

Current state

• ✅ Per-row menu — implemented. Fetches dynamic per-scheme workflow actions via getByInode(…, LISTING) and renders them alongside edit, permissions, lock/unlock and Add to Bundle.
• ⚠️ Command bar (selection) — partially implemented. Shows a hardcoded set of system actions gated by selection state; does not yet show the dynamic per-scheme workflow actions the epic asks for, and has no overflow menu.
• ❌ Multi-select bulk — not implemented. Tracked by the child issues below.

Constraints that shape the design

These are properties of the workflow engine, not implementation choices, and they should be treated as fixed inputs:

1. A contentlet occupies exactly one workflow step at a time. workflow_task carries UNIQUE (webasset, language_id) and its status column holds a single step id. So a contentlet belongs to one scheme at a time, per-scheme counts in the UI partition the selection rather than overlapping, and a mixed selection will partially skip when an action is fired.
2. Firing one action invalidates the others. The action moves the contentlet to its next step, so any other action's precondition and count go stale immediately. This is why execution is one action at a time until the spike says otherwise.
3. Counts can be an upper bound. The backend does not evaluate an action's Velocity condition when aggregating counts, and flags this as conditionPresent. The UI has to be honest about that rather than promising an exact number.
4. Some actions cannot be fired unattended. Push publish, move-with-path, and assign/comment actions need extra input before they can run.

Scope

Child	Type
#36817 — Action Center: bulk workflow actions, one action per execution	Task
#36818 — Spike: running multiple workflow actions in one execution	Spike
#36819 — Preview the items a workflow action will run on	Task
#36894 — Per-item execution results, and enrich _bulkfire to support them	Task
#36844 — Bulk Lock and Unlock quick actions	Task
#36845 — Refresh quick action that reindexes the selection	Task

Also in scope, not yet ticketed:

• Dynamic per-scheme workflow actions in the command bar for a single-item selection, plus the overflow "more" menu
• Add to Bundle over a selection — reachable today only through the legacy RemotePublishAjaxAction servlet, not a REST endpoint

Backend gaps shared by several children. There is no bulk REST endpoint for lock/unlock, reindex, or add-to-bundle — in each case a single-item endpoint exists and legacy loops server-side through a Struts command. And no endpoint returns which items an action applies to, only counts — #36819 works around that by grouping the selection per content type, which is exact at scheme level but cannot account for an item's step position or a Velocity condition. #36844 and #36845 each carry the decision between a client-side loop and a new endpoint; if endpoints are added they should be designed together so they share one request/response shape rather than three.

The SSE fire endpoint also drops information it already holds — the failure reason, which item succeeded, and skipped items — which is what blocks a results view. #36894 covers enriching it.

Naming: the dialog is presented to users as Workflow Center, while the code and i18n keys keep the action-center prefix. Some child issue titles still say "Action Center".

Desired Outcome

A content editor can move content through its workflow without leaving Content Drive.

Concretely, we would consider this landed when:

• Workflow actions defined by a content type's schemes are reachable from Content Drive for a single item and for a multi-item selection — not just the built-in defaults
• For a multi-item selection, the user can see how many of the selected items each action actually applies to before running it
• Executing an action over a selection reports what succeeded, what was skipped, and why, rather than failing silently or reporting only a total
• The experience holds on Community, where System Workflow is the only scheme that can exist
• Editors stop bouncing to the legacy content-search portlet to perform bulk workflow operations

Target Personas

• Developer teams
• Content teams
• DevOps teams
• System administrators (dotCMS)

Links

• Design prototype: Content Drive remix — ActionCenterDialog.tsx
• Reference implementation (legacy, same endpoints): dotCMS/src/main/webapp/html/portlet/ext/contentlet/view_bulk_actions_inc.jsp
• Key backend: WorkflowHelper.findBulkActions, WorkflowAPIImpl.distributeWorkAndProcess, WorkflowActionUtils.filterBulkActions

Start with the child issues, the ActionCenterDialog.tsx design reference, and the existing per-row implementation using getByInode(..., LISTING); then trace WorkflowHelper.findBulkActions and WorkflowAPIImpl.distributeWorkAndProcess. This epic is done when single- and multi-selection workflow actions, counts, and per-item execution results work in Content Drive, including Community constraints.