Allow hook content_lock_entity_lockable to disable locking

Created on 31 January 2020, over 4 years ago
Updated 27 August 2024, 11 days ago

There is a module invoke all hook content_lock_entity_lockable in the isLockable() method that could be used to allow custom code to disable locking on a per entity basis but right now the hook does not use the results.

Would it hurt to allow this functionality and let other modules optionally return FALSE to short circuit this method before checking the config?

🐛 Bug report
Status

Fixed

Version

2.0

Component

Code

Created by

🇺🇸United States mattsqd

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

Merge Requests

Comments & Activities

Not all content is available!

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

  • First commit to issue fork.
  • Status changed to RTBC 6 months ago
  • 🇺🇸United States smustgrave

    I believe this is correct but there is no api.php so not 100% sure if this was the intent of the hook. Going off of Missing content_lock.api.php Needs review

  • Pipeline finished with Success
    6 months ago
    Total: 258s
    #129117
  • Status changed to Needs work 6 months ago
  • 🇬🇧United Kingdom alexpott 🇪🇺🌍

    I'm not sure the hook even makes sense in it's current form. I thought maybe you could alter the $config but I'm pretty sure the $config array will be passed by value as it is just an array so any changes a module maybe would not count for anything.

    In Drupal 7 this was like this return !in_array(FALSE, module_invoke_all('content_lock_entity_lockable', $entity, $entity_id, $entity_type, $bundle)); so it works like what is being proposed here.

    I think we should:

    • Add automated tests (if we had these we would not have broken this)
    • Add documentation i.e. a .api.php with information about how this hook works.
    • Use a better implementation - we can do an early return the moment we get a false if we use invokeAllWith()

    Here's a sample implementation of a similar hook in another module.

        // Check if encryption is prevented due to implementations of
        // hook_field_encrypt_allow_encryption().
        $allowed = TRUE;
        $this->moduleHandler->invokeAllWith('field_encrypt_allow_encryption', function (callable $hook) use (&$allowed, $entity) {
          if ($allowed && $hook($entity) === FALSE) {
            $allowed = FALSE;
          }
        });
    

    I think we should expect hook implementations to return TRUE or FALSE and any other type of return should be an error.

    Changing to a bug because atm the hook is pointless.

  • Assigned to smustgrave
  • 🇺🇸United States smustgrave

    Will work on this evening

  • Pipeline finished with Failed
    5 months ago
    Total: 227s
    #130904
  • Pipeline finished with Failed
    5 months ago
    Total: 229s
    #130908
  • Pipeline finished with Success
    5 months ago
    #130909
  • 🇺🇸United States smustgrave

    Added some test coverage.

    For the api documentation I just went with $entity, $config, and $form_op for now
    Per slack can edit more if needed but assumed most info can be drawn from $entity.

    Updated contentLock and appears to be working.

  • Status changed to RTBC 5 months ago
  • 🇬🇧United Kingdom alexpott 🇪🇺🌍

    This looks great.

  • Pipeline finished with Skipped
    5 months ago
    #131235
  • Status changed to Fixed 5 months ago
  • 🇬🇧United Kingdom alexpott 🇪🇺🌍
  • Automatically closed - issue fixed for 2 weeks with no activity.

  • 🇮🇹Italy luca_cracco

    The reading configuration $config = $this->config->get("types.$entity_type");, prev the changes introduced, may return a null value that is not compatible with the declaration of the second argument of the hook function ( hook_content_lock_entity_lockable(\Drupal\Core\Entity\EntityInterface $entity, array $config, string $form_op = NULL)), which expects an array.
    This causes a TypeError error.

Production build 0.71.5 2024