feat(content-drive): add Action Center for bulk workflow actions

[rjvelazco]

Draft implementation of the Content Drive Action Center — a dialog for acting on a multi-item selection.

Opening as a draft: this is a working v1 to demo and discuss with the team, with a few deliberate scope limits documented below.

Fixes #36817

Proposed Changes

• getBulkActions() on DotWorkflowsActionsService — wraps POST /api/v1/workflow/contentlet/actions/bulk, which returns the workflow actions available for a set of contentlets, grouped by scheme and step, each with the number of selected contentlets it applies to. New DotBulkActionView models in dotcms-models.
• DotContentDriveActionCenterComponent — the dialog, with two sections:
  • Quick Actions — Publish / Unpublish / Archive / Unarchive / Delete, each fired over the whole eligible selection in one request via POST /api/v1/workflow/actions/default/fire/{systemAction}. Counts are derived client-side from row state (live, archived), and an action that applies to nothing is omitted rather than shown as (0).
  • Workflow Actions — one collapsible panel per workflow scheme, with real per-action eligibility counts from the backend's Elasticsearch aggregation on wfstep. Single-expand; one action selected at a time.
• Toolbar — once more than one contentlet is selected, the flat action buttons are replaced by a single "Action Center" button. Folders are excluded from the count and from every payload, since the bulk endpoints take contentlet inodes and folders carry no workflow step.
• Shell — DIALOG_TYPE.ACTION_CENTER is routed out of the shared dialog's content switch and mounted as a sibling, because this dialog owns a custom header and footer (see Additional Info). The store stays the single source of open/close state.
• i18n — 19 content-drive.action-center.* keys.

Checklist

• Tests — 37 new (action-center.spec.ts for the pure mapping/eligibility logic, plus the component spec). Full portlet suite green: 872/872, lint clean.
• Translations — English keys added to Language.properties; other locales not translated.
• Security Implications Contemplated — no new endpoints and no new permissions surface; this consumes existing authenticated REST endpoints. Worth knowing for review: the bulk-actions endpoint filters by action-level role permission only and deliberately lets actions with special workflow roles through, because there is no per-contentlet permissionable at aggregation time (WorkflowActionUtils#filterBulkActions). So a listed action can still fail per item at fire time, which the backend reports in fails[] and the dialog surfaces. Enforcement stays server-side; the counts here are advisory, never an authorization decision.

Additional Info

Scope limits, all deliberate:

• One action per execute. No endpoint fires several different actions in one call, and this isn't just a missing endpoint — workflow_task has a UNIQUE (webasset, language_id) constraint, so a contentlet+language sits on exactly one step, owned by exactly one scheme. Firing action A moves it to a new step, which invalidates the other actions' preconditions. The legacy JSP dialog has the same constraint. A useful consequence: the scheme counts partition the selection rather than overlapping.
• Actions needing extra input are disabled with a tooltip — push-publish settings, a move target path, or an assign/comment prompt. Wiring those means reusing DotWorkflowEventHandlerService; out of scope here.
• Conditional counts are shown as ≤ N. When conditionPresent is true the backend does not evaluate the action's Velocity condition while aggregating, so the count is an upper bound.
• Lock / Unlock and Add to Bundle are omitted — neither has a bulk REST endpoint. Legacy drives unlock through a Struts command (full_unlock_list) that loops server-side, and add-to-bundle through the legacy RemotePublishAjaxAction servlet.
• Fires synchronously via bulkFire. The legacy dialog uses the SSE endpoint (_bulkfire) for live progress counters, which is the better path for large batches but needs an SSE shim since native EventSource cannot POST a body.
• System Workflow stays visible. Hiding it would remove bulk Copy outright — Copy has no system-action mapping, so it is only reachable through the workflow list — and would empty the section on Community, where System Workflow is the only scheme that can exist.

Known follow-ups (backend asks):

• _bulklock / _bulkunlock REST endpoints (the _batchUnlock logic already exists to port).
• An endpoint returning eligible inodes per action — the only thing that unblocks the design's per-item drill-down, which needs to know which items an action applies to. The API returns aggregate counts only.
• A REST replacement for the legacy add-to-bundle AJAX action.

Deviations from the design prototype, both following from the above: workflow steps use radio semantics rather than checkboxes (multi-select would need sequential fires with re-validation between each), and there are no per-step icon chips (the API returns dotCMS icon names that don't map to Material Symbols).

Styling note: the prototype's raw slate-* / #1D1B4B / #1D4ED8 values are mapped onto the theme tokens tailwindcss-primeui exposes (surface-*, primary-*), so the dialog follows the active PrimeNG theme instead of pinning one palette. If that navy is meant to be a real brand token, that's a theme-level change rather than something hardcoded here.

Video

video.mov

[claude]

Claude finished @rjvelazco's task in 5m 18s —— View job

---

Code Review

Reviewed the diff against the Action Center feature. One correctness issue stands out, plus a couple of smaller items.

New Issues

• 🟠 High: core-web/.../dot-content-drive-action-center.component.ts:222,249,253 — Quick actions fire over the whole selection, not the eligible subset. The displayed count is derived per-action from eligibleWhen (action-center.ts:173 → contentlets.filter(quickAction.eligibleWhen).length), but onExecuteQuickAction builds inodes from toContentletInodes(this.$selectedItems()) — every contentlet, regardless of eligibility — and fireQuickAction fires the system action over all of them. The component's own spec proves the mismatch: with inode-1 (not live) + inode-2 (live: true), Publish renders (1) yet fireDefaultAction is asserted to be called with ['inode-1', 'inode-2'] (spec lines 308–317). Consequences:

  • The success toast reports inodes.length (fireQuickAction → onExecuteSuccess(..., inodes.length)), so it says "Published (2)" when the UI advertised (1).
  • For a mixed selection this fires lifecycle actions on ineligible items — e.g. 1 archived + 1 live, Delete shows (1) but fires DELETE over the live inode too. fireDefaultAction returns DotCMSContentlet[] with no per-item fails[], so an ineligible item can fail the whole call (or mutate state you didn't intend), unlike the workflow-action path which reports skippedCount.
    This contradicts the PR description ("each fired over the whole eligible selection"). The fix is to carry eligibleWhen onto the rendered DotActionCenterQuickAction (or recompute it at fire time) and fire only the eligible inodes, then report that count in the toast. Fix this →

• 🟡 Medium: core-web/.../dot-content-drive-action-center.component.ts:437-445 — Error handling uses a bare MessageService toast + console.error instead of DotHttpErrorManagerService.handle(error). The portlet guide (libs/portlets/CLAUDE.md) lists custom error UI as an anti-pattern and prescribes DotHttpErrorManagerService for HTTP errors — which also correctly handles 401/403/404 rather than showing a generic "error" toast for, say, a permission failure at fire time (exactly the case the PR notes can happen server-side). Assumption: the fire endpoints surface auth/permission failures as HTTP errors here; What to verify: whether a per-item permission failure comes back as a 4xx (→ handled better by the error manager) vs. inside a 200 fails[] body.

• 🟡 Medium: core-web/.../dot-content-drive-action-center.component.ts:184-186 — $quickActions is computed from getQuickActions(this.$selectedItems()) while $contentlets/$contentletCount use excludeFolders(...). getQuickActions re-runs excludeFolders internally, so folders are handled correctly, but the two computeds walk the selection separately. Minor — not a bug, just redundant work; deriving $quickActions from $contentlets() would keep one source of truth.

No security issues found — this consumes existing authenticated endpoints and enforcement stays server-side, consistent with the PR's security note. Folder exclusion from payloads is applied consistently (toContentletInodes, excludeFolders).

---

The High item is the one worth resolving before merge; it's a real display-vs-behavior divergence that the existing test locks in rather than catches.

[rjvelazco]

@claude core review this PR and propose some unit test

[claude]

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

---

Review: Action Center for bulk workflow actions

Todo list

• Gather context (diff, changed files, related utils/component/service code)
• Review core logic: action-center.ts, the dialog component, DotWorkflowsActionsService, toolbar/shell wiring
• Check status of previously-flagged High issue (quick actions firing over ineligible items)
• Propose additional unit tests
• Post final review

---

Status of the earlier High finding

Still open. onExecuteQuickAction (dot-content-drive-action-center.component.ts:222) builds inodes from toContentletInodes(this.$selectedItems()) — the whole selection — while the displayed count (action-center.ts:173) is contentlets.filter(quickAction.eligibleWhen).length. The component's own spec still locks in the mismatch: inode-1 (not live) + inode-2 (live: true) → Publish renders (1) but fireDefaultAction is asserted called with ['inode-1', 'inode-2'] (spec lines 308–317). Firing a lifecycle action (e.g. DELETE) over an item that doesn't satisfy eligibleWhen contradicts the PR description ("fired over the whole eligible selection") and can mutate items the UI never advertised as affected. Worth fixing before merge — see the proposed regression test below.

New/confirmed findings

• 🟡 Medium — dot-content-drive-action-center.component.ts:437-445 (onExecuteError): custom MessageService toast + console.error instead of DotHttpErrorManagerService.handle(error). libs/portlets/CLAUDE.md's anti-pattern table calls this out explicitly ("Custom error dialogs" → "Use DotHttpErrorManagerService.handle(error) everywhere"), and it's the pattern already used elsewhere in this same portlet (e.g. dot-content-drive-navigation.service.ts). A generic "Action failed" toast also masks 401/403 differently than the error manager would, which matters here specifically since the PR notes a listed action can fail per-item on a permission check at fire time.
• 🔵 Minor — dot-content-drive-action-center.component.ts:184-186: $quickActions computes from getQuickActions(this.$selectedItems()) while $contentlets() already holds excludeFolders(this.$selectedItems()). getQuickActions re-derives the same folder exclusion internally, so behavior is correct, just redundant — getQuickActions could take this.$contentlets() instead of walking the raw selection twice. Fix this →
• No security regressions found beyond what's already noted in the PR description — enforcement stays server-side, folder exclusion is applied consistently across every payload (toContentletInodes, excludeFolders), and the confirm-before-destructive-action behavior (Delete) matches the toolbar's prior behavior.

Test coverage gaps

The new specs (action-center.spec.ts — pure mapping, and the component spec) are solid for the mapping/eligibility logic and the dialog's own behavior, but a few things introduced or changed by this PR aren't exercised anywhere:

1. DotWorkflowsActionsService.getBulkActions (dot-workflows-actions.service.ts:100) has no test. dot-workflows-actions.service.spec.ts covers every other method on this service via createHttpFactory/expectOne but wasn't updated for the new one.
2. Toolbar → Action Center wiring (dot-content-drive-toolbar.component.ts:287-299, $displayActionCenter / onOpenActionCenter) has no test in dot-content-drive-toolbar.component.spec.ts.
3. Shell routing of DIALOG_TYPE.ACTION_CENTER (dot-content-drive-shell.component.ts:197-207, the $isActionCenter/$sharedDialogVisible/$actionCenterVisible split) isn't covered by dot-content-drive-shell.component.spec.ts.
4. The eligibility bug above has no regression test once fixed.

Proposed unit tests

1. Regression test for the eligibility bug (add to dot-content-drive-action-center.component.spec.ts, once the fix lands):

it('should fire the quick action only over eligible inodes', () => {
    // inode-1 is not live (eligible for Publish); inode-2 is already live (not eligible)
    spectator.detectChanges();

    spectator.click('[data-testid="quick-action-PUBLISH"]');

    expect(fireService.fireDefaultAction).toHaveBeenCalledWith({
        action: 'PUBLISH',
        inodes: ['inode-1'] // NOT inode-2
    });
});

it('should report the eligible count in the success toast, not the full selection size', () => {
    spectator.detectChanges();
    spectator.click('[data-testid="quick-action-PUBLISH"]');

    expect(messageService.add).toHaveBeenCalledWith(
        expect.objectContaining({
            detail: expect.stringContaining('1') // eligible count, not 2
        })
    );
});

2. DotWorkflowsActionsService.getBulkActions (add to dot-workflows-actions.service.spec.ts):

it('should post contentletIds and unwrap the entity', (done) => {
    const request = { contentletIds: ['inode-1', 'inode-2'] };
    const mockResponse = { schemes: [] };

    spectator.service.getBulkActions(request).subscribe((res) => {
        expect(res).toEqual(mockResponse);
        done();
    });

    spectator
        .expectOne('/api/v1/workflow/contentlet/actions/bulk', HttpMethod.POST)
        .flush({ entity: mockResponse });
});

it('should fall back to an empty schemes array when entity is missing', (done) => {
    spectator.service.getBulkActions({ contentletIds: ['a'] }).subscribe((res) => {
        expect(res).toEqual({ schemes: [] });
        done();
    });

    spectator
        .expectOne('/api/v1/workflow/contentlet/actions/bulk', HttpMethod.POST)
        .flush({});
});

3. Toolbar → Action Center gating (add to dot-content-drive-toolbar.component.spec.ts):

it('should hide the Action Center button for a folder-only selection', () => {
    mockSelectedItems.set([{ type: 'folder', inode: 'f1' } as DotContentDriveItem]);
    spectator.detectChanges();

    expect(spectator.query('[data-testid="action-center-button"]')).toBeFalsy();
});

it('should show the Action Center button once a contentlet is selected', () => {
    mockSelectedItems.set([{ baseType: 'CONTENT', inode: 'c1' } as DotContentDriveItem]);
    spectator.detectChanges();

    expect(spectator.query('[data-testid="action-center-button"]')).toBeTruthy();
});

it('should open the ACTION_CENTER dialog on click', () => {
    mockSelectedItems.set([{ baseType: 'CONTENT', inode: 'c1' } as DotContentDriveItem]);
    spectator.detectChanges();

    spectator.click('[data-testid="action-center-button"]');

    expect(store.setDialog).toHaveBeenCalledWith(
        expect.objectContaining({ type: DIALOG_TYPE.ACTION_CENTER })
    );
});

4. Shell dialog routing (add to dot-content-drive-shell.component.spec.ts):

it('should mount the Action Center as a sibling, not inside the shared dialog switch', () => {
    mockDialog.set({ type: DIALOG_TYPE.ACTION_CENTER, header: 'x' });
    spectator.detectChanges();

    expect(spectator.query('dot-content-drive-action-center')).toBeTruthy();

    const sharedDialog = spectator.query('[data-testId="dialog"]');
    expect(sharedDialog?.getAttribute('ng-reflect-visible')).not.toBe('true');
});

it('should route FOLDER and CONTENT_TYPE_SELECTOR through the shared dialog switch, unaffected', () => {
    mockDialog.set({ type: DIALOG_TYPE.FOLDER, header: 'x' });
    spectator.detectChanges();

    expect(spectator.query('dot-content-drive-action-center')).toBeFalsy();
    expect(spectator.query('dot-content-drive-dialog-folder')).toBeTruthy();
});

(Test 4's exact assertions on visible/attribute names may need adjusting to match how the shell spec's existing mocks expose the dialog — I didn't find that spec's helper setup in this pass, so the above should be read as intent rather than drop-in code.)

---