checkout_checkout shouldn't be called during prepare

Outstanding post, thanks for pointing out these issues!

Since there were some interesting questions in your comments, and because some issues turned out to have even more bugs, I've taken some time to largely fix these and refactor several parts of the code. The changes in detail:

• The biggest change was moving the node locking and releasing from hook_nodeapi() and hook_exit(), respectively, to a new central location (checkout_process()), which will be invoked during hook_menu() processing. This will allow users to specify additional paths that should keep a node locked, while the former approach only worked with the regular node edit form (despite the presence of some detection mechanism). For example, the default paths have already been enhanced by revisions and revisions/* pages, so a node will now be locked when administering revisions. Note there still is no admin page that lets you modify these paths.
• As you already pointed out, the use of request_uri() and referer_uri() functions were the cause for several bugs. request_uri() has almost everywhere been replaced by $_GET['q'], whereas the usage of referer_uri() needed a lot more processing to work properly with clean urls enabled/disabled and (especially) url aliases.
• Display the error message even for the same user and also the initial message when a document has been locked for the first time were both reasonable changes.
• All issues about nodes being checked out multiple times *should* have been solved.
• Additionally, checkout_checkout()'s obscure return value has been replaced by some cleaner logic. Several functions now have more descriptive names (hopefully).

Re comment #2: The key point is that the user already has been warned before the administrative check-in in big red letters, that when forcing a check-in any other editing session will be nuked. (That's also the reason why this is backed by an access permission, because only admins should have the power to forcefully release locks, not regular editing users). IMO there isn't anything left to do here.

I think both patches should get their own issue. smk-ka's patch from comment #4 patched perfectly against 5.x-1.0 and actually made the module work. It wasn't working for me at all in even the most simple of cases and now all works as advertised. It's RTBC.

ptalindstrom, perhaps you could re-roll your patch against that version?

Thanks for the patch smk-ka it applied cleanly and installed fine.

However, when I edit a node (as admin) save it and then edit it as a user without "check out documents" permission I get a string of errors when attempting to edit;

user warning: Table 'cache_views' was not locked with LOCK TABLES query: SELECT data, created, headers, expire FROM cache_views WHERE cid = 'views_urls' in /var/www/drupal/includes/database.mysql.inc on line 172.
user warning: Table 'view_view' was not locked with LOCK TABLES query: SELECT name, url FROM view_view WHERE page = 1 AND LENGTH(url) > 0 in /var/www/drupal/includes/database.mysql.inc on line 172.
user warning: Table 'cache_views' was not locked with LOCK TABLES query: SELECT data, created, headers, expire FROM cache_views WHERE cid = 'views_default_views:en' in /var/www/drupal/includes/database.mysql.inc on line 172.
user warning: Table 'cache_views' was not locked with LOCK TABLES query: SELECT data, created, headers, expire FROM cache_views WHERE cid = 'views_tables:en' in /var/www/drupal/includes/database.mysql.inc on line 172.
user warning: Table 'v' was not locked with LOCK TABLES query: SELECT v.*, n.type FROM vocabulary v LEFT JOIN vocabulary_node_types n ON v.vid = n.vid ORDER BY v.weight, v.name in /var/www/drupal/includes/database.mysql.inc on line 172.
user warning: Table 'role' was not locked with LOCK TABLES query: SELECT * FROM role ORDER BY name in /var/www/drupal/includes/database.mysql.inc on line 172.

However, if the scenario is reproduced but the second user attempting to edit has the "check out documents" permission everything works as expected, and no errors/warnings are generated.

Should all users that can or may potentially edit any document be assigned the 'check out documents' privilege? If so, isn't that an unnecessary setting since all necessary information can be gleaned strictly by whether or not the user can edit a node? Or am I missing something here?

@jgraham
Could you please try the 2.x branch (available on the releases page)? This should have this bug (and others) fixed.

I'm still not sure how we should proceed with the 1.x branch (ie, this issue) and if it's worth fixing it. The reason why I've started a new branch was because my patch (#4) introduced several API changes, which I took as a starting point to completely overhaul the module. Backporting from there seems like a non-trivial task to me.

I am using pageroute. When I hit the back button in my browser, I get the error

"This content has been modified by another user, changes cannot be saved" and I cannot do anything.

I am on the same machine and browser.

Do I need to install the checkout module in order to get around this?

Chris

@activelyOUT
No, this seems to be a problem with pageroute itself, which this module can't resolve.

D5-2.0 has finally been released, closing this issue.