content_lock_entity_operation doesn't work if the entity list is cached

I think this is not only a problem with the entity operations. Content lock also offers some view fields, for e.g. owner of the current lock. Adding/ removing a lock, doesn't invalidate this fields, so the view is then out of date as well.

Here's a patch that invalidates the cache tag for the entity and for the entity list for that entity's entity type.

This fixed the issue for me on a view where unlocking or locking wasn't updating the view.

I had both issues (the one of the issue description and the one described by @chr.fritsch) and the patch fixes both. Thanks!

The patch looks good to me. Maybe it doesn't cover every case where the list is cached but at least solves the most obvious one.

And, what about the 8.x-2.x-dev branch?

Flushing the entity_list tag might not be a good idea since this will also affect frontend. Maybe flushing only the view / view result cache of the view, the action was triggered from, would be a more sensible approach. That imho would have to be done from views bulk operation form.

Working in 2.x for me.

Patch fails to apply in both branches in tests.

Patch applies on version 2.3.0 and fixes the issue stated above.

Comment in #8 should still be taken into account but marking this as reviewed since it does work and fixes the issue.
Up to the maintainer to see if they want to implement it this way or not.

I think given #8 we need to come up with a better approach.

Something like the operation adds some other cache tag to the view that we can then use to clear when we need to. This list cache tag is way too generic.

added 'content_lock:' to make it more unique.

@smustgrave the new cache tage should not be specific for an entity ID and we should not clear the entity list cache list here.

Also need to add the cache tag to the break lock operation so that views that use this have the new cache tag in them and are cleared when necessary.

I believe this would be fixed with #2473873: Entity operations lack cacheability support, resulting in incorrect dropbuttons in core.

After applying the patch to the Core issue 2473873, we ran into a new issue that the "Masquerade as" operation is not displayed in the people admin view due to access check.

If the lock status is displayed in some views, how would this module know which views would need their caches to be invalidated when an entity is locked or unlocked? Would those views need a special cache tag to be added manually or automatically?

In the mean time, re-rolled the patch for v3.0 Alpha 4 in case someone needs this.

content_lock-caching-invalidation-2919019-4.patch cannot work for 3.0.0-alpha4 due other codebase changes that are not taken into account.

Started MR97 on the 3.x to keep the current solution up to date, until something better comes up.

Here's a new patch against 3.x

@jviitamaki I'm not convinced that this is the best fix - I think it'd be better to disable the views cache on your admin content lists - blowing the entity cache and list cache due to releasing a lock feels wrong as per #13.

We need to add the CacheableMetadata argument into \Drupal\content_lock\Hook\ContentLockHooks::entityOperation() and use it to make the entity operations uncacheable is the entity is lockable. We also need to add the config as a dependency to the cacheable metadata even when the entity type is not lockable.

I've added an MR to set the cacheable metadata in \Drupal\content_lock\Hook\ContentLockHooks::entityOperation() - now we need to add some test coverage...

Moving this to the 3.x queue as 8.x-2.x is about to the retired.

Looks great!