Last modified: 2014-01-10 18:42:48 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 T59073, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 57073 - Identity reverts and PendingChanges rejection
Identity reverts and PendingChanges rejection
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
FlaggedRevs (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Jackmcbarn
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-14 20:09 UTC by Andrew G. West
Modified: 2014-01-10 18:42 UTC (History)
3 users (show)

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


Attachments

Description Andrew G. West 2013-11-14 20:09:35 UTC
This follows from discussion at: https://en.wikipedia.org/wiki/Wikipedia_talk:STiki#Pending_changes_and_STiki

Assume an article is under pending changes protection. An IP user then makes a vandalism edit. If another user with 'reviewer' permissions issues a rollback command via the API, then all the PendingChanges annotation seems to occur properly, as the editor auto-accepts his own version. 

It doesn't work this way if the edit is reverted without using rollback. For example in Huggle, STiki, and other tools we simulate rollback in software for: (1) those that don't have the native permission, and (2) when doing "good faith reverts/rollbacks" that should not be marked as "minor". In these cases, a reviewer can revert a pending changes revision, but their change is not auto-accepted, and they sit in the review queue.

This speaks to the larger issue that PendingChanges works well in the browser where there is a well-defined workflow, but it can be a bit challenging to integrate with existing anti-damage tools via the API. (See also some concern about "multi-user pending changes chains" in the above link). 

How this should be resolved is an open question. Could a parameter be passed at edit time to force acceptance? Could the software better recognize identity reverts and treat them consistent with rollbacks?
Comment 1 Aaron Schulz 2013-11-14 20:31:25 UTC
Reverts of the last X edits can all be detected using the rev_sha1 column instead of relying on the old baseRevId params so much (which bots usually don't supply unlike people in browsers). It seems like improvements could be made then.
Comment 2 Platonides 2013-11-14 20:33:01 UTC
If it's just a matter of providing baseRevId, the tools can be changed to give them.
Comment 3 Aaron Schulz 2013-11-14 20:34:30 UTC
(In reply to comment #2)
> If it's just a matter of providing baseRevId, the tools can be changed to
> give
> them.

This too, since rev_sha1 cannot handle anything beyond straightforward reverts with no other changes.
Comment 4 Gerrit Notification Bot 2014-01-10 17:51:21 UTC
Change 106737 had a related patch set uploaded by Jackmcbarn:
Autoaccept reverts to the last stable revision

https://gerrit.wikimedia.org/r/106737
Comment 5 Gerrit Notification Bot 2014-01-10 18:38:13 UTC
Change 106737 merged by Aaron Schulz:
Autoaccept reverts to the last stable revision

https://gerrit.wikimedia.org/r/106737

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


Navigation
Links