Last modified: 2013-10-23 18:17:01 UTC
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...)
>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.
(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.
