Entity queries for latest revisions should return the latest workspace-specific revisions

Darren Oh → made their first commit to this issue’s fork.

catch was just asking a question. This change is necessary to ensure predictable behavior with code that is not workspace-aware. I am currently trying to set up workspaces for a major client, and a blocker is that the edit tab does not load the revision for the current workspace by default.

Darren Oh → closed merge request !6682

@Darren Oh, I think you're the first one to actually bump into this problem that was only theoretical so far, so I'm wondering if you can share any more info about the code that is not workspace-aware and it was loading the wrong revision :)

As for the MR, let's switch the order in the condition and check for isEntityTypeSupported() before hasActiveWorkspace(), see 🐛 Fix workspace-support check in entity queries Fixed for a recent example why this matters.

Sure I can share more info. If you have multiple workspaces, the first workspace in which a node is edited blocks editing in all other workspaces because the edit tab always loads the most recent revision. You'll get a message saying the node is being edited in another workspace and changes cannot be saved. The expected behavior is that the most recent live revision is loaded and copied to the current workspace.

The expected behavior is that the most recent live revision is loaded and copied to the current workspace.

That's not the expected behavior in core at the moment. Editing the same entity in different workspaces requires a conflict resolution solution, which doesn't exist in core (yet?), that's why we actively prevent it.

If you'd like to give editors the ability to edit the same entity in different workspaces, with the (important!) caveat that whichever workspace is published last "wins" (i.e. the changes from the previously-published workspace will be lost), I'd suggest to override the plugin class of the EntityWorkspaceConflict constraint with a custom one.

I did override the EntityWorkspaceConflict constraint. Also had to apply the fix from this issue.

There must be something else at play then, because I tried the snippet below and the following steps:

1. edit a node in a workspace, save
2. edit the node in Live, save
3. create a new workspace, and editing the node showed me the revision created in step 2.

--- a/core/modules/workspaces/src/Plugin/Validation/Constraint/EntityWorkspaceConflictConstraintValidator.php
+++ b/core/modules/workspaces/src/Plugin/Validation/Constraint/EntityWorkspaceConflictConstraintValidator.php
@@ -79,6 +79,7 @@ public static function create(ContainerInterface $container) {
    * {@inheritdoc}
    */
   public function validate($entity, Constraint $constraint) {
+    return;
     /** @var \Drupal\Core\Entity\EntityInterface $entity */
     if (isset($entity) && !$entity->isNew()) {
       $active_workspace = $this->workspaceManager->getActiveWorkspace();

amateescu → changed the visibility of the branch 3045177-test-only to hidden.

While working on 📌 Allow for / implement simplified content workflow with workspaces Active , it turned out that this is very much needed for that issue, and for ✨ Ability to edit content in live workspace when it has been edited in other workspaces Active as well.

Pushed an update to also handle latest translation affected revisions.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The bot is trying to apply the 11.1.x MR to 11.x

The MR needs to be against 11.x since that's the target for commits, the bot isn't wrong there.

This could use an issue summary about why it needs to be done and what the impact is.

The bot is confused when there are multiple MRs. 6681 (3045177-workspace-specific-latest-revision) is the one for 11.x. Updated the IS.

Looks great to me!

Had just one question, but that is minor.

Tests also make sense.

FWIW, here is a test summary by AI:

This is a kernel test for Drupal's Workspaces module, specifically testing how entity revisions are managed in different workspaces and languages. Let's break it down:

**1. Key Components:**
- **Workspace Context:** Tests how entities behave when edited in different workspaces ('ham', 'cheese') vs Live environment
- **Multilingual Support:** Tests with English (en) and Romanian (ro) languages
- **Two Entity Types:**
- `entity_test_revpub`: Revisionable, non-translatable entity
- `entity_test_mulrevpub`: Revisionable AND translatable entity

**2. Test Flow:**

**A. Non-translatable Entity Test:**
1. Creates initial entity in Live
2. Creates revisions in workspaces:
- 'ham' workspace revision
- 'cheese' workspace revision
- New Live revision
3. Verifications:
- Each workspace sees its own revision
- Live sees the latest Live revision
- Workspaces maintain their revisions even after Live updates

**B. Translatable Entity Test:**
1. Creates multilingual entity with EN/RO translations in Live
2. Tests workspace-specific translations:
- Creates RO translation revision in 'ham'
- Creates RO translation revision in 'cheese'
- Creates new RO translation in Live
3. Verifications:
- Correct workspace-specific RO translations are returned
- Language context (en/ro) is respected
- Workspace revisions remain isolated from each other and Live

**3. Key Technical Checks:**
- `EntityRepository::getActive()` correctly resolves:
- Workspace context (which revision is active in which workspace)
- Language context (which translation to show)
- Revision tracking across workspaces
- Workspace switching mechanics (`switchToWorkspace()`/`switchToLive()`)
- Proper isolation of workspace-specific revisions

**4. Why This Matters:**
- Ensures content editors in different workspaces don't interfere with each other
- Validates proper version control for multilingual content
- Maintains data integrity when publishing from workspaces to Live
- Tests core Workspaces module functionality at the storage layer

The test uses kernel-level testing (without full HTTP stack) to validate these low-level entity operations efficiently.

Edited code to enhance clarity.

Edited issue summary.

Where it states 'The only impact on existing sites is that entity queries will function properly if the locking protection mentioned above was bypassed in custom code.' in the issue summary should that be '...entity queries will not function properly...'?

No, Drupal was relying on the locking mechanism to hide this bug from users. Existing sites that bypass the locking mechanism in custom code will now work properly without needing additional workarounds.

@darran oh Great! MR seems good to me.

Rebased.

One question on the MR.

Replied to the MR comment. It seems that the number of MRs here causes some confusion, so here's a quick breakdown for them:

11.x -> MR !6681
11.1.x -> MR !10971
10.5.x (and below) -> MR !10973

And to reply to that comment here as well, note that in the 11.x MR the hook implementation is in the proper place: core/modules/workspaces/src/Hook/EntityOperations.php

OOP hooks made it very "fun" to work on the Worskspaces module :)

Sorry I completely missed that was the 11.1 MR. However I left one more question on the 11.x MR about an explanatory comment and possibly additional test coverage.

amateescu → changed the visibility of the branch 3045177-10.5.x to hidden.

Updated both the 11.x and 11.1.x MRs to expand that comment, and added explicit test coverage.