Creating an unpublished entity in a workspace does not set the workspace field on the revision

Created on 21 April 2020, over 4 years ago
Updated 4 May 2023, over 1 year ago

Problem/Motivation

When adding a new unpublished content entity in a workspace, the workspace revision metadata field on the entity is not set, resulting in the content being attributed to 'Live'. The content is still attached to the workspace in a workspace_association table row.

As things stand if a user is in a workspace and creates a piece of content it does not appear in that workspace when using views that filter by workspace.

SELECT * FROM node_revision WHERE nid = 1; SELECT * FROM workspace_association WHERE target_entity_id = 1;
nid         vid         langcode    revision_uid  revision_timestamp  revision_log  revision_default  workspace 
----------  ----------  ----------  ------------  ------------------  ------------  ----------------  ----------
1           1           en          1             1587501174                        1                           
workspace   target_entity_type_id  target_entity_id  target_entity_revision_id
----------  ---------------------  ----------------  -------------------------
stage       node                   1                 1                        

This workspace field is set when

  • A new revision is created on an existing entity
  • A new published entity is created

Proposed resolution

Track the initial revisions created in a workspace, for both published and unpublished entities.

🐛 Bug report
Status

Fixed

Version

10.1

Component
Workspaces 

Last updated about 8 hours ago

No maintainer
Created by

🇬🇧United Kingdom alexj12

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇷🇴Romania amateescu

    This problem was also discovered in 🐛 [PP-1] Prevent content from being deleted when there is an active workspace Postponed . I will bring over the relevant changes from that issue to this one because the fix is a bit more involved than the current patch.

  • 🇷🇴Romania amateescu

    Let's start with explicit test coverage for this bug, and the fixes required for it.

    The second patch will fail _other_ tests because we need to update that test coverage to account for the change we're introducing: when creating a new entity in a workspace, either published or unpublished, the initial revision will now be considered as part of the workspace.

    Leaving at needs work for now, will followup with the complete patch.

  • 🇨🇦Canada adriancid Montreal, Canada

    I had these errors while testing the patch, so I added a validation to check for the existence of the element in the array:

    • Warning: Undefined array key "test_delete_workspace" in Drupal\workspaces\WorkspaceAssociation->getAssociatedRevisions() (line 179 of /var/www/html/web/core/modules/workspaces/src/WorkspaceAssociation.php) 
    • Warning: Trying to access array offset on value of type null in Drupal\workspaces\WorkspaceAssociation->getAssociatedRevisions() (line 179 of /var/www/html/web/core/modules/workspaces/src/WorkspaceAssociation.php) 
    • TypeError: array_merge(): Argument #2 must be of type array, null given in array_merge() (line 179 of /var/www/html/web/core/modules/workspaces/src/WorkspaceAssociation.php)
  • 🇨🇦Canada adriancid Montreal, Canada

    Fixing a problem with undefined $workspace_candidates.

  • 🇷🇴Romania amateescu

    The test-only patch from #15 was flawed, it didn't take into account editing an existing entity in a workspace. Reworked the test coverage to cover all cases, and this shows that we can't check for "initial revisions" (of the entities that are created in a workspace) at the moment.

  • 🇷🇴Romania amateescu

    These are the fixes needed for the test-only patch from #18. As mentioned in #15, some other tests will fail because workspaces are now tracking initial default revisions, and I will follow up with a complete patch.

  • Issue was unassigned.
  • Status changed to Needs review over 1 year ago
  • 🇷🇴Romania amateescu

    Here are the changes needed to fix the existing test coverage. This is fully ready for reviews now.

  • Status changed to RTBC over 1 year ago
  • 🇨🇦Canada adriancid Montreal, Canada

    We are using this patch in a production site and is working as expected. I know usually it needs some screenshots but I can confirm is working.

  • Status changed to Needs work over 1 year ago
  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    There's some API changes here (new arguments to plugin constructors, new methods).
    Whilst we don't have to provide a BC layer, it would be nice to add a change notice, so tagged for that.

    We've not had a test-run that shows the new tests fail yet (they didn't pass the custom checks so tests didn't run) - so can we get a red/green set of patches - ie one with just the tests, and one with tests and fixes.

    Couple of minor observations

    1. +++ b/core/modules/workspaces/src/WorkspaceAssociation.php
      @@ -192,6 +200,42 @@ public function getAssociatedRevisions($workspace_id, $entity_type_id, $entity_i
      +  public function getAssociatedInitialRevisions($workspace_id, $entity_type_id, $entity_ids = NULL) {
      
      +++ b/core/modules/workspaces/src/WorkspaceAssociationInterface.php
      @@ -74,6 +74,23 @@ public function getTrackedEntities($workspace_id, $entity_type_id = NULL, $entit
      +  public function getAssociatedInitialRevisions($workspace_id, $entity_type_id, $entity_ids = NULL);
      

      Can we get typehints here for new code

    2. +++ b/core/modules/workspaces/src/WorkspaceManager.php
      @@ -316,31 +316,60 @@ public function purgeDeletedWorkspacesBatch() {
      +          $associated_entity_storage->delete([$associated_entity_storage->load($initial_revision_ids[$revision_id])]);
      

      should we try to do this in bulk outside the foreach loop?

  • Status changed to RTBC over 1 year ago
  • 🇷🇴Romania amateescu

    Good point about the CR, wrote one here: https://www.drupal.org/node/3352703

    Attaching the test-only patch from #18 with the custom checks fixed, as well as the complete one from #20 with the point from #22.1 fixed.

    I thought a lot about #22.2 while working on this patch and eventually settled on the argument that this is "just" cleanup code that usually runs on cron, and that it's better to be correct and easy to read rather than fast. Loading multiple default revisions would only save a few cache gets anyway :)

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    29,203 pass
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    29,284 pass
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    29,301 pass
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    29,303 pass
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    29,305 pass
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    29,360 pass
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    40:33
    37:19
    Running
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    29,367 pass
    • catch committed cd12944d on 10.1.x
      Issue #3129762 by amateescu, adriancid, msuthars, Alexj12: Creating an...
  • Status changed to Fixed over 1 year ago
  • 🇬🇧United Kingdom catch

    This is tricky but the changes look solid and agreed the CR is plenty for the changes.

    Committed/pushed to 10.1.x, thanks!

  • 🇳🇿New Zealand quietone

    I published the change record

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024