Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Workspaces can be integrated with Workbench Moderation to trigger a merge when a workspace's moderation state is set to published. This raises the question "What does it mean for a Workspace to be published?"
Can a user edit content on a published workspace? If so, does the state of the workspace get set back to draft? Are we even using the right terms to define workspace states? If we changed them to something like "Editable/Ready for Review/Deployed", would that make it more clear to the user? And, for that matter, should you be able to edit content in a workspace that is In Review?
Proposed resolution
I'm really not sure what to propose here. I suppose the following rules would make sense, but I'm pretty sure it's not ideal:
- Users cannot edit content on a published workspace, but aren't prevented from trying to do so.
- If a user does edit content on a published workspace, the workspace should automatically be set back to a draft state.
Remaining tasks
Discuss, come to a consensus, and implement!
User interface changes
Depends on the way forward, but if we implement something like the Proposed Resolution, some simple drupal_set_messages would help the user understand what's going on (E.g. "You are editing a node on a published Workspace. If you save your changes, the Workspace will be set back to Draft".)
Comments
Comment #2
phenaproximaMy unsolicited opinion on this is that a published workspace is any workspace, in any moderation state, that fulfills two criteria:
1) It has been deployed to the live workspace.
2) It has not been changed since it was last deployed.
This essentially defines "published" as "fully consistent with the live workspace", which IMHO is what 80% of users will be expecting. Just my $0.02.
Comment #3
balsamaI agree with phenaproxima's definition. I'd like to expand the issue a bit and define the workflow too.
It has been suggested that we could have two different types of workspaces. One that is somewhat ephemeral and one that is somewhat persistent. The differences between the two would mainly be around what happens after a workspace is merged (published). I can see the use case for both, but I'm worried that having more than one behavior would be confusing. So I vote for having consistent behavior across workspaces. And I think the more common use case is for workspaces to be somewhat ephemeral.
That would likely mean that once a workspace is published, it is automatically set to some defined state such as "Archived". I think site builders would need the ability to override that state in case they don't have an "Archived" state defined. But that would be the default. So that begs the question, "What is an 'Archived' workspace?".
I think workspaces can have three "super"-states - defined by what options are checked on the Moderation State edit form. These states don't necessarily correspond to the labels and machine names of the states themselves.
Archived
Users cannot switch to workspaces in this state - and therefore cannot edit content. Workspaces that are moved to a Published state will automatically be set to this state once the replication/merge is complete.
Editable
E.g. Draft or Needs review. Users can switch to workspaces in this state and modify content in them.
Published
This state triggers a replication and workspaces will automatically be set to a defined archived state once complete. So workspaces are only in this state while the replication is being performed.