https://bugzilla.wikimedia.org/show_bug.cgi?id=57073
Web browser: ---
Bug ID: 57073
Summary: Identity reverts and PendingChanges rejection
Product: MediaWiki
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Unprioritized
Component: General/Unknown
Assignee: [email protected]
Reporter: [email protected]
Classification: Unclassified
Mobile Platform: ---
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?
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
