incorrect work new element locked function

[Dmi3yy]

http://take.ms/54z9G

We have one of the functional users online http://take.ms/y0pdW
and if I edit the document online, and I then everything is OK and does not unlock until I online.

As soon as I am not online then remove my lock. For the current implementation is not very correct and beautiful

[Deesen]

Sry pls explain what should be more correct and beautiful? I will work on it.

[Dmi3yy]

We need to put a check on the line if the current user.
If I open page online but I do not remove the lock.
If I do not have to remove the active users. so I think even less code will be so beautiful

Lukianenko Dmytro
Web developer
Site: http://dmi3yy.com
Skype: dmi3yy
Phone: +38 (091) 357-10-80

понедельник, 21 ноября 2016 г. в 11:41, Deesen написал:

Sry pls explain what should be more correct and beautiful? I will work on it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub (#945 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAo3M-zLvoAp79wtzm9hgPp6savs_1dUks5rAWdRgaJpZM4K39w5).

[Deesen]

We discussed how to improve the lock-mechanismn and get it free of trouble as follows:

• revert everything related to "lock - interval" and no more relying on periodical server-requests (too many factors that can lead to unnessecary issues)
• add a new simple table "active_user_sessions" with fields userid, lasthit
• manager/index.php and includes/session_keepalive.php will update this table at each request when session is valid / user is logged-in
• rename "lock cleanup delay" to "keep session alive interval" and use this value in session.js / keepMeAlive(). If lasthit exceeds this interval, MODX will assume this user is no more online / logged out
• locked elements will only be unlocked
  • when user hits logout-button (ALL locks related to this user will be deleted)
  • by manager/index.php at every request, when no corresponding valid session in active_user_sessions exists (exceeding "keep session alive interval")
  • window.beforeunload triggering AJAX unlock-request when needed (hopefully free of trouble):
    • unlock for save+leave, cancel-button etc
    • no unlock for save+stay
    • no unlock when clicking "edit" on the same element multiple times in a row
• localStorage to share required parameters between windows like last clicked element/id

This way bad connection or whatever may go wrong, will not lead to unexpected behaviour or error-messages. While we still can have multiple locks, and avoid those everlasting lock-"corpses" (and customer phonecalls), just because a user (or admin) closed his browser and forgot to logout or press cancel.

[bossloper]

Sounds like a plan!
Would these changes potentially break any third-party snippets/plugins/modules (though I don't know of any) and so prevent some from upgrading to 1.2 and beyond?

Along those lines, please also check to make sure Quick Manager+ lock/unlock (for resources edit, inline tv edits etc) works after these improvements are implemented.

[Deesen]

No it cannot break anything I know of. The original "active_users"-table is still working like before, no changes.

[fourroses666]

Avoid everlasting lock "corpses".

That would really help out.
Clients just don't understand it unless you have tell them.

[mcparana]

also click on other resource/element in tree has to unlock edited resource/element if any (maybe window.beforeunload triggering AJAX unlock-request will handle that, dont know)

[Deesen]

Yes I´m already fighting with all those issues.

[Deesen]

One issue is left as already mentioned on Slack: The Unlock-Ajax-Button and "Remove Locks" is still working, I did not remove it yet.

Do we need any "unlock"-buttons? Locks will clean-up automatically now, there is no need for any unlock-button except admins want to have the option to "steal" a lock, to prevent a user editing a resource for any reason. This is the only usage I can imagine.

[bossloper]

I guess there is no harm in leaving the 'unlock' (steal!) option there for now? Could be revisited at 1.2.1 and at least it gives a safety net for removing locks if there are any unforeseen issues.