Last modified: 2011-01-25 01:28:20 UTC
I just had this scenario: A grawp move had the move page expunged (offensive move target) but the offensive edit summary had been left. So I updated the revision to delete that too. When I clicked apply, there was no update of the displayed information showing me what it looked like now. What would be useful: 1/ When deletion settings are updated in this extension, the new details are updated (AJAX style?) to show how it will now look. 2/ It should also be more visible and clear as to what non-administrators, and administrators, will each see.
(In reply to comment #0) > 2/ It should also be more visible and clear as to what non-administrators, and > administrators, will each see. > Possibly related to bug 17342. Probably using double-strikeout for content hidden from sysops and strikeout for content hidden from non-sysops would be clear enough without even a legend. Only oversighters are ever going to see content hidden from sysops, and single strikeout is clear enough in the first instance.
While _at present_ only oversighters can see the hidden content, that's very much a configuration option. The function allows for different material to be seen by different classes of user and may well be set up to do so. Hence item 2 to ensure users can be sure what will be visible, and what won't, to whom.
Example - I find an edit where some user put a virus site in the edit summary. I use revisionDelete to hide the edit summary, and click "Apply to selected revision". RevisionDeleted reloads the browser and states "Revision visibility successfully set", but does not grey out or overstrike the text, nor show the current visibility of the edit. Desired action - when tyhe button is clicked and the edit's visibility is amended, the current options are shown in the check boxes (rather than all checkboxes being empty), and if the user or edit summary is hidden, then the details reflect this by grey-out and strikeover, etc.
I can't reproduce this locally. Might be slave lag.
(In reply to comment #4) > I can't reproduce this locally. Might be slave lag. > Fixed in r48672
