juanolalla / content_lock Goto Github PK

As @martincollar mentioned in https://www.drupal.org/node/2606858#comment-11832539:

Route content_lock_timeout.settings_form should require "administer content lock" permission instead of "access administration pages". For example with this permission my editors (they have access to admin pages) will be able to setup timeout for locks.

As @dawehner explained in https://www.drupal.org/node/2606858#comment-11817124, and @chrfritsch pointed out in https://www.drupal.org/node/2606858#comment-11831036, there is no reason for not supporting any entity type, instead of specifically supporting and so for duplicating the code for node, taxonomy_term and block content entity types. The module should not have a hard dependency on the block_content module, neither with any other specific entity type module.

As a follow up we could move this logic into a new handler type on entity types, so you can implement your own logic if needed. inline_entity_form does something similar.

@jazzdrive3 proposes the following config changes. These are required for the new Strict Schema testing that is enabled by default for Drupal 8 tests.

New file in config/schema: content_lock.views.schema.yml
views.filter.content_lock_filter:
type: views.filter.boolean
label: 'Is Locked'
mapping:
value:
type: string
label: 'Value'

And then in config/optional/views.view.locked_content.yml, change line 227 to be
value: '1'

@dawehner proposed this improvement in: https://www.drupal.org/node/2606858#comment-11817124

Conceptually this really reminds me of the locking feature in views. We are using the tempstore functionality in the user module for that (service: user.shared_tempstore), which should make all the DB storage here redundant.

After using the site with content lock for a few days, it's become clear that a cancel button is needed. Consider this scenario:

• User visits a node (locking it from other editors)
• User decides they aren't ready to work on it.
• User clicks the back button or the 'View' tab.
• In this case, the content is locked. The only way for the content to unlock is to save the node, which isn't always the desired action. You may wish to leave the node without changing it, and end the lock.

For this reason it appears we need a cancel button on nodes where the user has a lock, so they can clear the lock without saving.