Metadata lock is not removed if metadata editor is closed without using the close buttons

[BartChris]

I just encountered the problem that when the metadata editor is closed without using the buttons ("Schließen", "Speichern und schließen"), e.g. by jumping directly to the desktop, the metadata lock is not removed. And it seems like that even an admin cannot easily remove that lock.
I am not sure if this is intended since somebody might lock the editing of the metadata without being aware of it. It is probably not an easy fix but closing the metadata editor should probably always remove the lock - even if the user did not use the Buttons. Another option would be to give an indication to the user that the editor is locked for others and that he or she should should remove the lock, if the work is done.

[solth]

Duplicate of #3860

Yes, this is still bugged and not intended behavior.

The main problem I see is that even if we "unlock" a process through all the other links on the metadata editor page, the user can still use a bookmark or just enter the URL of a different Kitodo page directly, leave Kitodo altogether and visit some completely different page or close the browser/tab and we won't be able register that.

I tried using the onpageunload event but that didn't work either. If you have an idea how to remove the lock for processes in all cases described above, please let me know!

[BartChris]

Would it be possible to store a ,processlock_user' attribute in the process table? And set this to the id of the user who is blocking the metadata of the process? This would enable to show this Information as a Info icon in the process overview. And would maybe enable an action for a) the blocking user and b) the admin to remove that lock. Maybe in combination with a configurable timestamp so that the lock loses Validity if it is older than 30 minutes?

[BartChris]

I have no knowledge on JSF unfortunately but the way to proceed here using browser events seem to be OmniFaces viewScope annotations:

https://stackoverflow.com/a/40552152
https://stackoverflow.com/a/9986442
https://showcase.omnifaces.org/cdi/ViewScoped

[matthias-ronge]

First, if the same user re-opens the metadata editor for this process and then exits it regularly, then the meta.xml should again be released from the lock.

Second, if the user navigates to another page in another tab but leaves the metadata editor open (like doing a middle / mouse wheel click on the bread crumbs) then the lock should be maintained.

Third, when the user closes the browser tab, there is no way for Tomcat to observe this, as the browser then does not make an HTTP request. Maybe we could make this possible with an unbeforeunload event in javascript, but I don't know how reliable this is in all browsers, we would have to test thoroughly, and it can break in future browser versions.

A reasonably good way to handle would be using timing. That is, the browser sends requests to Tomcat when the user is working, and then a timer runs out in Tomcat, and when that is done and there is no new request, the lock is released. That was implemented in version 2 in the code, but I never saw it work because the timeout of the timer conflicted with the timeout of the Tomcat user session. Well, basically it is possible, but you have to pay attention to a lot: The program must intercept when the lock was released but the window remained open and another user has acquired lock in the meantime, then when the first user wants to continue editing, he must be logged out of the metadata editor. It's all very cumbersome.

It would be nice if there was natural support from JSF for this.

[solth]

I have no knowledge on JSF unfortunately but the way to proceed here using browser events seem to be OmniFaces viewScope annotations:

https://stackoverflow.com/a/40552152 https://stackoverflow.com/a/9986442 https://showcase.omnifaces.org/cdi/ViewScoped

@BartChris the documentation of the OmniFaces @ViewScoped annotation seems to describe exactly what we need! Implementing it would also fix #4182. Thanks for the hint! I will try to get onto it as soon as I get some time!

[matthias-ronge]

@solth or @oliver-stoehr, I seem to remember either of you had tried changing the annotation to @ViewScoped before, but that hadn't worked easily. Do you remember why that failed?

if the user navigates to another page in another tab but leaves the metadata editor open (like doing a middle / mouse wheel click on the bread crumbs) then the lock should be maintained.

Third, when the user closes the browser tab, there is no way for Tomcat to observe this, as the browser then does not make an HTTP request.

A @ViewScoped annotation wouldn't solve that problem either, would it?

[matthias-ronge]

Another question about this (also to @andre-hohmann, @subhhwendt and @henning-gerhardt, what do you think?): If we would add a button in the user list, to close all metadata that a user is working on: Should these metadata then be saved when they have been changed , or not?

[henning-gerhardt]

The user list is already terrible slow so adding an other button with some action would not increase the speed of this page. An other question back: who should click this button?

I don't know if the following is working and with the following assuming the following: one user has taken the task to edit the meta data of a process, so he/she take over the task and if he/she starts editing the meta data then the lock is set, correct? Why not add a timer component to the lock which is refreshed on the user actions inside the meta data editor and if the timer is ended because of no action of an user after a certain time the remove this lock.

[matthias-ronge]

who should click this button?

The person who else would have to restart Tomcat in order to unlock the meta.xml

if he/she starts editing the meta data then the lock is set, correct?

The lock is set when the metadata editor is opened, be it from a task, or from the process list.

Why not add a timer component to the lock which is refreshed on the user actions inside the meta data editor and if the timer is ended because of no action of an user after a certain time the remove this lock.

1. The function call must be added to each and every function the user can invoke. This adds many lines to the code.
2. If the lock is removed while the user still has the editor window open, and then continues editing, there must be introduced checks that forbid the user to continue. This again must be implemented in all and every function.

However, maybe there is a smarter way to do it …