Page MenuHomePhabricator

Set $wgBlockDisablesLogin to true when someone selects the "private wiki configuration"
Open, NormalPublic

Description

When a wiki is private (i.e. anon 'read' is disabled), then it would be expected that blocking a user will also remove their read access (i.e. it removes all of the extra rights that their user account has granted to them). However, that is only the case when $wgBlockDisablesLogin is set to true - and by default, it's set to false.

Of course, setting $wgBlockDisablesLogin to true by default would lead to unexpected behaviour in other situations (e.g. on Wikipedia, when logging into a blocked account you wouldn't be able to read any content, so you'd have *less* rights than an anon user has). So a simple 'yes/no' answer doesn't work here.

One possibility would be to make the default $wgBlockDisablesLogin setting conditional on whether anons can read the wiki - if they can, then it's false, if they can't, then true. That could then be overwritten by specifying a setting in LocalSettings.php.

Another one would be to add an option when blocking a user to also remove their read access (either by Special:Block and/or Special:UserRights).

(As a secondary issue: I note that while the default text at Special:Block does indicate that it blocks editing, it doesn't specify that it only blocks editing and not reading, and nor does that text change if $wgBlockDisablesLogin is set to true...)


Version: 1.18.x
Severity: enhancement

Details

Reference
bz33379

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 12:08 AM
bzimport added a project: MediaWiki-Installer.
bzimport set Reference to bz33379.
bzimport added a subscriber: Unknown Object (MLST).

One possibility would be to make the default $wgBlockDisablesLogin setting
conditional on whether anons can read the wiki - if they can, then it's false,
if they can't, then true. That could then be overwritten by specifying a
setting in LocalSettings.php.

That could certainly be done. Another possibility is to just have the installer set $wgBlockDisablesLogin to true when someone selects the "private wiki configuration" (Won't affect existing wikis or custom set up wikis, but would make new ones be more like what the user probably wants)

(In reply to comment #0)

Of course, setting $wgBlockDisablesLogin to true by default would lead to
unexpected behaviour in other situations (e.g. on Wikipedia, when logging into
a blocked account you wouldn't be able to read any content, so you'd have
*less* rights than an anon user has). So a simple 'yes/no' answer doesn't work
here.

We would just over-ride it, like we do with many other settings. We already have that enabled on the private wiki group by default.

I have always seen blocking as a method to stop people editing for a variety of different reasons (spam being one) and we shouldn't mix up what blocking means by having different meanings and actions on a "public" vs "private" setup, unless the end consumer wants to setup that way.

demon added a comment.Dec 27 2011, 5:53 PM

(In reply to comment #2)

I have always seen blocking as a method to stop people editing for a variety of
different reasons (spam being one) and we shouldn't mix up what blocking means
by having different meanings and actions on a "public" vs "private" setup,
unless the end consumer wants to setup that way.

If we made blocking a per-right affair (bug 14636) and made logging in a user right, it would make the separation much clearer.

$wgBlockDisablesLogin works well enough IMHO.

(In reply to comment #1)

Another possibility is to just have the installer
set $wgBlockDisablesLogin to true when someone selects the "private wiki
configuration" (Won't affect existing wikis or custom set up wikis, but would
make new ones be more like what the user probably wants)

Makes sense: moving to installer and changing summary.

@SpookyGhost8's code from the other task:

.

@SpookyGhost8's code from the other task:

.

Would I be adding the new code to the mediawiki-vagrant's installer file when submitting this commit through Gerrit? I will reinstall the applications tomorrow to also try and get the SSH keys working.

SpookyGhost8 removed SpookyGhost8 as the assignee of this task.Sep 19 2017, 6:49 PM
SpookyGhost8 added a subscriber: SpookyGhost8.