Problem: Unauthorized Locking of Nodes that cannot be edited

Nice catch! I've just fixed on place: node_access() requires a node object, not a nid. Otherwise this looks good to me.

Found a better solution using menu_get_item(): the hardwired node_access('update', ...) only checks for node edit permissions, which might be sufficient for node/%/edit, but not any other path that can be locked. For example, on node/%/outline we need to check for book.module's "administer outline" permission. This can be done by directly querying the menu system and letting it figure out the access permissions.

Subscribing.

Has anyone tested if there are problems with
· Taxonomy Access Control
· Domain Access
· Domain Access pach: multiple_node_access patch (allows you to use AND logic instead of OR logic: ALL of the access' modules must allow you to view/edit the node, not only one)

I try to reproduce the scenary and test it.

I didn't check the patches yet, but I just found out that at least some of the "unauthorized" locking was caused by users opening the revisions tab of a content.

Whoa. That is an unexpected behavior. The message "...is locked" appears, but I wonder why the lock happens at all, because revisions should only be displayed at that point.

+1. We are also getting hit with the inadvertent locking of content when navigating to the revisions tab.

We've confirmed that the patch from #4 does not work with 'Taxonomy Access Control Lite', 'Module Grants' and 'Workflow Access'. The patch from #3 does work though.

We are still interested in a fix for inadvertent locking when navigating to the 'revisions' tab.

Got time to look through the code, the following line allows people to override the locking behavior using a variable:
$patterns = variable_get('checkout_edit_paths', "edit\nrevisions\nrevisions/*\noutline\nclassify");

We added only 'edit' to the settings.php file and it seems to work fine for us. Still believe the default setting shouldn't lock when navigating to the revisions tab.

In settings.php? Why did you do anything in that one? *confused*

I tried using the line
$patterns = variable_get('checkout_edit_paths', "edit");

but then nothing gets locked properly, despite the message being shown. Help would still be appreciated.

@itsnotme. The 'variable_get' function will use the provided variable's value ('checkout_edit_paths' in this instance) or the provided default value. As opposed to changing the source code, we choose to set the variable's value in settings.php.

$conf = array(
#   'site_name' => 'My Drupal site',
#   'theme_default' => 'minnelli',
#   'anonymous' => 'Visitor',
   'checkout_edit_paths' => 'edit',
);

Looks like it appropriately locks the node (on edit only) to me.

You might want check http://drupal.org/project/content_lock . Its a fork(and partially rewrite) of checkout and activly maintained. It does not seem that checkout is maintained anymore (not officially confirmed though)