Voting starts in March for the Drupal Association Board election.
For content moderation, there are the following concepts:
- state - configuration entity for a moderation state
- transition - configuration entity for the (one way) from and to relationship between two states
- valid states - the states that are allowed on a particular entity bundle, stored as a third party setting
This means you need to have two different config entity types, several individual entities of those types, as well as bundle third party settings to figure out what the workflow is for a particular bundle entity.
It also results in some trickiness with things like ordering states/transitions - since each needs to store its own weight relative to the others. This is usually a sign that data shouldn't be in configuration entities but rather a single object.
Also I can see people wanting to use this system for workflow on users (account pending, e-mail validated, approved, blocked etc.), even though they wouldn't use forward revisions for that, or even necessarily revisions. However those states are extremely user-specific, and something like translation editorial review is never going to apply to account entities too. So not sure how useful the global states and transitions are conceptually.
Consider consolidating this information into one or two objects per-entity or per-bundle (or per entity with per bundle overrides).
So something like (excuse the invalid YAML). This isn't a proposal as such, just something for comparison.
states: - draft: label: draft - published: label: published - archived: label: archived transitions: - draft_published: from: draft to: published
In chat @alexpott pointed out that http://symfony.com/blog/new-in-symfony-3-2-workflow-component exists, this has a concept of a single 'workflow' that contains all the information. Again not a proposal but something to compare against.
Adds a new experimental Workflows module that provides
- A workflow configuration entity type. This is where states and transitions are configured.
- The concept of workflow type plugins. This is how modules can leverage workflows and extend the information stored against a state or a transition. If there are no workflow type plugins the user can not create workflows because there is nothing to apply them to.
- Fluid API for workflow entities:
$workflow = new Workflow(['id' => 'test', 'type' => 'test_type'], 'workflow'); // By default states are ordered in the order added. $workflow ->addState('draft', 'Draft') ->addState('published', 'Published') ->addState('archived', 'Archived') ->addTransition('create_new_draft', 'Create new draft', ['draft', 'published], 'draft') ->addTransition('publish', 'Publish', ['draft', 'published'], 'published');
- A workflow creation UI. A user interface that can create, edit and delete workflows and their states and transitions.
Changes content moderation module by:
- Removing the state and transition configuration entities
- Changing the content moderation state content entity to record the workflow and state used.
- Adds a new workflow type to moderate content entities.
- Changes the permission names to include the workflow label
- Changes how workflows are added to bundles. Instead of arranging states and transitions on the bundle you just select a workflow.
- Just makes sense. Arranging a workflow on each bundle is a repetitive task and states and transitions not belonging to a workflow entity means that in order to create a workflow in HEAD you have to load all sorts of things. This also means we can totally get around issues with duplicate state names.
- States are ordered on the workflow using table drag.
- Allows additional configuration on both the state and transition level
- Allows workflows to be applied to things other than content by contrib
Experimental module / release strategy
All the changes are in experimental code.
Review patch, make decisions, and create / find followups
What should the workflow provided by the content moderation be called. At the moment it has the ID 'typical' and the label 'Typical workflow'changed to 'Editorial workflow' / editorial see #117 Decide how much of the UI work to include here - created follow up Should we continue to use the word "State" or use the more generic and common in workflow theory "Place"?Chose
statesince the arguments in #95 are compelling
Should the new module by called "Workflow"? This clashes with a 8.x contrib module. Ee could use "Workflows" just to avoid the issue.We called the experimental module "Workflows" Should transitions have multiple from states? And should transitions have multiple from states?We implemented multiple from states and a single to state - see #107
User interface changes
New UI for creating workflows - see #22 for a flavour.
Changed UI for attaching workflows to content entities.
New workflow configuration entity
New workflow type plugin type
Removed ModerationState config entity
Removed ModerationTransition config entity
Data model changes
The content moderation state content entity no longer references a ModerationState config entity by references a Workflow config entity and records a state ID.