You are here: Foswiki>Tasks Web>Item3222 (04 Jan 2015, GeorgeClark)Edit Attach

Our developers complain a lot about the new merge in some of our applications. There many topics are automatically written, but now often fail due to that somebody had edited the topic, but has no way to unlock the topic. There is a lease hanging around still.

We'd like to have the checkbox back that would allow the user to say to give up the lease.

Marked as bug as cairo had the checkbox....
The worth of the extra checkbox really depends on the situation. I prefer to have less options for most situations.

I suggest you put a DEF in the edit template to make it easy to switch on, but have it invisible for normal use.


The unlock checkbox is not something I would recommend putting back because as TWiki actually works now it makes little sense. Actually it would do absolutely nothing.

In Cairo the unlock checkbox was only doing something when you save.

And in TWiki4 the lease that is hanging today is released when you save. It is hanging when people click edit and then hit back in the browser instead of clicking the cancel button. In fact the cancel button is the unlock button.

If people have not used Cairo they will not know about any unlock. I think the demand comes from people used to Cairo and that do not know that hitting cancel means the same. I hit "back" all the time also.

Thomas you should try and follow these small scenarios.

  • View a test topic. Check that there is no lease file.
  • Edit the topic. Check that the lease file is there now
  • Save the topic. The lease file is deleted again. No need for any unlock.

  • Edit the topic again. Note the lease file is back
  • Use the back button to get away from edit mode. Note that the lease file stays behind. This is the problem your users see Thomas when guy that clicked edit does not save or cancel.

  • Edit the topic again. Lease file is still there.
  • Save the topic the lease file is deleted.

  • Edit the topic. Lease file is created.
  • Use the back button to back out without saving or cancelling. Again we have the lease file left behind.
  • Edit the topic again. Lease file is still there.
  • Click cancel. Lease file is removed.

So there is no need for any unlock checkbox. It could not possibly do anything. Your users simply have to either cancel or save. And of they forgot they release the lock by editing again and canceling.

Arthur is there a way to Javascript a cancel action if you back out from editing in the browser?

KJL thanks for your thorough analysis and your pinpointing the source of the real problem. I have come to that conclusion also, but you beat me to it. Sorry for causing this extra work for you.

However, you came up with a great enhancement suggestion that would really help, as users often back out of topics and leave the locked topics behind.

I have changed the topic name and made it enhancement.... -- TW
That would be easy. In pub/TWiki/TWikiJavascripts/twiki_edit.js we add:
window.onunload = function () {
   alert("test unload");
       // unlock action here

While we are at it, an addUnload event handler would be useful for twikiEvent.js

This onload function would be called whatever link or button is clicked to close the page. So perhaps a check would be necessary when the Preview button is clicked.


Seems like a good idea, but using the "back" key in the browser has an advantage especially with very large topics that take a long time to render. Issuing the unlock might involve considerable overhead. Also, if the backspace was inadvertent, will the browser forward-action re-acquire the lock? Setting this to Proposal Required.

-- Main.GeorgeClark - 04 Jan 2015 - 22:00

ItemTemplate edit

Summary Can we invoke the "cancel" action when users back out of editing a topic?
ReportedBy TWiki:Main.ThomasWeigert
SVN Range TWiki-4.1, Tue, 28 Nov 2006, build 12081
AppliesTo Engine
Component FoswikiUIEdit, NatEditPlugin
Priority Enhancement
CurrentState Proposal Required
TargetRelease n/a
ReleasedIn n/a
Topic revision: r9 - 04 Jan 2015, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy