All too often I want to edit a page and find that it is locked by the previous editor. The current unchecked box "Release edit lock" is too easily overlooked.

So please set this variable in your personal page (as long as it is not set in the global web variables):

Set RELEASEEDITLOCKCHECKBOX = checked="checked"

-- ArthurClemens - 06 Jun 2003

Or better, get rid of this variable, and make release lock the default. What users want is a direct "checkpoint" button, not a separate variable...

-- ColasNahaboo - 06 Jun 2003

I've added this to UsabilityIdeas.

-- ArthurClemens - 06 Jun 2003

This facility is already available in TWikiAlphaRelease, see UsingFormsForSettings.

-- JohnTalintyre - 06 Jun 2003

The reason for the unchecked default state is to prevent simultaneous update problems. This does happen if the checkbox is checked because many folks use the browser back button to make more changes. Doing so leaves the topic unlocked, e.g. another user can edit the topic at the same time.

Now if a user is aware of this problem, he/she can uncheck the flag in the user preferences.

-- PeterThoeny - 07 Jun 2003

Mmm... I didnt think this happenned at my site, but anyways, this is not a solution, as the problem still exists if somebody does "back" after one hour. I guess the real solution to this problem would be to perform a check when saving, and if we see that the topic was modified since our edit (by embedding the contents of the lock file we created as metadata in the edit & preview buffer and comparing to the one existing - or not - on save? ). Then if we see that somebody has saved in the meantime we could present a warning page offering the choice to:

1. default: clobber previous editions (with the option to mail the previous author(s)?)
2. cancel save, open a new window and re-edit, applying his changes by hand.
3. perform a RCS merge and suggest to the user to edit the topic to remove conflicts
4. for power users, download the 3 versions so that he can apply his merge tools locally (it could be nice to have a tool like tkdiff native in twiki, but it would be quite complex to code I think)

Recommended action would be the first one, so that:

• if first user to save was more technical than the second, the responsability of the merge will be on the first users, and he will be mailed to this effect
• if the second is more technical, then he can choose the appropriate option: 2, 3, or 4.

Thus if I want to edit a topic and it is locked by a naive user (an assistant), I can break the lock and save my topic without waiting, since I know that when he/she will save, the default action will not put any more burden on her, and I will be mailed to "finish the job".

-- ColasNahaboo - 07 Jun 2003

Excellent!

-- RandyKramer - 07 Jun 2003

Detecting competing locks/saves surely helps to increase user confidence, although I rareley saw that in practice. Here a few more observations with the proposed immediate unlocking:

1. On the internet (at least twiki.org) there are mostly fast, threaded discussions going on. a lock by someone from the other side of the globe is intimidating; you can't pick up the phone, don't write an email. You might chat to Melbourne, though
2. On the intranet (IMH experience) you work mostly in document mode. If you run into a lock, you yell over the desk, pick up the phone or edit anyway. No problem. Actually a good way to synchronise.
3. With savemulti, people don't use preview any more. you save, spot a problem, go back, save again, boom: one more revision preserving your embarrassing mistake forever.

My recommendation: keep locking by default, make the lock expire fast (10 min?) on the internet, make it slow on the intranet (we use 10 hours!). That said, detecting saves from 'edit anyway' would of primary interest for internet sites.

-- PeterKlausner - 09 Jun 2003

The combination of Colas' approach and Peter's different timeouts for Internet vs. intranet sounds fine.

Does savemulti create a new revision each time the same person saves? I thought it did not. Or does it vary depending on whether it occurs before or after the one hour timeout? _There have been times when I wanted to force a revision — I wanted a permanent record of the current status before I started modifying the page, even though I may just have made some modifications. IIRC, I had to wait the one hour in order to force a revision. I.e., checking the "release edit lock" box doesn't force a revision.

Being able to force a revision at any time would be a nice feature, but it does not necessarily have to be tied to the release edit lock feature:

• If you check a new "force a revision" checkbox, the next edit, even by the same author, creates a revision. (Or maybe it should be for the current edit — if I want to force a revision, I indicate it when I submit the first changes for that revision?)
• If you don't check the new "force a revision" checkbox, behavior is as today, which, IIUC, if the same author makes additional changes within one hour of his last change, a new revision is not created.

---

RandyKramer - 12 Jun 2003

Actually, this problem happened a lot at my company this February: We (200 of us) had to register for transportation options for an internal offsite meeting, so we were all requested by an assistant to edit a single wiki page in a short time frame, including people who were really not comfortable with wiki. I heard lots of horror stories of people loosing their edits (meaning they were not registred to be picked at the airport by the bus, etc...), this can be very detrimental to TWiki success. And this was with the KoalaSkin and its savemulti screen, it seem lot of people forgot to save immediately (were interrputed) and saved some time afterwards, unknowingly clobbering other user edits.

On the intranet, your users are not TWiki-aware. A lot of them do not want to take the time to understand how the tool work, nobody will bother phoning a coworker about a TWiki lock: it is not their problem, they do not want to be bothered by details. ... And they are right: tools must be simple and predictable. So I'd say the locking system must be foolproof for the intranet.

And even with savemulti, if you save, then go back in your browser and save, you will clobber changes (the data in the edit buffer will be the one of the old editions), so there is still need to compare a "version ID" included with the edit data with the current state of the file on the disk before saving.

I agree this is a minor bug, but as TWiki becomes more and more used, these kind of "surprises" become worth fixing.

PS: forcing a revision is another issue, which can be an useful one. Savemulti just use the standard TWiki save code, so it obeys the "if last rev was by same author in less than one hour, do not increment revision".

-- ColasNahaboo - 12 Jun 2003

Frequent updates by multiple people of single page is bettere addresses by Plugins.CommentPlugin, IMHO. And it also makes adding text easier (including signature) - no need to see edit page with all the formatting. It also releases page lock immediately. For people not willing/ready to learn Twiki markup, Comment is the way to go, IMHO. That is why I was so big proponent to add it to standard plugins installed by default.

-- PeterMasiar - 13 Jun 2003

mmm...

• In my case it was a big table edited via the EditTablePlugin, really a DocumentMode topic, not a ThreadMode one, so the comment plugin would not have worked.
• Last time I checked, the CommentPlugin was even more problematic, as it did not lock at all the topic...

-- ColasNahaboo - 13 Jun 2003

I know Plugins.CommentPlugin is broken - it is for a long time, and I reported it . My point is, is you need to update some page often, non-locking COMMENTS which does not require edit lock and understand Twiki markup is better, especially for newbies.

-- PeterMasiar - 14 Jun 2003

Yes. Actually the EditTablePlugin is also very popular because of this (no need to understand TWiki markup), and it allows modifying a previous entry, very useful for table of reservations. And it was an incentive for assitant to use TWiki, as they ended up with a ready-to-use, summarized document, whereas with a Threadmode document like done with the Comment Plugin, they would have to process by hand all the 200+ entries, bringing not much more confort than handling this task by email.

Moreover, a nice side effect of TWiki tables is that they cut-and-paste nicely with excel. Assistants are able to give TWiki tables to the accountants, who use only MS office, as they just cut n paste TWiki contents into automagically Excel tables deduced from the HTML tables...

And adding a comment may not require a lock... except it prevents refactoring the page (or just editing the text to detail things on top) as you run the risk of a race condition then...

TWiki is really great because it does a bit of everything just good enough so that you do not have to resort to specialized tools (word processors, spreadsheets, database apps). But the more you use it, the more it must be reliable as the more you depend on it. I guess what I am wanting to say is that TWiki needs a bit of a stabilization phase: the features are there, we need to put effort in fixing the more obscure bugs (and making it look attractive

-- ColasNahaboo - 14 Jun 2003

Is this a bug? I cannot set RELEASEEDITLOCKCHECKBOX globally in TWiki/TWikiPreferences (if I do nothing changes), but I can in each Web's WebPreferences and Main/UserTopic.

-- ArthurClemens - 10 Sep 2003

Regarding two previous comments:

The reason for the unchecked default state is to prevent simultaneous update problems. This does happen if the checkbox is checked because many folks use the browser back button to make more changes. Doing so leaves the topic unlocked, e.g. another user can edit the topic at the same time.

Now if a user is aware of this problem, he/she can uncheck the flag in the user preferences. -- PeterThoeny - 07 Jun 2003

and

And even with savemulti, if you save, then go back in your browser and save, you will clobber changes (the data in the edit buffer will be the one of the old editions), so there is still need to compare a "version ID" included with the edit data with the current state of the file on the disk before saving. -- ColasNahaboo - 12 Jun 2003

If edit opens up in a _blank target, users will never be able to go back. Further, if save or cancel also closes the window, this new window won't clutter the desktop. Even further, if view also had refresh (10 sec, for example), users would always see up-to-date pages. (Though meta-refresh is obsolescent.)

-- JonathanCline - 11 Sep 2003

There is quite a lot of discussion of the locking issues under BetterFileLocking (there is also ReleaseEditLockByDefault, but I think that everything there has been covered here already).

One thing suggested in BetterFileLocking quite a long time ago was having a short timeout (e.g. 10 min) after save while keeping the long (default 60 min) timeout after starting an edit. This leaves a short opportunity to fix a minor problem by going back in the browser history or forwards to another edit before anyone else can get in, but does not open up too big an opportunity for conflicts. I recently hacked the code of my installation to implement this - the grubby details are in BetterFileLocking.

-- OwenRees - 12 Sep 2003

How about if the user has it released, and tries to save when someone else has it locked, their changes are queued for appending later? How does this interact with the merge ideas (IDRTTN) banded about a few weeks ago? This would raise the requirement for a queue of unwritten appends for each topic - like those I suggested on AppendTextToTopic

-- MartinCleaver - 28 Sep 2004

I believe what you are asking for is discussed in ReleaseLocksOnSave.

-- PeterThoeny - 29 Sep 2004