Last modified: 2014-06-09 12:57:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T67831, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65831 - Rollback does not work on items
Rollback does not work on items
Status: NEW
Product: Wikimedia
Classification: Unclassified
Wikidata (Other open bugs)
wmf-deployment
All All
: High major (vote)
: ---
Assigned To: Wikidata bugs
u=dev c=backend p=0
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-27 20:26 UTC by Ajraddatz
Modified: 2014-06-09 12:57 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ajraddatz 2014-05-27 20:26:31 UTC
Rollback currently isn't working on any items, giving an editconflict error when none has occurred. Reverting with the (undo) button still works.
Comment 1 John F. Lewis 2014-05-27 20:28:43 UTC
Confirmed by Lydia in #wikidata.

+ CC: Aude
Comment 2 Gerrit Notification Bot 2014-05-27 21:31:44 UTC
Change 135696 had a related patch set uploaded by Aude:
Fix rollback by re-adding baseRevIdForSaving in EntityContent

https://gerrit.wikimedia.org/r/135696
Comment 3 Daniel Kinzler 2014-05-27 21:44:37 UTC
Please keep this ticket open after katie's fix is merged. I'd like to have it in one of the next sprints, to investigate why this nasty workaround is needed for rollbacks. In theory, the prepareSave method gets all the info it needs from its parameters: the base rev ID, and the current rev ID. It should be sufficient to compare these. I wonder why this doesn't work for rollbacks, we should alot some time to investigating this.
Comment 4 Daniel Kinzler 2014-05-28 09:43:32 UTC
It seems like WikiPage::commitRollback() calls WikiPage::doEditContent() with $baseRevId set to the ID of the revision to be rolled back to, instead of the current revision before the rollback. It's unclear what the idea behind this is, and WikiPage::doEditContent() does not specify what exactly $baseRevId is defined to mean, or what it is used for. In fact, it's not used at all per default, just passed on to some hooks and Content::prepareSave, which itself doesn't use it per default either. The revision ID recorded as the revision's "parent ID" is *not* the one passed via $baseRevId, but the ID returned by WikiPage::getLatest().

This is woefully underspecified. I'll write to the list and ask for clarification.
Comment 5 Daniel Kinzler 2014-05-28 11:33:55 UTC
I wrote some more details to the list: http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076712.html
Comment 6 Gerrit Notification Bot 2014-05-28 12:13:27 UTC
Change 135696 merged by jenkins-bot:
Fix rollback by re-adding baseRevIdForSaving in EntityContent

https://gerrit.wikimedia.org/r/135696
Comment 7 Gerrit Notification Bot 2014-05-28 12:32:05 UTC
Change 135760 had a related patch set uploaded by Thiemo Mättig (WMDE):
Fix rollback by re-adding baseRevIdForSaving in EntityContent

https://gerrit.wikimedia.org/r/135760
Comment 8 Gerrit Notification Bot 2014-05-28 12:41:43 UTC
Change 135760 merged by jenkins-bot:
Fix rollback by re-adding baseRevIdForSaving in EntityContent

https://gerrit.wikimedia.org/r/135760
Comment 9 John F. Lewis 2014-05-28 12:43:40 UTC
Patch merged.

Resetting back to open per Daniel's comment about putting this in one of the next sprints.
Comment 10 Lydia Pintscher 2014-06-09 12:57:12 UTC
Tobi: Is this all done now? I think we should open a separate ticket for the investigation as proposed by Daniel.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links