Project

General

Profile

Bug #1542

Group Docs Locked

Added by Matt Gold over 9 years ago. Updated over 7 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
BuddyPress Docs
Target version:
Start date:
2012-01-13
Due date:
% Done:

0%

Estimated time:
15.00 h

Description

I'm noticing that multiple docs (I'd guess all) in the JITP group (http://commons.gc.cuny.edu/groups/journal-of-interactive-technology-and-pedagogy/) are locked, purportedly because they are being edited by Luke. I'm guessing that this is a bug, though it's possible that Luke is editing multiple docs at once. I unlocked the first doc, but this seems like it could be a larger bug. Hence the ticket.


Related issues

Related to CUNY Academic Commons - Bug #2276: Commons Document Remains Locked Even Though Untouched for Day+Resolved2012-11-19

History

#1 Updated by Boone Gorges over 9 years ago

  • Status changed from Assigned to Reporter Feedback

I was only able to find three that were locked. It's probably because Luke opened them to edit, and then closed the browser window without hitting Save. See also https://github.com/boonebgorges/buddypress-docs/issues/44

#2 Updated by Matt Gold over 9 years ago

  • Status changed from Reporter Feedback to Rejected

Okay -- thanks

#3 Updated by Matt Gold over 9 years ago

Just found another example, where I'm told that a doc is being edited by you. Please see attached screenshot.

Question: is there any way of querying the database to see which/how many docs are currently locked?

#4 Updated by Matt Gold over 9 years ago

Seeing this in another group (CAC Planning) -- the email doc appears to be locked and I don't think it should be. Please see attached screenshot.

#5 Updated by Boone Gorges over 9 years ago

  • Status changed from Assigned to Reporter Feedback

I've added Scott as a watcher. Scott, is there any chance that you clicked on the Edit mode of the Doc in question, and then left without saving (either by clicking the Back button or by closing the window)? If so, then this can be chalked up to a limitation in the way that the lock is implemented, and I'm going to move this ticket to 1.4 for a fix, as it will be substantial. If not, then it means that the lock mechanism is not even working as advertised.

#6 Updated by Boone Gorges over 9 years ago

  • Target version changed from 1.3.11 to 1.3.12

#7 Updated by Matt Gold over 9 years ago

Just received another report of this -- in this group, the "Journals of Interest" doc is locked (another member tells me there is an alert saying that I'm editing it). I did edit the document a few days ago, but I always save before closing the browser window. http://commons.gc.cuny.edu/groups/journal-of-interactive-technology-and-pedagogy/docs/journals-of-interest

Before forcing the document open, I wanted to report the problem. Please, though, tell me when it's okay to release the lock since we do actually want to edit the doc. Thanks.

#8 Updated by Boone Gorges over 9 years ago

Feel free to unlock the document. There's not much information I can gather, other than that it's marked as locked by you.

You'll have to let me know how you want to progress with this issue. The problem probably will not be fixed until I find the time to totally rewrite the Doc lock mechanism. I had been planning on doing this for the 1.4 release, but this release is not imminent. I can rearrange my schedule to make the lock rewrite a top priority. Or I can disable the edit-lock feature until it's been fixed. Or I can do nothing, and we handle these issues on a case-by-case basis.

My recommendation is to wait, as this does not seem to be a pervasive issue.

#9 Updated by Boone Gorges over 9 years ago

  • Target version changed from 1.3.12 to 1.3.13

#10 Updated by Matt Gold over 9 years ago

My recommendation is to wait, as this does not seem to be a pervasive issue.

Sounds fine to me. Thanks, Boone.

#11 Updated by Boone Gorges over 9 years ago

  • Status changed from Reporter Feedback to Assigned
  • Target version changed from 1.3.13 to 1.4
  • Estimated time set to 3.00 h

Thanks, Matt.

#12 Updated by Boone Gorges about 9 years ago

  • Target version changed from 1.4 to Future release

This is not going to be done by the 1.4 release. Let's reassess after 1.4.

#14 Updated by Boone Gorges about 9 years ago

Did you unlock it manually? It wasn't locked when I visited it.

#15 Updated by Matt Gold about 9 years ago

Yes, I unlocked manually because that's what you seemed to advise above in comment #8. The screenshot shows what I found before unlocking, though.

#16 Updated by Matt Gold almost 9 years ago

Noting for the record that this continues to occur - http://redmine.gc.cuny.edu/issues/2276

#17 Updated by Matt Gold almost 9 years ago

I think we should try to put this on our development roadmap, as it's a bug that continues to affect the user experience. Boone, can you think about when we might be able to fit it in? Many thanks.

#18 Updated by Matt Gold over 7 years ago

  • Target version changed from Future release to 1.6

#19 Updated by Matt Gold over 7 years ago

Hoping we can return to this for the 1.6 milestone.

#20 Updated by Boone Gorges over 7 years ago

  • Category name changed from BuddyPress (misc) to BuddyPress Docs
  • Estimated time changed from 3.00 h to 15.00 h

I'm willing to take a look, but it's going to be a fair amount of work. WP has recently introduced a couple new features that I'd probably leverage (post locking and the heartbeat API) but it will take a good deal of research to reverse engineer those tools. I'll write it first as a feature for mainline BuddyPress Docs, and then port it back to the version that we use on the Commons.

#21 Updated by Matt Gold over 7 years ago

Thanks, Boone, and sorry that this is a thorny one. If there is anything I can do to help (like hiring someone with particular knowledge of the features you're looking at), please let me know. I do think that this is worth fixing.

#22 Updated by Boone Gorges over 7 years ago

  • Status changed from Assigned to Testing Required

I made some improvements for the latest version of BuddyPress Docs, and have backported them to the Commons in https://github.com/castiron/cac/commit/0363b58f223dde334b7ce70dd3f9064a75fae681

Basic edit lock functionality remains the same: only one user can edit a Doc at a time, and admins have the option of removing an edit lock manually. Otherwise, edit locks are cleared when the Doc is saved, or the user clicks out of edit mode. There is still a 30 minute "idle" window, after which you are automatically removed from Edit mode.

The main change is that a "heartbeat" detector has been introduced. While editing a Doc, your browser communicates every 15 seconds with the server. If WordPress stops receiving these pings - more specifically, if more than 4 pings are missed (one minute) - we assume that the browser window was closed or the connection was lost in some other way, and the edit lock is removed.

The combination of the existing functionality with this new heartbeat ought to catch the vast majority of cases where edit locks are being applied incorrectly.

Ready to test on cdev.gc.cuny.edu.

#23 Updated by Matt Gold over 7 years ago

  • Status changed from Testing Required to Assigned

Boone, we just tested this and I am thrilled to say that it worked!!! Please add to the codebase for 1.6

Here's how we tested:

Micki logged in on one computer through the teststudent account, created a doc, and closed browser window while editing

I logged in to cdev and looked at the doc. it showed micki editing it, but then, after 15-20 seconds, the locked cleared.

So this is great. 2 years in the making! So glad to have this fixed. Huge thanks, Boone!!!

#24 Updated by Boone Gorges over 7 years ago

  • Status changed from Assigned to Resolved

Also available in: Atom PDF