Last modified: 2012-10-29 16:39:58 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 T22928, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20928 - Change visibility fails if existing states not identical. Use tri-state buttons?
Change visibility fails if existing states not identical. Use tri-state buttons?
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Revision deletion (Other open bugs)
unspecified
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Aaron Schulz
:
Depends on:
Blocks: SWMT 18780
  Show dependency treegraph
 
Reported: 2009-10-01 17:40 UTC by FT2
Modified: 2012-10-29 16:39 UTC (History)
2 users (show)

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


Attachments

Description FT2 2009-10-01 17:40:13 UTC
Easiest described by example:

Oversighter #1 sees a load of vandalistic edits in some page history with possible defamation in the edit summary. So he/she checkboxes those edits and suppresses the edit summary for 20 revisions.

Oversighter #2 reviewing a bit later notices that a couple of them don't have vandalistic edit summaries, but one of them did have vandalistic revision text. Modifies the suppression for 2 of those 20 revisions and passes it on for discussion. The consensus is to suppress the revision text on all of the edits.

At this point, the "change visibility" option for the 20 revisions breaks. RevDelete recognizes some of the 20 already have that setting and results in "failure".

What's happening is RevDelete needs all 20 revisions to be in the same state prior to an action on multiple revisions. if some of those revisions have been manually changed already, it can't cope, even if the requested change is to bring other revisions into line with them.

What I think should happen is, when RevDelete is reached by selecting multiple revisions (either by using checkboxes, or clicking "change visibility" in a log), the handling needs to be changed slightly.

1/ perhaps use tri-state buttons at [[Special:RevisionDelete]], to specify for each field either "forcibly show this field, for all revisions listed", "forcibly hide this field, for all revisions listed", or "don't change this field for all revisions listed". Hopefully that would be a more intuitive result.

A warning "These revisions are in an inconsistent state" + <usual summary of the revisions> + "do you want to force <field = value> for these revisions?"  would be better than just "failure".
Comment 1 Aaron Schulz 2009-10-01 18:30:52 UTC
Looks like another regression from the refactoring tim made.
Comment 2 FT2 2009-12-01 23:37:37 UTC
A further aspect to this bug report, posted for DerHexer:

When RevDelete is used to set visibility or suppression for multiple revisions, it also needs tri-state boxes. It may be for example that 20 revisions need suppression added, but 6 of them have combinations of edit summary or revision text already hidden by admins before this. It would be unnecessarily annoying to not be able to set suppression on all 20 just because some already had RevDelete used on them. 

But tri-state buttons could fix that, also.
Comment 3 FT2 2009-12-01 23:42:08 UTC
(To clarify: You can set suppression on all 20 in one action, but lacking tri-state buttons, this will also modify the visibility of all other fields on all 20 revisions to the specified value, which is unwanted.)
Comment 4 Aaron Schulz 2009-12-11 06:58:19 UTC
Done in r59949

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


Navigation
Links