Last modified: 2014-01-17 03:55:33 UTC
On mediawiki.org page, unregistered users can't edit LQT posts. It doesn't matter if the message was originally posted by the same user or not. When editing a post, the edit form is displayed as normal. But when saving the edit, the "progress" icon appears and nothing more happens. Inspecting what's going on in the AJAX calls, I can see the edit request is posted, but the server response is: {"servedby":"mw1202","error":{"code":"editconflict","info":"Edit conflict detected"}} If I edit the post as a logged in user, the same info is sent to the API when saving the edit, except the "token" which is different, so I can't see how it's detecting edit conflicts. I'm going to open another bug requesting a better handling of those error responses from the server, since the "Edit conflict detected" message isn't displayed anywhere.
Well, error handling seems covered in bug 28132
Seems that an edit conflict is detected for all users, but the check to see if you're conflicting against yourself (which suppresses the conflict) doesn't apply to anonymous users.
I don't understand how these are conflicts though: timestamp: 20130425193332, edittime: 20130813191144 EditPage::internalAttemptSave: conflict! getting section '' for time '20130813191144' (article time '20130425193332') This is determined by a check in EditPage::internalAttemptSave: $timestamp != $this->edittime I wonder if that != should be a >=...
I've looked to what params are posted when the edit is saved, and they are: * action=threadaction * threadaction=edit * thread=<THREAD ID> * text=<MESSAGE TEXT> * render=1 * reason=<EDIT SUMMARY> * bump=true * signature=<SIGNATURE> * token=<TOKEN> Compared to a normal edit page, or what params are available to http://www.mediawiki.org/wiki/API:Edit for edit conflict resolution, LQT seems incomplete. It should get a "basetimestamp" along with the edit form, with the timestamp of the last edit of that message, and send it when the edit is saved, and pass it to the edit conflict resolution logic. Otherwise there's no way to detect conflicts because it doesn't know from what revision/timestamp the edit was started.
If you read the code for LQT's threadaction you'll see that it deals with basetimestamp. We know this is happening because otherwise no conflicts would be detected.
(In reply to comment #5) > If you read the code for LQT's threadaction you'll see that it deals with > basetimestamp. We know this is happening because otherwise no conflicts would > be detected. So this is not related in any way to bug 34580?
(In reply to comment #5) > If you read the code for LQT's threadaction you'll see that it deals with > basetimestamp. We know this is happening because otherwise no conflicts would > be detected. As I said, when you save the edit, the server isn't getting that basetimestamp. Yes, I see how it's "dealing" with it: 'basetimestamp' => wfTimestampNow(), That's wrong, since there's no way to know from which "revision" the edit was started. Maybe someone else saved the edit before you, but LQT has no reference to detect it. The workflow should be: 1. A request is made to get an edit form of a message 2. LQT should send the basetimestamp of the current message along with the edit form 3. The user hits save. 4. A request is made with all the current fields plus the basetimestamp received in #2 5. LQT should use it to detect edit conflicts, instead of generating a reference basetimestamp from wfTimestampNow() Editing a message should be like editing any normal page (if I haven't understood it wrong). Every message is like a page.
