Voting starts in March for the Drupal Association Board election.
Note: This is issue is part ofand is only meant for planning and governance sign-offs. Work will happen in child issues of this plan.
Target version: Drupal 8.4
Workspace API (no UI)
Introducing the concept of workspaces. Content entities always belong to a workspace (there is one main exception, which is the user entity type). A workspace is a silo/container of content on a site. However, this phase only introduces the underlying concept with one single workspace available, without many supporting APIs around it (see later phases). This phase will not change any UIs or behaviours in core.
See Workspace module for the current contrib implementation.
- Define the workspace entity itself
- Introduce the workspace reference field for all content entity types
- Extend storage handlers to work with workspaces
Entity revision indexes
Many functions and operations in later phases will rely on intensive lookups of certain metadata about revisions (e.g. does a revision exist, is it flagged as deleted, what sequence were revisions created in, etc). For this we need various indexes of basic revision metadata in order to improve performance and DX of looking this up.
- Revision UUID index
- Revision hash index
Richer Workspace API (still no UI or behaviour changes)
This phase will extend the Workspace API and provide underlying functionality for fetching basic info from workspace (what revisions are changed, what revisions are missing etc) as well as a basic implementation that let’s you replicate entities from one workspace to another.
Step 1: Additional services
Changes— service for fetching metadata about revision that has changes since a given sequence ID
RevisionsDiff— service for comparing what revisions are missing between two workspaces
Step 2: Workspace replication API (no UI)
See Workspace module for the current implementation in contrib.
Step 3: Conflict management API (no UI)
This is a big step. Now when entities can exist in multiple workspaces that can be replicated there needs to be APIs to support conflict management. This is only the underlying API and no UI will be implemented until phase H, step 1.
Initial plan for a plugin framework:
The merge algorithms needed will use lots of work from this Google Summer of Code project: Solving content conflicts with merge algorithms in Drupal 8.
Existing and related issues in core:
Step 4: Experimental UI
This step is optional and would cover a basic/experimental UI that will be elaborated on in phase I.
A product manager needs to sign-off on this plan because, although no UI is introduced and the out-of-the-box experience of Drupal won't change, the concept of workspaces constitutes a significant addition to Drupal core.
A framework manager needs to sign-off on this plan as the above phases introduces very significant API additions.
A release manager needs to sign off because the scope and impact of the work are significant for core.
The sub-system maintainers for the Entity API needs to sign-off on this plan as it significantly impacts the Entity API.
- Product manager - pending
- Framework manager - pending
- Release manager - pending
- Sub-system maintainers - pending