feat(content-drive): add workflow filter (scheme → step) to toolbar #35880

[zJaaal]

Proposed Changes

Frontend and backend for the Content Drive Workflow filter (scheme → optional step), implemented together in this PR. Closes #35880 (frontend) and #35470 (backend — consolidated here).

Frontend (#35880)

• Workflow filter in the Content Drive toolbar — a two-column popover (schemes → steps) mirroring the content-type filter.
• Multi-select schemes, single step per scheme: each selected scheme can pin one step; pinning a step cascades to select its scheme, deselecting a scheme drops its pinned step.
• Selection persists as a single structured filter key workflow: string[] (entries are schemeId or schemeId:stepId), so it round-trips through the URL via the existing encode/decode machinery with no step lookups.
• Scheme source follows the content-type selection (all schemes / schemes for the selected content types); steps load on demand and are cached per scheme.
• Empty-schemes state shows a dedicated, i18n'd message (singular/plural by selected content-type count); empty/loading states are centered.
• New DotWorkflowService methods: getSchemesByContentTypes() and getSteps().

Backend (#35470) — DB-first

• POST /api/v1/drive/search now honors an optional workflow: [{ scheme, step? }] field.
• Filter lives in the shared SQL builder (BrowserAPIImpl.selectQuery → appendWorkflowQuery), keeping the drive's DB-first hybrid intact — no forced Elasticsearch path.
• Scheme-only entry → matches by content-type assignment (workflow_scheme_x_structure), so imported / push-published / never-actioned content (no workflow_task) still appears under its scheme.
• Step-pinned entry → matches the contentlet's current task (workflow_task.status). Entries combine with OR. Folders are suppressed when a workflow filter is active.
• New immutable WorkflowFilterForm on DriveRequestForm; BrowserQuery.withWorkflowSchemeIds / withWorkflowStepIds. All ids are bound as ? parameters (no string concatenation).
• FE $request wires the stored workflow tokens into the drive-search request.

Chore

• chore(vscode): add MCP server config (primeng, nx, angular-cli).

Checklist

• Tests
  • FE: workflow-filter component spec + workflow encode/decode round-trip in functions.spec.ts + store empty-result pagination test
  • BE: ContentDriveWorkflowFilterTest integration test — scheme filter (incl. task-less content), step filter (current task), OR semantics, no-filter regression, folder suppression
• Translations — content-drive.workflow-filter.* keys added to Language.properties
• Security Implications Contemplated — read-only filter; all workflow ids bound as SQL parameters (no concatenation); MCP config contains no secrets

Additional Info

The backend ticket #35470 has been consolidated into this PR (and its design folded into #35880); it is closed in favor of #35906. The request contract there matches the structured workflow field used here.

🤖 Generated with Claude Code

[claude]

Claude finished @zJaaal's task in 6m 53s —— View job

---

PR Review

• Gathering context and reading changed files
• Reviewing backend changes (Java)
• Reviewing frontend changes (TypeScript/Angular)
• Final assessment

---

Issues Found

Backend

1. BrowserQuery.Builder(BrowserQuery) copy constructor does not copy workflowSchemeIds/workflowStepIds (BrowserQuery.java:285-318). If any caller ever uses BrowserQuery.from(existing) to clone and modify a query that already has a workflow filter, the workflow fields silently fall back to empty LinkedHashSets. There is no call site that does this today (no BrowserQuery.from() usage exists in the codebase), but it is a silent trap for future code and inconsistent with every other field in the same copy constructor. Fix this →

2. workflow_task.status holds a step UUID, not a step name. BrowserAPIImpl.appendWorkflowQuery joins workflow_task.status in (?) and the step IDs come from WorkflowFilterForm::step. This relies on workflow_task.status being a step ID, not a step name — this appears to be correct in dotCMS, but it's worth confirming against the schema, as status is an ambiguous column name that could mislead future maintainers. No fix needed if confirmed, but a brief inline comment would help.

3. Scheme-only filter uses workflow_scheme_x_structure.structure_id = struc.inode — this matches the content type, not the actual contentlet. A contentlet of a type governed by scheme A but reassigned away (if content-type reassignment is possible) could appear or not appear erroneously. This is an inherent limitation of the "scheme-only = assignment-based" design that the PR documents, but it is not tested as a negative case.

4. parseWorkflowFilter passes content-type IDs (variable names) to getSchemesByContentTypes — the frontend getSchemesByContentTypes passes contentTypeIds (the raw filter value, which may be variable names like "Blog" rather than UUIDs). The WorkflowResource.getWorkflowSchemesByContentTypeList endpoint resolves either inodes or variable names, so this is fine, but it's worth noting explicitly.

Frontend

5. getSchemesByContentTypes passes content type IDs (possibly variable names) from the filter — the #loadSchemes call reads rawContentTypes directly from getFilterValue('contentType') which is the encoded filter array (could be variable names or IDs). The backend handles both, but if content type filters are stored as variable names (as the store spec implies — contentType: ['Blog']), then the passed value matches by variable name via the WorkflowResource endpoint's normalization. This is fine but not explicitly tested.

6. $selection is a linkedSignal that recomputes from the store filter. When #reconcileSelection calls this.$selection.set(kept) and then this.#syncStore(), the #syncStore writes back to the store, which re-triggers the linkedSignal computation — but linkedSignal only recomputes when its source changes, so this is fine. However, the pattern is subtle enough that a future developer could easily break it by changing the signal type. Not a bug, but worth noting.

7. Step loading error in #focusScheme uses of([]) as the fallback, which then calls #cacheSteps(schemeId, []). An empty step list gets cached, so if the user navigates away and back to the same scheme, the component treats "empty" as loaded and never retries — the error is permanent for that session. The review discussion flagged the scheme-loading path (comment by oidacra on 2026-06-03) and it was fixed, but the step-loading error path in #focusScheme has the same problem: of([]) gets cached at line 385. Should probably not cache on error (return EMPTY and skip #cacheSteps in the error case). Fix this →

8. URL encode/decode collision risk: encodeFilters joins workflow tokens with ,, and each token is schemeId[:stepId]. UUIDs do not contain commas or semicolons, so this is safe in practice. But if a non-UUID scheme/step ID were ever used, a comma in the ID would silently corrupt the encoding. No current risk, but worth a comment in the multiSelector / workflow decode path.

9. decodeFilters processes workflow:schemeA:stepX,schemeB by splitting schemeA:stepX,schemeB at commas first (via multiSelector), yielding ['schemeA:stepX', 'schemeB']. This is correct. The encodeFilters path joins the array with commas. The round-trip test verifies this works. However, note that the URL segment workflow:schemeA:stepX,schemeB contains bare colons and commas — if the URL is ever percent-encoded by a router, the whole string survives only if the router doesn't encode those characters. The existing content-type filter has the same exposure, so this is consistent behavior.

Chore

10. .vscode/mcp.json (root) is added in this PR. MCP server configs can contain sensitive information. This file contains no credentials, only localhost/port references — this is fine, but the file should likely be in .gitignore (workspace-local tool config), or at minimum the PR author should confirm the team intends to commit this globally for all contributors.

---

Summary

The core logic is sound: SQL is parameterized, sanitization via SQLUtil.sanitizeParameter is applied, the scheme-only vs. step-pinned split is clear, and the copy constructor omission (item 1) is the only correctness issue worth fixing before merge. Item 7 (step error caching) is a UX defect but not a data integrity issue. The rest are minor notes.

[oidacra]

This PR removes $query / buildContentDriveQuery / escapeLuceneSpecialChars / BASE_QUERY. Per git history (2d7eb3e6, #35503) that $query computed was intentionally kept with an inline note tying it to #33338 ("Enable select all checkbox"), which is still open. The removal looks like reasonable cleanup if select-all is now going server-side via the new $request pipeline — could you confirm that's the plan (and ideally note it on #33338, or close it), so whoever picks that issue up later doesn't have to reconstruct the Lucene-query infra from history?

[zJaaal]

This PR removes $query / buildContentDriveQuery / escapeLuceneSpecialChars / BASE_QUERY. Per git history (2d7eb3e6, #35503) that $query computed was intentionally kept with an inline note tying it to #33338 ("Enable select all checkbox"), which is still open. The removal looks like reasonable cleanup if select-all is now going server-side via the new $request pipeline — could you confirm that's the plan (and ideally note it on #33338, or close it), so whoever picks that issue up later doesn't have to reconstruct the Lucene-query infra from history?

The removal was intentional