Edit lock for wiki pages and/or page elements

1 Requirements

1.1 Detailed Proposal for automatic lock (Alex, 17 May 2013)

2 Status

3 Additional Information

4 Discussion

Marko Glaubitz, 27.03.2013
We definitely support this feature request and would like to participate in funding this feature.  Since we run a dokuwiki farm, we know that more users than one might think work at roun same time. Thus, locking pages while they are being edited prevents so much frustration and anger among users. Contact: marko.glaubitz@rz.uni-freiburg.de

Alex, 17 May 2013: How would the second suggestion be different from the existing block/set-read-only feature in wiki pages? This already blocks editing of "normal" users.

Matthias Kunkel, 17 May 2013: I highly appreciate this feature! But I would add one tiny little feature to it: When another user already edits this wiki page and I do not get access to it, ILIAS should not only display a message that editing this page is not possible but also who is currently editing (and locking) it. Especially in collaborative groups and in teams this would be a very helpful feature. Showing this name should not be a privacy issue as the name of the user is shown in the history anyway once the page has been changed.

JF 27 May 2013: We appreciate the (first) feature and schedule it for 4.4. As Matthias wrote the info message should name the user that currenty locks the user.

Marko Glaubitz, 27.05.2013: I'd suggest one small change to the detailed proposal, if that is still possible: after the lock has expired, the changes should only be lost, if someone has edited the page in the meantime. Once the lock expires, ILIAS could jump back to the editor page with the last version (still unsaved) of the page, disable the "save and return"/"save" buttons and display the previously edited block (opened), so that the user can still copy the unsaved content to the clipboard and reload the page.

Marko Glaubitz, 21.11.2013: The Edit lock is still not being released automatically after hitting save. Did you mark my last comment?

Alex Killing 22 Nov 2013: The concept above "Detailed Proposal for automatic lock" never stated that the lock is lost, after the user hits save. The concepts states that the user gets the lock once (s)he requests the edit tab (see above) of the page. After a users hits save/return for a paragraph, the edit tab is requested again. The user is still in edit mode and still is owner of the lock.
 
This has been the lock "per page for the whole page while in editing mode of the page" concept, not the "lock per paragraph or page component concept". The concepts also clear states that you "select the number of minutes a lock should stay valid after the last user access to the "Edit" screen of a page. Nothing said that locks are released when save buttons are hit, since this does not make any sense for page based locks, see my comments in report #11767.

Marko Glaubitz, 22.11.2013: I thznik the prupose of this feature was to prevent users from losing changes through interaction with other users. This means, that if a user works with multiple browsers / tabs he/she can still overwrite her/his own changes. Thus, if either the locking time is up or if the user does anything else on ILIAS (click on "Page", use another tab to do something else, ...) there should not be an "open" editing sessions in the sense of active text fields, .... The lock should not be forgotten by doing anything on the platform in another tab (but can expire), if the user still has an editor screen (not the "Edit" tab) open and has not yet hit "Save & Return". Since the current version of a page is being loaded freshly if users insert / modify / do anything in the page editor no harm would be done.
As I sees it, simply having the edit tab openen is not equivalent to editing the page in a way that data / changes can be lost.
Thus, hitting "Save and Return" and releasing the lock seems to me as a good comprimise between not losing data and usability.

5 Implementation

...