refactor(content-drive): trim quick actions to the old-search bulk operations

[rjvelazco]

Draft / spike — not for merge as-is. This is route 1 of two options being put to the team for how Content Drive's Action Center should relate to the legacy content search. Opened as a draft so the diff can be read and discussed. No linked issue yet.

What this does

Narrows the Action Center's Quick Actions section to the bulk operations the old content search offered outside its workflow dropdown.

Row	Before	After
Lock	wired	wired
Unlock	wired	wired (keeps the "locked by another user" warning)
Add to Bundle	wired	wired (keeps the bundle-picker step)
Publish / Unpublish / Archive / Unarchive / Delete	wired	removed
Push Publish	—	added, disabled placeholder
Refresh	—	added, disabled placeholder

Why remove the five state actions

They are already offered by the Workflow Actions section below, as the scheme's own actions.

That is not a duplicate — it is a more correct answer. A quick action fires POST /v1/workflow/actions/default/fire/{systemAction}, which resolves through the scheme's Default Actions mapping. If a content type's scheme maps PUBLISH to something other than a plain publish, the quick-action row labelled "Publish" and the workflow row labelled "Publish" do different things. Two rows with the same label and different behaviour is worse than one row that resolves correctly.

Lock and Unlock stay because they are genuinely per-user state on the version info, not a workflow transition — they have no scheme action to defer to. (WorkflowAPI.SystemAction documents this: they carry no actionlet and mapping them has no effect.)

Why the placeholders are rendered rather than hidden

Push Publish and Refresh are actions the old search does offer. Leaving them out entirely makes Content Drive look like it dropped them; a disabled row with a Work in progress badge and an explanatory tooltip is the honest state. Neither is wired:

• Push Publish needs an environment, filter and schedule collected before it can fire — a configuration step the quick-action path does not have yet (the workflow-action path already does, via DotWorkflowPushPublishComponent).
• Refresh is backed by _bulkrefresh, which streams progress over SSE and is not job-backed, so it cannot reuse the synchronous bulkFire path the other quick actions run on.

Both count over the whole selection rather than sitting at 0 — a 0 would read as "does not apply to these items", a different and untrue claim from "not built yet". The row is disabled by its comingSoon flag, not by its count.

Commits

1. Trim the quick actions — list, new IDs, comingSoon flag, template, specs.
2. Drop the machinery the removed rows were the only users of — danger (permanently false once the destructive rows left, plus its two red-styling branches), the entire confirmation path (confirmMessage, the ConfirmationService provider/injection, ConfirmDialogModule, <p-confirmDialog>, and fireQuickAction, which existed only so the confirm and direct branches could share a path), their tests, and doc comments still describing Publish and Delete as quick actions.
3. Prettier formatting.

i18n

One key added: content-drive.action-center.coming-soon. Labels reuse the legacy Remote-Publish and Refresh keys the old search already uses, so the parity is free in every translation. The badge reuses the existing content-drive.work-in-progress.

Known leftovers — deliberate, flagging for review

Two keys are now orphaned repo-wide (core-web and dotCMS/src both grep clean):

• content.drive.worflow.action.delete.confirm
• content-drive.action-center.confirm.header

Left in Language.properties on purpose: removing i18n keys is a different risk profile (customer overrides and plugins can reference them), and route 2 may bring destructive quick actions back. Happy to delete them if reviewers prefer.

Testing

• pnpm nx test portlets-content-drive — 1240 passed, 32 suites
• pnpm nx affected -t lint --base=main — clean, 4 projects
• pnpm nx format:check --base=main — clean

New coverage: placeholders render disabled with the badge, the click guard holds if a call ever gets past the disabled attribute, the five state actions are absent from the list, and the display order is pinned.

Not done here

Manual QA in a running instance. The dialog is covered by unit tests only; someone should click through Lock/Unlock/Add to Bundle against real content before this stops being a spike.

🤖 Generated with Claude Code

[github-actions]

❌ Issue Linking Required

This PR could not be linked to an issue. All PRs must be linked to an issue for tracking purposes.

How to fix this:

Option 1: Add keyword to PR body (Recommended - auto-removes this comment)
Edit this PR description and add one of these lines:

• Fixes #123 or Closes #123 — same-repo issue
• Fixes org/repo#123 or Closes org/repo#123 — cross-repo or private issue
• Closes https://github.com/org/repo/issues/123 — full GitHub URL
• Other supported keywords: fix, fixed, close, closed, resolve, resolved

Option 2: Link via GitHub UI (Note: won't clear the failed check)

1. Go to the PR → Development section (right sidebar)

2. Click "Link issue" and select an existing issue

3. Push a new commit or re-run the workflow to clear the failed check
   Option 3: Use branch naming
   Create a new branch with one of these patterns:

• 123-feature-description (number at start)

• issue-123-feature-description (issue-number at start)

• feature-issue-123 (issue-number anywhere)

Why is this required?

Issue linking ensures proper tracking, documentation, and helps maintain project history. It connects your code changes to the problem they solve.
---This comment was automatically generated by the issue linking workflow

[claude]

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

---

Review — PR #37073

• Read changed files
• Analyze quick-action list, component, template changes
• Check tests & i18n
• Post review

I reviewed the full diff against origin/main (6 files). This is a well-executed, self-consistent refactor. I focused on correctness of the trim, dangling references, and the placeholder behavior.

New Issues

No issues found.

What I verified:

• No dangling references — grepped the portlet for fireQuickAction, onExecuteQuickAction, confirmMessage, danger, ConfirmationService, ConfirmDialog, and the confirm-header key. All clean. The confirmation machinery, the danger field/branches, and the two red-styling template branches were removed together, so nothing points at a deleted symbol.
• Placeholder guard is doubled correctly — the row is disabled via [disabled]="… || quickAction.comingSoon || …" in the template and onSelectQuickAction returns early on comingSoon. The unit test drives onSelectQuickAction directly to prove the guard holds if a click ever gets past the disabled attribute (component.spec.ts "should not open a preview for a placeholder row").
• Count semantics — PUSH_PUBLISH/REFRESH use eligibleWhen: () => true, and getQuickActions returns [] only when there are no contentlets, so their count is always the (folder-excluded) contentlet count, never a misleading 0. The comingSoon disable is independent of count. Consistent with the spec assertions.
• i18n keys resolve — content-drive.action-center.coming-soon added; Remote-Publish, Refresh, and content-drive.work-in-progress all pre-exist in Language.properties. No missing-key risk.
• Hint precedence — quickActionHint checks comingSoon before count === 0, so a placeholder shows the "under development" tooltip rather than "not applicable." Correct given both would otherwise be true.
• Test parity — the removed Publish/Delete/Archive assertions were re-pointed to Lock/Unlock/Add-to-Bundle equivalents rather than dropped, and display order + count/inode-alignment invariants are still pinned.

Notes (non-blocking)

• The two orphaned keys (content.drive.worflow.action.delete.confirm, content-drive.action-center.confirm.header) are left in Language.properties deliberately, and the PR body already explains the rationale (override/plugin risk, route-2 may restore destructive actions). Agreed this is the safer default; no action needed unless reviewers want them gone. Note content.drive.worflow.action.delete.confirm also contains a pre-existing typo (worflow) — leaving it untouched is correct here since it's slated for possible removal.
• Since this is flagged as a draft spike, the main follow-up remains the one you called out: manual QA of Lock/Unlock/Add-to-Bundle against real content before this leaves spike status.

``
· spike/content-drive-quick-actions-parity-v1

[rjvelazco]

Route 2 is now open for comparison: #37075 — keeps the state actions and gates them on the workflow Default Action mapping, rather than removing them.

Both are drafts and are meant to be read against each other:

	#37073 (this one)	#37075
Publish/Unpublish/Archive/Unarchive/Delete	removed from Quick Actions	kept, gated on the mapping
Reaching them	Workflow Actions section only	either, when mapped
Closes the raw-API bypass	yes, by removal	yes, by gating
New requests per dialog open	none	1 per content type + 1 per scheme
Diff size	−298 / +285	+903 / −82
Backend follow-up	none	optional: a resolved-mapping endpoint would collapse the fan-out to one call