As the title suggests, allowing users to "checkout" content for editing.

If you have a large site and a lot of users, it makes sense to prevent users from editing files when others are working on them.

The current system can become frustrating to non-drupalers. Most users expect the web applications they use to do this. An actual example is Joomla!.

I would add the workflow:

1. User clicks 'edit' tab, system verifies it is not locked.
2. If NID is locked, print message explaining the lock, else show edit tab.
3. Administrator can set a "max edit time" directive to unlock "forgotten" locks after x amount of time.

Comments

bsherwood’s picture

bsherwood commented

*bump*

Any comments, either way on this? Does this seem like a more intuitive way to handle editing content?

lilou’s picture

lilou commented

See : http://drupal.org/project/checkout

keith.smith’s picture

keith.smith commented
Title: Intergrate Checkout (content locking) into D7 » Integrate Checkout (content locking) into D7
bsherwood’s picture

bsherwood commented

I realize the existence of this module. Also note how I titled the issue. I am talking about integrating Checkout into core.

I am coming from the position that this should be the default method of handling users editing nodes in D7 (or D8).

With sites with a lot of users editing content, it seems like the most intuitive way to prevent users getting errors. The node system would "lock" the content until the user hits the submit button or a set amount of time has been reached. it's more about usability than anything else. The point being to help prevent users from seeing error messages.

What if a user spent 20 minutes editing a node only to find out someone beat them to the punch, this most certainly would upset the user, potentially not editing another node due to this frustration. This is a loss to that site's community. Contributing users might become frustrated enough to not contribute to the community after a few attempts.

I realize I could just use the contrib, but I do believe this functionality is "core" worthy. Maybe the code in Checkout isn't "core" worthy, but the concept to me is.

bsherwood’s picture

bsherwood commented
Status: Active » Postponed (maintainer needs more info)

*bump*

Any direction yay or nay on this?

I realize that this is not a major priority with the core developers, but I do believe this should be how nodes are handled when users can edit them.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Postponed (maintainer needs more info) » Active

I'd prefer to get #120967: Separate revisions from node.module and #120955: Integrate Diff into Core in first, but I like the idea.

bsherwood’s picture

bsherwood commented

Dave,

All I have to say is, wow! I have read through most of your ideas and I love most of them. You really have a knack for adding those little things I think Drupal needs.

I realize you have set your priorities with the two previous issues (which would be great additions to core), but are you considering helping to code this issue?

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented

Oh, definitely that'd be a great improvement!
However, implementing this is going to be quite some work, and I'm in serious doubt we can get it properly done until D7 code freeze.
Some of the more problematic aspects include: Handling forgotten locks, locking the node for actions and queueing the actions, allowing admins to unlock an edit by someone else plus afterwards handling the concurrency.
We can't just start implementing this - rather we need an elaborate spec first. I'm postponing this for now, but it would be awesome to get this in early in D8.

I'd also invite you to help us with the two issues Dave mentioned. That's doable until D7 code freeze and an improved revision management, that would be next, is doable as well.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Active » Postponed

I agree this should be postponed, so thanks for updating the status Pancho. There are way too many 'big' node patches to get through first. Hopefully there will still be time left before the freeze that we might attempt this. :)

jstoller’s picture

jstoller
he/him
commented

+1

Speaking as someone who works at a large organization, content checkout is a very important feature.

MiMe’s picture

MiMe commented

I agree, content checkout is almost too important to postpone

bsherwood’s picture

bsherwood commented
Issue tags: +Usability

Tagged under "Usability" since I think this method would be better for end users.

mdupont’s picture

mdupont
Primary language French
Location Switzerland
commented
Title: Integrate Checkout (content locking) into D7 » Integrate Checkout (content locking) into D8
Version: 7.x-dev » 8.x-dev

Bumping to D8.

jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented
Status: Postponed » Active

As per #8.

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented
Version: 8.x-dev » 9.x-dev

Too late for Drupal 8 at this point, we are past feature freeze. Drupal 9 material.

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented
Title: Integrate Checkout (content locking) into D8 » Integrate Checkout (Content locking) into Core

Bumped to D9, so the title needs to be adapted.
This should probably be based on or inspired by content_lock module now.

catch’s picture

catch
he/him
Primary language English
commented
Version: 9.x-dev » 8.1.x-dev
Issue summary: View changes
Status: Active » Postponed

As a feature this could potentially be added in a minor release.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

acbramley’s picture

acbramley commented
Status: Postponed » Postponed (maintainer needs more info)

Is this something that needs to be brought into core? The content lock module provides this functionality.

acbramley’s picture

acbramley commented
Status: Postponed (maintainer needs more info) » Closed (outdated)

It's been 3 months since #33 and 10 years since the last comment before so I'm closing this for now.