content lock not attaching
| Project: | Checkout (Content locking) |
| Version: | 5.x-2.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
I've got 'checkout' installed on one Drupal site and it works perfectly, but fails on another site.
1) Logged in as 'user1', and opened a document for editing. Got the "This document is now locked against simultaneous editing" message as expected.
2) Then logged in as 'user2' (using a different browser), and when I tried to edit the same content I got the "This document is locked for editing by user2 since ...." message.
Exactly as it should be, but the same scenario doesn't work on another install I have.
Both users get the "This document is now locked against simultaneous editing" message, and whichever one is last hitting the submit button gets the "This content has been modified by another user, changes cannot be saved." error message.
I have the most recent version of 'checkout' installed on both sites. Ironically the site that works is an older version of Drupal (but both are in the 5.x release range).
Is there any known incompatibility between 'checkout' and other modules? Or any specific role assignments that might interfere with functionality?
Thanks.
#1
Subscribing to this one. Content locking isn't working for us, either. I've tried it on two installations, and while i get the same status update messages, another user can go right in and edit the same node. Access control permissions are correct (all user types that can edit content can administer/checkout/keep documents checked out).
The work around that we've implemented (ugly as it is), is for users to edit, then check the "Keep document locked" box, save. From that point, the node is locked against simultaneous edits until the original user goes back in, makes the real edits, and saves.
It's a hassle, to be sure.
Drupal 5.12/Checkout 5x-2.0 (although the problem has persisted in every version of Drupal 5x).
#2
I'm having the same problem. It appears to be related to the ajax used by autocomplete fields triggering a lock release when the page loads.
#3
Yup. The problem is that checkout_handle_request() can't tell the difference between you navigating to another page and an AJAX request for an autocomplete field making a request to another page.
I've created a workaround by moving the call to checkout_handle_request() from hook_menu, which gets called on every request, to hook_footer, which only gets called on requests that return a page (i.e. not AJAX requests returning JSON or similiar). I haven't tested extensively for any other side effects for this change, but it looks good!
#4
Sadly, didn't resolve my issue with content not locking. Next step for me is to selectively disable other modules on a dev site to try and find a conflict.
#5
Sorry to hear that, paulb0t.
You say it works if you use the "keep document locked" checkbox, so my gut says there must be something unlocking the page right after it locks. Are you using any AJAX at all on the form pages? Have you tried watching to page load in something like Firebug to see what other calls are being made?
Here's an idea -- does locking work if you disable javascript? If so, it *has* to be some type of AJAX request on the form.
If that doesn't solve it, I'd add a poor man's breakpoint (
debug_print_backtrace(); exit();) inside function checkout_release() in checkout.module. Then you can see what the heck is calling that function.#6
Thanks for the suggestions - still completely stuck here, though the function does work with JS disabled. I'll try running it through firebug, though first attempts didn't shed too much light on the issue.
Slight update - looks like autocomplete might be the conflict - though I've long since disabled the module, it's still sticking it's head in.
#7
The patch worked for me. I had to insert it by hand since the patch is not for the latest version, but it worked... Almost. Now user2 gets told the document is locked, and does not get immediate access to edit the node. But user1 does not get any message. Not even the green status-message saying "This document is now locked against simultaneous editing.....". Is that the way it is supposed to be?
#8
Ups, the status-message saying "This document is now locked..." now gets shown when I (/user1) navigates elsewhere. So user1 gets the message leaving the edit-form not in it. Is it a weight problem or something?
#9
This has already been fixed in CVS by checking for the HTTP_X_REQUESTED_WITH header line that gets automatically set by jQuery when doing AJAX requests. Please update to the latest development snapshot.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.