Problem Statement
The chip-filter UI for "workflow" in content drive needs to know which workflow schemes are valid options given the user's currently-selected content types. The existing endpoint (GET /api/v1/workflow/schemes/schemescontenttypes/{contentTypeId}) only accepts a single content type ID. Calling it N times client-side is slow and creates ordering/race conditions in the UI.
Acceptance Criteria
- New endpoint that accepts a list of content type identifiers (variable names or IDs) and returns the union of workflow schemes assigned to those content types.
- Response shape:
{ schemes: WorkflowSchemeView[] } (a content type → schemes breakdown is not needed for the current UI; can be added later if required).
- Schemes are deduplicated by scheme ID before being returned.
- Empty input list returns
{ schemes: [] } (200 OK), not 400.
- Unknown content type IDs are silently ignored (do not 404 the whole request).
- Auth/permissions: same model as the existing single-content-type endpoint.
Implementation Pointers
- Reuse
WorkflowAPI.findSchemesForContentType(ContentType) per content type and combine results.
- Deduplicate by scheme ID before returning.
- The existing single-content-type endpoint stays for backward compatibility.
Discussion Point — Endpoint Shape
The recommended shape is a new POST /api/v1/workflow/schemes/schemescontenttypes with a JSON body: { "contentTypes": ["Blog", "News"] }. This matches the dotCMS multi-value convention used in DriveRequestForm and avoids touching the existing path-param endpoint.
Alternative: extend the existing endpoint to also accept a CSV path parameter or query param. Cheaper to ship but mixes two URL contracts on one path.
The implementer should confirm with the team before choosing. The default recommendation is the new POST.
Tests
- Unit:
WorkflowResourceTest covering empty input, single content type, multiple content types with overlapping schemes, multiple content types with disjoint schemes, unknown content type ID mixed with valid ones.
- Integration:
dotcms-integration covering permission denial.
- Postman: new entry under the workflow collection.
Out of Scope
- Filtering by archived schemes, languages, or workflow actions.
- Returning workflow steps (steps come from a separate API; this endpoint only returns schemes).
- Per-content-type breakdown of which scheme came from which type.
Problem Statement
The chip-filter UI for "workflow" in content drive needs to know which workflow schemes are valid options given the user's currently-selected content types. The existing endpoint (
GET /api/v1/workflow/schemes/schemescontenttypes/{contentTypeId}) only accepts a single content type ID. Calling it N times client-side is slow and creates ordering/race conditions in the UI.Acceptance Criteria
{ schemes: WorkflowSchemeView[] }(a content type → schemes breakdown is not needed for the current UI; can be added later if required).{ schemes: [] }(200 OK), not 400.Implementation Pointers
WorkflowAPI.findSchemesForContentType(ContentType)per content type and combine results.Discussion Point — Endpoint Shape
The recommended shape is a new
POST /api/v1/workflow/schemes/schemescontenttypeswith a JSON body:{ "contentTypes": ["Blog", "News"] }. This matches the dotCMS multi-value convention used inDriveRequestFormand avoids touching the existing path-param endpoint.Alternative: extend the existing endpoint to also accept a CSV path parameter or query param. Cheaper to ship but mixes two URL contracts on one path.
The implementer should confirm with the team before choosing. The default recommendation is the new POST.
Tests
WorkflowResourceTestcovering empty input, single content type, multiple content types with overlapping schemes, multiple content types with disjoint schemes, unknown content type ID mixed with valid ones.dotcms-integrationcovering permission denial.Out of Scope