Currently, the app silently saves and writes over other edit without notifying about conflict.
example https://en.wikipedia.org/wiki/special:diff/795380478
Version: Android App 2.6.201-beta-2017-08-10 (but it's been broken a while before that)
Description
Description
Details
Details
- Reference
- bz64281
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Correctly handle edit conflicts. | apps/android/wikipedia | master | +102 -43 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T72163 Edit conflicts (tracking) | |||
| Resolved | Dbrant | T66281 Handle edit conflicts on the mobile app in some way |
Event Timeline
Comment Actions
Currently we just ignore Edit Conflicts and just overwrite the conflicting edit. This is 'bad' and we should get to have some way of both:
- Letting the user know that a conflict has occured
- Some way of resolving it
Comment Actions
@Krenair We're focussing on reading and not actively supporting editing right now, and also this is a nontrivial issue to fix.
Comment Actions
Honestly I don't see why clients should even be allowed to just ignore conflict detection like this. Perhaps it's an upstream MediaWiki-Action-API issue.
Comment Actions
Hi Guys,
IMHO this is a serious show-stopper. It is very embarassing to commit an edit conflict without even being noticed.
Please implement at least a simple fix soon, like showing a message like "Sorry, your edit cannot be saved because the page has been edited by another user". Possibly give the user a chance to copy their own text into system clipboard, but even completely throwing away the user's edit is better than an unnoticed edit conflict. Sophisticated stuff like merging text may be implemented later ...
This happened using Android 2.1.141-fdroid: https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:MeraVagahau&diff=153104970&oldid=153104896
Comment Actions
No progress here since 2014? IMHO it's irresponsible to keep the application like this. If you can't fix it, please disable editing in the mobile app completely.
Comment Actions
@Deskana no, this is absolutely not normal priority.
I'll defer to others on getting this more perfect/polished but for now at least making it fail instead of silently clobber other's changes without telling anyone that there was an edit conflict is IMHO high/UBN.
Comment Actions
enough is enough. silent data loss is not ok. IMO we should disable all editing from this app until this task is resolved.
(that was with Android App 2.7.225-beta-2018-02-06)
do I have to fix it myself? (currently a snow day, not entirely joking)
but seriously regardless of how it gets fixed now how did this go nearly 4 years without resolution? in T66281#1123593 @Deskana says this is a nontrivial issue to fix. can you elaborate?
Comment Actions
I'm not even saying make it perfect, but MVP
- no silent error, no clobbering, if there's a conflict then don't make the edit. and also pass the server enough data so that it is possible for it to do the server side conflict resolution magic
- but also no data loss client side. give the user an opportunity to copy the text that they were trying to save. possibly to clipboard or a share to another app.
note, that initial fix does not require any kind of local display of a diff or display of the server's version. that can be a future enhancement but the 2 points above are absolutely UBN.
Comment Actions
Acknowledged, and will move into our next sprint. However, the "mvp" solution will need to be something like the following:
- It looks like we can easily detect whether an edit conflict has occurred, by including the timestamp of the last revision, as the API specifies.
- We can also show an error to the user when they try to submit the edit (and don't actually submit the new edit).
However, doing anything beyond that (e.g. showing a diff) will indeed take significantly more work, and is not on the current road map.
In the interest of preventing data loss on the client side, we can instruct the user to copy the changes they've made to the clipboard, then go back to the article, refresh it, then edit it again.
It sounds like the biggest issue here is the silent "clobbering" of edits that can be made currently from the app, which would be mitigated by the mere detection of conflicts. Is that correct?
Comment Actions
there should be no data loss client-side nor on-wiki. but sounds like your comment just repeated what I already said so we're on the same page.
Comment Actions
Change 421141 had a related patch set uploaded (by Dbrant; owner: Dbrant):
[apps/android/wikipedia@master] [WIP] Correctly handle edit conflicts.
Comment Actions
@RHo : When there is an edit conflict, we advice the user to copy content and go back and refresh, and then when the user tries to exit, we still show the dialog asking the user to save changes. If we should not show that dialog once we show the conflict dialog, could you please open a ticket for that? : https://youtu.be/_gX9RMGnF7g
Comment Actions
Change 421141 merged by jenkins-bot:
[apps/android/wikipedia@master] Correctly handle edit conflicts.