[sneridagh]

Step 4 of #2061. Stacked on #2080.

What a workflow UI needs: the available workflows with enough detail to plan a state mapping, and changing the workflow of a type, or the default one, with a preview of what happens to existing items.

GET /@workflows

• Every workflow in portal_workflow, sorted by translated title, with @id, id, title, description, initial_state and the IDs of its states, plus the site's default (null when the default chain is empty).
• GET /@workflows/{id} returns one workflow in full: states with title, description, transitions, visibility and permission_roles; transitions with title, description, new_state and guard (permissions, roles, expression); and the types whose effective chain has the workflow, including types following the default. Unknown IDs return 404.
• visibility comes from the roles with View: anyone (Anonymous), members (Authenticated or Member), restricted (explicit roles only), or unknown (the state doesn't manage View, or acquires it without Anonymous). DCWorkflow stores acquired permissions as a list, the others as a tuple.
• Titles and descriptions are translated in the plone domain. Transition titles are the action titles ("Publish"), as in @workflow.
• States are in the workflow's own order, which for workflows imported by GenericSetup is alphabetical.
• No color yet: DCWorkflow has nowhere to store it.

GET, POST /@content-types/{type}/workflow

• GET returns {"@id", "id", "follows_default"}, the same as the workflow of the type.
• POST takes {"workflow": "…" | null} or {"follows_default": true}, an optional state_map, and dry_run. Unknown workflows, unknown target states and a body with neither return 400; unknown types 404.
• With dry_run, it changes nothing and returns the target workflow, the current one, one entry per current state with its item count and the suggested new state, and unaffected: items under a placeful workflow policy that give them another workflow (0 without portal_placeful_workflow). A type without a workflow has a single entry with "id": "". Counts are unrestricted catalog queries on portal_type and review_state.
• The suggestion keeps who can see the items: the most visible target state that isn't more visible than the source, else the least visible one; among those, the same ID, then the same title, then the initial state, then the first. The same algorithm as the Aurora frontend.
• Without dry_run, it applies the mapping with plone.app.workflow's remap_workflow, as the classic types control panel does: it updates security and reindexes. States left out of state_map get the suggested state. It returns {"workflow", "follows_default", "changed"}. When the effective workflow doesn't change (for example the default workflow assigned explicitly), only the assignment changes and changed is 0.

POST /@workflows

• Changes the site default, with the same request and dry run shapes (default instead of workflow), plus the types following the default. Like the classic form, it pins the old chain on the types following the default, changes the default, and remaps them back to (Default). Returns {"default", "changed"}.

Docs

• A new workflows.md
• content-types.md: "Change the workflow"
• New http examples: workflows_get, workflows_get_item, workflows_post_dry_run, workflows_post, content_types_get_workflow, content_types_post_workflow_dry_run and content_types_post_workflow

Tests

• test_services_workflows.py: listing, no default, the full workflow, types with explicit chains, visibility (including acquired and unmanaged View), suggestions keeping visibility, default changes (dry run, apply, no default), invalid requests, and permissions
• test_services_contenttypes.py, TestContentTypesWorkflow: GET, dry run counts and suggestions (published in simple publication → external in intranet), dry runs to and from no workflow, applying (real items move, security follows), back to the default, same workflow, no workflow, 400s, 404s, items under a placeful policy, and the new paths in the permission tests

Full suite: 1539 tests. 7 fail, and the same 7 fail on #2080's branch: date-dependent tests in test_workflow, test_search and test_statictime.

[read-the-docs-community]

Documentation build overview

📚 plone.restapi | 🛠️ Build #35671067 | 📁 Comparing 5ff93d9 against latest (1cca588)

  🔍 Preview build  

13 files changed · + 2 added · ± 11 modified

+ Added

• endpoints/behaviors.html
• endpoints/workflows.html

± Modified

• endpoints/aliases.html
• endpoints/breadcrumbs.html
• endpoints/comments.html
• endpoints/content-rules.html
• endpoints/content-types.html
• endpoints/types.html
• endpoints/users.html
• endpoints/vocabularies.html
• endpoints/workflow.html
• endpoints/workingcopy.html
• and 1 more...

[sneridagh]

LGTM

[sneridagh]

@davisagli there are two required checks that are not running? I think it happens in all this stack

[davisagli]

@sneridagh It's the normal Jenkins builds. They don't run until you ask mr.roboto to start them.

[davisagli]

I reviewed the docs, but not the implementation yet.