RFC: When user session ends, unlock locked assets

[smehrbrodt]

When a user edits something (article, category, etc), it is locked to prevent conflicts.
This is fine.

However, as the lock is only cleared when the user closes with the "Close" button, and not when he closes the tab, sometimes locks remain, and need to be removed manually.

I suggest that we remove all locks by users who don't have an active session anymore.
Maybe with our session garbage collector plugin.

[mbabker]

Natively, sessions don't advertise anything saying "this session belonged to this user". Joomla has this capability because of the extra metadata tracking. IMO the cleanup plugin is not the place for this because it is simply purging data from known sources, lock tracking requires scanning all database tables and can potentially be an expensive operation.

In the slim chance #13322 lands in 4.0 (I'm not holding my breath anymore, I seem to be the only one who cares about being able to disable this useless tracking), such a tool becomes useless anyway because the metadata wouldn't be there to work with.

FWIW the code in JTable that determines if a record is checked out does take this metadata check into account and will let the user edit a record if the "lock" is still owned by someone who no longer has a metadata record in the session table, so really the only annoyance is the visibility of the lock icon when it can be potentially inaccurate.

[smehrbrodt]

so really the only annoyance is the visibility of the lock icon when it can be potentially inaccurate.

Another thing is that you can't edit from the frontend when an article is locked. There is no way to unlock a locked article from the frontend afaik.

I also suggested some other enhancement related to this (#13120) but it got smashed down for reasons I don't understand.

[mbabker]

Another thing is that you can't edit from the frontend when an article is locked. There is no way to unlock a locked article from the frontend afaik.

Then that is a bug if the frontend edit code is not checking the lock state against the same code the backend uses.

I also suggested some other enhancement related to this (#13120) but it got smashed down for reasons I don't understand.

That would require JavaScript hi-jacking the browser navigation. Not reliable. I'm using that trick in a project actually, it doesn't work efficiently and definitely shouldn't be used to trigger AJAX operations which would most likely be action-blocking to the navigation action (back or close).

[brianteeman]

In the slim chance #13322 lands in 4.0 (I'm not holding my breath anymore, I seem to be the only one who cares about being able to disable this useless tracking), such a tool becomes useless anyway because the metadata wouldn't be there to work with.

As that has been merged then I am going to have to close this - sorry