Last modified: 2014-11-10 18:05:45 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 T54453, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 52453 - Accounts blocked on wikis with wgBlockDisablesLogin enabled should not continue to receive email notifications
Accounts blocked on wikis with wgBlockDisablesLogin enabled should not contin...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Email (Other open bugs)
1.22.0
All All
: High normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: SWMT
  Show dependency treegraph
 
Reported: 2013-08-02 12:40 UTC by MA
Modified: 2014-11-10 18:05 UTC (History)
8 users (show)

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


Attachments

Description MA 2013-08-02 12:40:46 UTC
Not sure if maybe Wikimedia/Site requests would be the appropiate place.

When an user account is blocked on a private wiki that has the 'wgBlockDisablesLogin' in the config, the blocked user should not continue to receive email notifications about pages changed on his watchlist. This is happening to me.

Blocked users on 'wgBlockDisablesLogin'-wikis won't be able to login and check the change made, and there's the posibility that private data may be leaked in the edit summary (data that the user is not suposed to access anymore).

Since blocking on those private wikis such as <http://noc.wikimedia.org/conf/highlight.php?file=private.dblist> (& I'm speaking for those that I know: CU and steward wikis) is not used as a way to prevent abuse, but as a tool to remove someone's access to the wiki, it makes sense IMHO to disable from blocked users the ability to continue to receive email notifications. I guess that that is the primary use of the tool in all of the other ones.

Thanks.
Comment 1 Kunal Mehta (Legoktm) 2014-06-29 06:12:29 UTC
We have the DisableAccount extension for this purpose, which according to <https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php> is enabled on both stewardwiki and CUwiki.

Is that not sufficient?
Comment 2 billinghurst 2014-06-29 06:30:37 UTC
Presumably not. That is tool that we use and seemingly this report is that they still receive notifications.

Deactivate an account (variation of Special:Block)

... deactivated MarcoAurelio (Talk | contribs) with an expiry time of infinite (account creation disabled) ...
Comment 3 MA 2014-11-10 18:05:45 UTC
(In reply to billinghurst from comment #2)
> Presumably not. That is tool that we use and seemingly this report is that
> they still receive notifications.
> 
> Deactivate an account (variation of Special:Block)
> 
> ... deactivated MarcoAurelio (Talk | contribs) with an expiry time of
> infinite (account creation disabled) ...

Nope. That is the normal 'block' option (the block log messages are customized over there).

Deactivation mentioned by Legoktm above is what is done via Special:DissableAccount. However it (is/was?) policy of that wiki not to use that powerful blocking tool unless it was strictly necessary (compromised accounts, etc.) as suggested by WMF because its use was not logged anywhere (cf. bug 32782 - not sure if that's really logged now, there was an ad hoc page created there for that purpose) and because its use is only reversible with system administrator intervention.

It is not rare that some CUs (and happened with stewards as well, tho less frequently) wants to take a break, drops the tools and it's access is removed, and after a couple of months the user regains the tools tho is allowed to have access to the Wiki again. It'd be overkill IMHO to call a sysadmin each time an account needs to be reactivated, when a simple "unblock" can be done.

Rename is an option, to free again the name and create a new account under the old name; however his/her former edits will be attributed to their old account, which is not an optimal situation IMHO.

Best regards.

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


Navigation
Links