Motivations

For now, it's impossible from a operations bulk form (E.g. visible in the Content views) to "Break locks" of all selected entity.

Resolution

Add a new system.action "Bulk Break Locks" & a new Plugin/Action to break all selected locks.
Here is a documentation about this process: https://www.flocondetoile.fr/blog/create-action-custom-mass-updates-drup...

It could then looks like this animated gif:
Break lock - bulk operation

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

wengerk created an issue. See original summary.

Jaber ME’s picture

Status: Active » Postponed
FileSize
3.26 KB

Solution :

I added this feature to view content list, I think it works well.

Jaber ME’s picture

Status: Postponed » Needs review
chr.fritsch’s picture

Thank you, it's a very nice feature request.

When we do this, we should try to provide this action for every entity type that is using content lock.

I will try to cook something up.

chr.fritsch’s picture

FileSize
3.55 KB

Here it's implementation with a deriver.

I would like to here @kfritsche feedback on this, especially on the release part.

Status: Needs review » Needs work

The last submitted patch, 5: 2938600-5.patch, failed testing. View results

chr.fritsch’s picture

Status: Needs work » Needs review
FileSize
8.31 KB
6.64 KB

Lets give this another push.

  • chr.fritsch committed ac6fb7c on 8.x-1.x
    Issue #2938600 by chr.fritsch, Jaber ME, wengerk: Add new Bulk Action to...
chr.fritsch’s picture

Status: Needs review » Fixed

Tests are passing. I think this is good to go.

kfritsche’s picture

Was reviewing it while it got committed :/

But still

  1. +++ b/src/Plugin/Action/BreakLock.php
    @@ -0,0 +1,74 @@
    +    $this->lockService->release($entity->id(), $entity->language());
    

    Missing entity type id.

  2. +++ b/src/Plugin/Action/BreakLock.php
    @@ -0,0 +1,74 @@
    +    return $object->access('update', $account, $return_as_object);
    

    Same issue as described in #2938092: Ajax lock not created due to strict permission checks, but would be fine for now.

  3. +++ b/src/Plugin/Action/BreakLockDeriver.php
    @@ -0,0 +1,96 @@
    +  protected function getApplicableEntityTypes() {
    +    $entity_types = $this->entityTypeManager->getDefinitions();
    +    $entity_types = array_filter($entity_types, function (EntityTypeInterface $entity_type) {
    +      return $this->isApplicable($entity_type);
    +    });
    +
    +    return $entity_types;
    +  }
    ...
    +  protected function isApplicable(EntityTypeInterface $entity_type) {
    +    return $entity_type->entityClassImplements(ContentEntityInterface::class);
    +  }
    

    Not sure about this. Would it make sense to check configs here, if type is lockable?

General note regarding caching. I'm unsure about this, but maybe just to think about it. Are Actions cached? Views are cached could this run into problems?

kfritsche’s picture

Status: Fixed » Needs work
chr.fritsch’s picture

Thanks for reviewing. I try to be more patient next time 😆

1. Nice find
3. I think thats fine. That doesn't mean that there are actions. That just means that these entity types could possibly used for the action.

The general problem is, that the view is most of the times cached. So the view says the entity is still locked, but it isn't. We have this problem with the "Break lock" operation as well. So thats not a problem of actions.

  • chr.fritsch committed 3beb6d1 on 8.x-1.x
    Issue #2938600 by chr.fritsch, Jaber ME, wengerk: Add new Bulk Action to...
chr.fritsch’s picture

Status: Needs work » Fixed

Fixed 1.

  • chr.fritsch committed 8588d57 on 8.x-1.x
    Issue #2938600 by chr.fritsch, Jaber ME, wengerk: Add new Bulk Action to...

Status: Fixed » Closed (fixed)

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