[Framework-Team] PLIP #240: Improve locking configurability
danny.bloemendaal at informaat.nl
Fri Oct 10 04:23:39 UTC 2008
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:
>>>> 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
> There shouldn't be much missing I hope.
> Just so this won't get forgotten ...
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?
More information about the Framework-Team