[Framework-Team] PLIP #240: Improve locking configurability

[Danny Bloemendaal]

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