Sub workspace does not clear

This will be fixed in #3323317: Revision metadata is not updated when a workspace is merged into its parent.

Turns out I was wrong in #2, the problem here is WorkspaceAssociation::onPostPublish() not deleting the associations of sub-workpaces.

Bumping for visibility.

As the workspace association is not getting deleted, One is not able to edit the content on the live workspace even if the content is published. Right now getting the message that content can not be edited as the content is edited in the sub workspace.
A temporary workaround is to delete the association manually (from the database) after merging the sub-workspace with the parent workspace.

Hello all here,

I had the same bug and fixed it in the way of adding additional cleanup on publication to Live workspace.
See details in attached patch file.

Hello, all fixes should be in MRs against 11.x so tests will run.

Also issue summary should be complete and a clear title. Tagging for both.

With most bugs will also need a test case showing the issue

Hi, I have created an MR incorporating the patch changes from comment #9 and added a test case to validate these changes as outlined in comment #11. The issue summary has been updated accordingly.

I am removing the "Needs issue summary update" and "Needs tests" tags. If anyone believes these tags should still be applied, please feel free to re-add them.

Kindly review the changes and let me know if any further adjustments or updates are needed. Your feedback and suggestions for further improvements are greatly appreciated.

Thanks!

Reviewed code of #13 (and #9) and tested on Drupal 11.0.1 clean Standard installation with default and custom content types, taxonomy terms, and menu links. The bug experienced is no longer happening. Updating status to RTBC.

One question on the MR.

Feedback appears to be addressed.

Thanks that looks better.

Committed/pushed to 11.x and cherry-picked back through to 10.3.x, thanks!

Hello all,

The code:

    if (!$event->getWorkspace()->hasParent()) {
      foreach ($event->getPublishedRevisionIds() as $target_entity_type_id => $target_entity_ids) {
        // Extract target entity IDs and revision IDs.
        $target_entity_ids_list = array_keys($target_entity_ids);
        $target_entity_revision_ids = array_keys($target_entity_ids);

        $this->deleteAssociations(NULL, $target_entity_type_id, $target_entity_ids_list, $target_entity_revision_ids);
      }
    }

which was committed to the core, there is a bug in this line:

        $target_entity_ids_list = array_keys($target_entity_ids);

The $target_entity_ids variable is an array where keys - revision IDs and values - entity IDs. So instead of:

        $target_entity_ids_list = array_keys($target_entity_ids);

should be:

        $target_entity_ids_list = array_values($target_entity_ids);

to get entity IDs instead of revisions.

Thanks that's a good spot!

I've rolled this back from all four branches, let's re-add it with some additional test coverage.

Thank you, @antonnavi, for highlighting the incorrect usage of $target_entity_ids_list = array_keys($target_entity_ids);.

I’ve updated the code to use $target_entity_ids_list = array_values($target_entity_ids);, which correctly retrieves the entity IDs instead of revision IDs. Additionally, I've added test coverage to verify this change, ensuring that workspace associations are properly cleaned up when publishing the workspace.

Kindly review the changes and please let me know if any further adjustments are needed. Your feedback and suggestions for improvements are greatly appreciated.

Thanks!

In this context is array_values actually useful? i.e. do we need to replace the revision ID keys with indexed keys or does it not matter?

#34 seems worth exploring.

Reviewed the MR and fixed all my comments, sorry for taking so long to get to this folks.

Feedback appears to be addressed!

Committed/pushed to 11.x and cherry-picked back through to 10.3.x, thanks!