Regardless of the solution, we are not accepting new features to Joomla 3. So this PR would have to be made against the 4.0-dev branch instead.

Sure. In J3 I just knew where to do it. In J4 I don't know yet. So for an RFC that will have to do.

This functionality belongs in the session garbage collection (or wherever sessions are marked as expired).

Ideally, checking out an item will emit an event for a listener that registers that item. Releasing the item by saving or cancelling the edit process emits an event for a listener that unregisters the item. The session cleanup process emits another event on closing a session (as does the logout) for a listener that checks-in all items registered with that session.

Thus, the lock icon keeps its meaning.

I like the idea with the events.

The listener doesn't need to register the items as we already do that in the table when checking out the item. It wouldn't make much sense to tie the lock to a specific session anyway as the user may switch browsers and keep editing the same item or switch the application (eg from backend to frontend) or even device.

If the cargabe collector can pass the userid to the event, then I think it would be sufficient if a component can listen to the "unregister" event (with a component specific plugin or a dedicated helper method) and check-in all items checked-out by that user. That would be a rather simple SQL command in that case.

We would have to be sure it was the last active session of that userid, if other sessions are still active (eg in another browser or another client) we shouldn't check-in the items.

But I haven't looked at that cargabe collector method yet. Is it able to provide that information to the event? We'd need the userid and if another session is still active for that userid.
If not we indeed need the register and unregister events and a plugin needs to store the session and table information when editing an item.

Another way could be, is to check how old the date in "check in" column.
Since the "check in" date are updates on every "save action", we could determine if user still "aktive"
Something like:

if (time_now - check_in_time) >  session_time * 2:
  User is inactive

It not 100% accurate, but could work also :)

Yep, that works. Plugins like https://extensions.joomla.org/extension/autocheckin/ work like that.
However there are several drawbacks:

• Sessions are kept forever when the user has an editor open. The keepalive JS takes care of that. So the checkout could time out while the user is still actively editing the item (even without saving it). That would basically make the checkout useless.
• The mentioned plugin has a performance impact as it does run several database queries on each pageload. That's not very efficient. Also it only works for the tables it checks (articles, menu, modules, plugins), it doesn't work for all other items. That's why I wanted to do something in the checkout method - but then the lock icons are not cleared beforehand.

Just an idea,
Inform the user in an existing session, that there is an object still checked-out, with the option to either discard it or edit it.
This could be additional done onlogin / onlogout.
Administrator/ Super User can set a max-check-out time, which were presented to the user as a countdown-timer.
When the max-checkout-time is reached, the object is reverted to the last version and checked-in or, in case there is no version available, that object will be either disabled or just checked-in again.

Inform the user in an existing session, that there is an object still checked-out, with the option to either discard it or edit it.

That would need a specific table where we store checked-out items per user. Otherwise we just don't know it without quering each database table - which for obvious reasons isn't going to happen on each pageload.
Also it doesn't help when the user just closes the browser.

When the max-checkout-time is reached, the object is reverted to the last version and checked-in or, in case there is no version available, that object will be either disabled or just checked-in again.

There would be nothing to revert or disable or whatever. "Checked Out" means the user started editing, but that is always done in the users browsers. The server doesn't know about the edited content until it is saved, and then it's live right away.
So all that has to be done is clearing the "checked_out" field in the database table.

Ok, but in combination with the upcoming workflow feature in 4.0, isn't
there already a table for that?
I mean, a kind of default workflow (just the user has to approve) and in
the way that the user had hit Save at least once, would help here?

And in the case (with that default workflow) that the user haven't saved
even once so the changes are lost, he just hit discard or the timeout runs
out and the object is checked-in again...

Just my 2c ....

Thomas Hunziker notifications@github.com schrieb am So., 13. Sep. 2020,
21:10:

Inform the user in an existing session, that there is an object still
checked-out, with the option to either discard it or edit it.

That would need a specific table where we store checked-out items per
user. Otherwise we just don't know it without quering each database table -
which for obvious reasons isn't going to happen on each pageload.
Also it doesn't help when the user just closes the browser.

When the max-checkout-time is reached, the object is reverted to the last
version and checked-in or, in case there is no version available, that
object will be either disabled or just checked-in again.

There would be nothing to revert or disable or whatever. "Checked Out"
means the user started editing, but that is always done in the users
browsers. The server doesn't know about the edited content until it is
saved, and then it's live right away.
So all that has to be done is clearing the "checked_out" field in the
database table.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30625 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQNZU54PW32IFCZDWV4OKETSFUKKZANCNFSM4RJ4TTRQ
.

I'm closing this RFC as it is clear it is not going to work in J4 and I don't have the ressources and knowledge to deal with the garbage collector.