#Workflow Initiative

catch → closed merge request !11871

Looks good. Committed/pushed to 11.x, 11.1.x and 10.5.x, thanks!

Thanks summary reads well

I was able to replicate following the steps and the MR does appear to address the problem
Test coverage seems to be there too.

LGTM

Updated the IS.

Instead of a new test could the existing tests be expanded, where you made the edits.

Can the IS be updated please.

@adamzimmermann

It feels weird to need a contrib module for core functionality to work though.

That's because core moves at a slower pace, and production sites needed a lot of various fixes for Workspaces that were lingering for years in the core queue for various reasons. Workspaces Extra had to incorporate all these little fixes to prevent developers from using a huge list of patches into their projects.

Opened a MR with a fix and test coverage for this issue.

Automatic testing failed because of update to 3.0 branch. Manually applying the patch is working on my project but we need to update the patch and continued testing.

At this moment, I am not sure if this is a long term solution. Open to hear oppinions.

This works for me, and it will finally show users without the right permissions what the publish status is, but also they can't change it.

Screenshots added

I write a script on composer that removes book core module. For now this should work for anyone that needs a quick fix.

{
    "scripts": {
        "post-install-cmd": [
            "rm -rf web/core/modules/book",
            "@composer drupal:scaffold"
        ],
        "post-update-cmd": [
            "rm -rf web/core/modules/book",
            "@composer drupal:scaffold"
        ]
    }
}

Last development version for this module has the required validation for $value->book on src/Plugin/Validation/Constraint/BookOutlineConstraintValidator.php

if (isset($value) && !empty($value->book) && !$value->isNew() && !$value->isDefaultRevision()) {

This should be working, but is not. This may be related to the update from core to contrib module.

The primary issue is with the BookOutlineConstraintValidator in the Book module. This validator is designed to prevent changes to book outlines in non-default (draft) revisions.
The key problematic code is in the validate() method of the BookOutlineConstraintValidator class:

public function validate($entity, Constraint $constraint): void {
  // Validate the book structure when the user has access to manage book
  // outlines. When the user can manage book outlines, the book variable will
  // be populated even if the node is not part of the book. If the user cannot
  // manage book outlines, the book variable will be empty, and we can safely
  // ignore the constraints as the outline cannot be changed by this user.
  if (isset($entity) && !$entity->isNew() && !$entity->isDefaultRevision()) {
    /** @var \Drupal\Core\Entity\ContentEntityInterface $original */
    $original = $this->bookManager->loadBookLink($entity->id(), FALSE) ?: [
      'bid' => 0,
      'weight' => 0,
    ];
    if (empty($original['pid'])) {
      $original['pid'] = -1;
    }

    if ($entity->book['bid'] != $original['bid']) {
      $this->context->buildViolation($constraint->message)
        ->atPath('book.bid')
        ->setInvalidValue($entity)
        ->addViolation();
    }
    // Additional validation code...
  }
}

This constraint validator triggers when:

1. An entity exists (isset($entity))
2. The entity is not new (!$entity->isNew())
3. The entity is not the default revision (!$entity->isDefaultRevision())

Since this appears to be a UI change can the summary get some bfore/after screenshots please

Thanks!