On 6 okt 2008, at 03:22, Raphael Ritz wrote:
David Glick wrote:
I'd like to propose PLIP #240 for inclusion in Plone 3.3:
http://plone.org/products/plone/roadmap/240
This PLIP is intended to provide several avenues toward
addressing the problem of content accidentally getting left in a
locked state.
+1 for this, although:
David Glick is willing to serve in an advisory role to whoever is
willing to implement this.
I suspect this means that it won't get implemented. :)
I think you need to find someone who's willing to commit to
delivering it, or it won't happen.
I suppose I should clarify. I'm willing to commit to implementing
this if it's just a matter of changing the default timeout and
adding some KSS to keep the lock in place while an item's being
edited. In an effort to avoid overextending myself, I'm not able
to commit to creating a new locking configlet (though based on
Sidnei's comment about the PloneLockManager product, which I was
unaware of, that may be less important).
I don't recall why it never made it into the release
but when Jeff and I started the locking integration
at the Archipelago sprint a few years ago we did
consider it and created
https://svn.plone.org/svn/collective/LockManager/branches/plip_145_TTWLocking/
There shouldn't be much missing I hope.
Just so this won't get forgotten ...
Raphael
Then this really should be added asap. I too see locks showing up
everywhere. There must be a sane timeout indeed and I also recalled
during that sprint that it was taken into account. Wasn't the
beforeunload event in the browser used to unlock it?
+2
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
