Page MenuHomePhabricator

allow detection of watchlisting and other "invisible" uses of account
Closed, DeclinedPublic

Description

bug 4350 (Delete unused user accounts) starts by proposing the removal of unused acccounts. Arguments presented are mainly:

  1. to unclutter the Special:Listusers
  2. to make room for the creation of new users with simple usernames (comment #6 From Borgx: "The purpose of having inactive accounts deleted is to make the account name available to other users. For ex. account adam and alex on id.wikipedia is never used. And that accounts are simple name for a lot of users. If users which created those accounts nevermeant to use it, then those accounts are unavailable FOREVER!")

From Rob Church's comment #4 onwards, the discussion moves (as Rob himself recognizes, in comment #7) towards the possibility of hiding unused accounts, which would solve the first issue but not the second.

Comment #8 From Reinhardt WIEWE states that deleting accounts is not reccomendable, since, as he says "some "users" / visitors migth create an account in order to benefit from the watchlist." Hojjat also noted on MediaWiki-General IRC channel that the emailuser function could as well be used without leaving log entries. I assume there might be other features that a user can use without showing external signals of activity.

So, my proposal is to implement a way to detect such actions (without, evidently, displaying the details of the actions, such as email address, messages or receivers, pages watched, or other similar information).

That would make the removal of unused accounts uncontroversial and the script mentioned on comment #2 (removeUnusedAccounts.php) could be used in mediawiki wikis without any problems.


Version: unspecified
Severity: enhancement

Details

Reference
bz11962

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:58 PM
bzimport set Reference to bz11962.
bzimport added a subscriber: Unknown Object (MLST).

Logins, watchlistings, and preference changes update the user_touched timestamp which can be internally detected.