Page MenuHomePhabricator

Store user ids in rollback summaries and substitute them run time
Open, MediumPublic

Description

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:

T20525: Hiding a username should not remove useful links to user contribs

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.

See Also: T23612: Remove username from LQT titles

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:34 PM
bzimport set Reference to bz18526.

mike.lifeguard+bugs wrote:

(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.

mike.lifeguard+bugs wrote:

This also has nothing to do with CentralAuth. Changing component/product accordingly & CCing Aaron.

mike.lifeguard+bugs wrote:

(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).

spacebirdy wrote:

(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

mike.lifeguard+bugs wrote:

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.

(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

@Legoktm, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?

I note that the user ID solution will cause edit summaries to be completely wrong if a revert revision is imported to another wiki (since the same ID will refer to a different user).

In T20526#970583, @Qgil wrote:

@Legoktm, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?

The priority is correct, but I don't think I will have time to work on this in the near future.

Qgil removed Legoktm as the assignee of this task.Feb 14 2015, 3:48 PM
Qgil set Security to None.

Change 153979 had a related patch set uploaded (by Jforrester):
[WIP] Store user id in revert messages instead of names

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

Change 153979 abandoned by Legoktm:
[WIP] Store user id in revert messages instead of names

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