Last modified: 2013-06-18 16:00:44 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 T20383, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18383 - RevisionDelete: hidden users appear in log entries created after the hiding
RevisionDelete: hidden users appear in log entries created after the hiding
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Revision deletion (Other open bugs)
unspecified
All All
: Low normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 18568 (view as bug list)
Depends on:
Blocks: revdel SWMT
  Show dependency treegraph
 
Reported: 2009-04-07 14:11 UTC by Dominic
Modified: 2013-06-18 16:00 UTC (History)
5 users (show)

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


Attachments

Description Dominic 2009-04-07 14:11:35 UTC
Hideuser only has any effect on the log entries and contributions that exist at the time of hiding. If it is possible, it should also hide log entries that are created afterwards. As an example, a vandal account with an innocuous name, or even a well-meaning editor tagging a userpage, can edit the user/talk page of a hidden account, and the resulting deletion and/or protection logs reveal the hidden account name. These logs should be hidden from the start.
Comment 1 Aaron Schulz 2009-04-22 06:23:04 UTC
Maybe editing of the user page by anyone should be blocked and log entries have the target hidden?
Comment 2 Dominic 2009-04-22 06:53:51 UTC
Blocking edits to their userspace is a good idea. If log entries occurring after the hiding can also be automatically suppressed as they occur (I think that's what you're saying), that solves the problem. Second choice would be to, as with the edits, just prevent subsequent (un)protections/(un)deletions/(un)blocks/renames/moves on the user(space).
Comment 3 Aaron Schulz 2009-04-22 06:59:49 UTC
Yeah, I was wondering if there is any reason to allow protect/move type events. If there is none, they can just be disallowed.
Comment 4 Aaron Schulz 2009-04-22 07:00:28 UTC
(In reply to comment #3)
> Yeah, I was wondering if there is any reason to allow protect/move type events.
> If there is none, they can just be disallowed.
> 

Well, except suppression events, like page suppression, which may come in handy and logged privately.
Comment 5 Dominic 2009-04-22 07:31:28 UTC
As long as any existing pages in the userspace are automatically deleted and suppressed when the user is hidden, so it doesn't become impossible to remove them after hiding, I don't see any reason to allow such events.
Comment 6 Aaron Schulz 2009-04-22 07:33:26 UTC
Currently, user and user talk pages and subpages are not suppressed on block.
Comment 7 Aaron Schulz 2009-04-23 00:54:59 UTC
(In reply to comment #6)
> Currently, user and user talk pages and subpages are not suppressed on block.
> 

Done in r49742; not subpages yet.
Comment 8 Aaron Schulz 2009-04-25 02:40:39 UTC
*** Bug 18568 has been marked as a duplicate of this bug. ***
Comment 9 Aaron Schulz 2009-07-30 18:11:12 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Currently, user and user talk pages and subpages are not suppressed on block.
> > 
> 
> Done in r49742; not subpages yet.
> 

Reverted btw.
Comment 10 Rob Lanphier 2011-12-03 00:27:22 UTC
There are just too many places where this info will end up popping up, and it's just too hard to *guarantee* that the name won't be findable in any form.

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


Navigation
Links