On Jan 16, 2009, at 3:04 PM, Andrew Burkhalter wrote:
Other
-----
There is a weird edge case in the following scenario:
1. Manager turns off locking.
2. User A starts editing a document
3. Manager turns locking back on
4. User A clicks the edit tab again
5. User B views the document
The document should show as locked to User B, but it doesn't. We
didn't have time to
track this down or compare to current Plone behavior, but will do so
before merging
this PLIP.
However, it should be noted that if the user in step 4 above hits
view and then
the edit tab (rather than just hitting edit an additional time) the
locking viewlet behaves
as expected (e.g. the item is listed as locked) for user B in step 5.
All initial analysis
of our added code from the debugger behaved as expected, so more
investigation is
needed on our part to determine if this was introduced by us.
Hey, just wanted to note that Andrew and I investigated this,
discovered it was due to a previously existing bug in the
unlockOnFormUnload.js script, and implemented a fix in the branch for
PLIP #240. In the process we also discovered a related bug which
results in items getting unlocked following a validation error even
though someone is still editing. We'll port the fix for that issue to
the 3.2 branch and trunk regardless of the decision on PLIP 240 as a
whole.
peace,
David Glick
Web Developer
ONE/Northwest
New tools and strategies for engaging people in protecting the
environment
http://www.onenw.org
davidgl...@onenw.org
work: (206) 286-1235 x32
mobile: (206) 679-3833
Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
