Lock Timeout Prevents Later Editing
Description
When an edit lock expires due to 900 seconds inactivity on a private wiki, you are logged out — but since you are in the middle of editing the page, you cannot leave the page to log back in. The only solution is to kill the current window, log back in, intercept the lock, and then return to editing.
How to Reproduce
Begin editing a page on a private wiki, wait 900 seconds.
Browsers
Firefox 2.0
Has bug
Works correctly
Workarounds
Contact
Dervish1
Rate this Bug
0
Comments
That is only true if you have not checked the "Do not timeout my session" check box at the login…
I am always asked after 900 secs if i want to recreate the lock ( if possible) …
Yes, once I didn't edit for 15 minutes, on an edit page, and Wikidot locked it. But there was the "recreate lock" button…
It should be on the pop-up box that appears after 900 sec have passed since you started editing.
Also to prevent that from happening again, listed below; just click the "stay logged in" when you first login. So, you won't have to close everything and do it over again.
This may be true .. but any behavior that results in you being locked out and unable to do anything without killing the current process/thread/window/whatever is bad. There is a workaround, but since I managed to create the problem pretty easily, I thought you'd like to know about it (as a bug that you will eventually want to fix).
You are correct - this is bad for a user editing longer than 900 secs..
I am not sure if this is really a bug - the behavior of the site is the fact, that every edit -session has a time out of 15 minutes…
and you can see the timer running - why such a user do "not click" on "save & continue" ?
I beleive, no one of the developers team on wikidot.org will really spend time to make this able to be switched off…
… but again - this is my oppinion …
And your bug - entry will be seen anyway.
I don't have a problem with the timer; in fact, I think the timer is a good idea. Do not switch off the timer.
What is bad is that when the timer runs out, you can't click on 'save & continue' — because you're logged out and don't have permission to save. Also, you also can't log back in, because going to a login screen triggers the 'you can not leave this page until you have saved' warning.
From the conversation here, I think what would be desired would be for the timer running out to not only end your session but to also disable the interception of attempts to leave the current page.
I hope that makes a bit better sense.
Yes, the sense is clear - but the need for closing the "open task" waiting for update and
the (really important) "Unlocking" the (whole) Page is neccessary anyway.
I see no possibility to "hold" the line without an automatic "saving" of the entered content - this is exactly what was to prevent.
I am not a developer of wikidot . I see after 40 years in IT the need for a central service not to lock pages longer than absolutely neccessary.
I believe the behavier of this is not really changeable ( makes no sense to make he timeout longer and longer..) .
And the "logout" and neccessary login has nothing to do with the lock / unlock of the edit-session.
But again - I am only a user….
My privat behavior is for a long time always "copy" the edit window in another editor - session window of Mail or word - only to save it bevore the locking tiome out occurs and brings me in big difficulties.
And the save does not working correctly sometimes - than I have my last copy too ( for a retry).
Question again:
I re-created the locked time out - warning/error message ( on my oprivate site ) - and I can always click on try to lock again.. ( or such text button).
Do you not get such possibility ?
I don't believe I had the option to re-create the lock, before, but I can't reproduce that behavior now, after several tries. This is one of the reasons I always admired software testers — they rarely forgot to document exactly how to reproduce a problem. Being able to continue working is all I wanted, even if all the changes are lost, so I guess I have to be content.
Thank you for the suggestions about how to edit in another window. I suspect I should consider doing the same when I'm doing anything larger. I'll revisit this if I figure out how to duplicate the problem and show what I mean. I still suspect we're talking about different aspects of the same thing, but after my own 30 years in software development, this is my first time having to deal with shared resources that might require more than a simple semaphore lock.
Anyway, many thanks for helping me reach this point.