Last modified: 2014-11-20 09:14:27 UTC
Active vandals with evil names are often caught and reverted by local admins and rc-watchers before they are hidden. The resulting reverts, if done in the standard way, include the name in their edit summaries: https://bugzilla.wikimedia.org/show_bug.cgi?id=18525 After a successful lock and hide, even if resulting edits are deleted from the article history, not only does the name still appear in these histories via the rv's, but it is now harder for local admins to track down all edits by an active spammer or vandal to clean up those ripple-effect edits. A change to the extension could look for instances of the name to be hidden near the user's edits and offer appropriate action (for instance deleting both the edit and its rv). This would be easier to script if bug #7566 were resolved.
(In reply to comment #0) > Active vandals with evil names are often caught and reverted by local admins > and rc-watchers before they are hidden. The resulting reverts, if done in the > standard way, include the name in their edit summaries If that's a problem then the edit summaries can be hidden.
This also has nothing to do with CentralAuth. Changing component/product accordingly & CCing Aaron.
(In reply to comment #1) > (In reply to comment #0) > > Active vandals with evil names are often caught and reverted by local admins > > and rc-watchers before they are hidden. The resulting reverts, if done in the > > standard way, include the name in their edit summaries > > If that's a problem then the edit summaries can be hidden. > On the other hand, it may be quite difficult to actually find those edits if, for example, the edit is reverted with undo some edits later. The default edit summary would contain the username, but wouldn't be easily visible by looking at the next diff (or even at the history page, depending on the circumstances).
(In reply to comment #1) > (In reply to comment #0) > > Active vandals with evil names are often caught and reverted by local admins > > and rc-watchers before they are hidden. The resulting reverts, if done in the > > standard way, include the name in their edit summaries > > If that's a problem then the edit summaries can be hidden. > As said in [1] it would be very handy, of course the summary could be hidden by an oversighter, but the problem is that this happens quite often and that this often includes a lot of reversions, which means lots of edit summaries that would have to be hidden. You may say that in the edit summary it does no harm, but then what is the purpose of hidename when it does no harm in the summary also on smaller wikis (where such vandalism also occurs), the names and reverts are seen in the rc for a longer time. Best regards. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=17831#c6
hopefully a clearer summary
Note that there isn't an easy way to do this. It would require either fulltext search for edit summaries or possibly a separate links table for links in edit summaries.
Doesn't seem so hard, but looks more appropiate for a toolserver addon. But I don't think the toolserver would have access to them. Maybe the edits could be searched by the id, but that would be one for each wiki, which is not friendly..
r105432 links the wrong revision.
With our current database scheme, this isn't doable and introducing either fulltext search to edit summaries or list links in a page_links like manner to resolve this is totally overexaggerated. So WONTFIX.
I'm not sure why local wiki administrators can't simply remove the username from the reversion summaries if it bothers them. It's a matter of tweaking a few MediaWiki messages and maybe a few user scripts. The easiest way to clean up a mess is to not make one in the first place. If wikis are concerned about these offensive usernames in reversion summaries, stop including them. :-)
Re-opening, there's a valid bug here, even if the solution is hard.
Solution would be to only store user ids in rollback summaries and then only substitute them with user names on run time. That way suppressions etc. could be taken into a account.
Or change {{int:revertpage}}
(In reply to MF-Warburg from comment #13) > Or change {{int:revertpage}} That's implied by this.
Change 153979 had a related patch set uploaded by Legoktm: [WIP] Store user id in revert messages https://gerrit.wikimedia.org/r/153979
