Last modified: 2010-08-06 10:13:15 UTC
Please add the following section to 'wgAddGroups' and 'wgRemoveGroups' in InitialiseSettings.php '+foundationwiki' => array( 'sysop' => array( 'inactive', 'confirmed' ), 'bureaucrat' => array( 'bot', 'sysop', 'bureaucrat', 'import', 'transwiki', 'inactive', 'confirmed' ), ),
I don't understand the purpose or need for an "inactive" user group. "confirmed" is apparently being implemented to give upload rights to brand-new accounts. There is probably a better way to implement this.
Those usergroups do, however, exist, and there are no reasons not to have these exceptions to rights assignment on foundationwiki; which is what this bug is about.
(In reply to comment #1) > "confirmed" is apparently being implemented to give upload rights to brand-new > accounts. There is probably a better way to implement this. Hmm, is this necessary? Under groupOverrides in InitialiseSettings, we have: // Fishbowls 'fishbowl' => array( '*' => array( 'edit' => false, 'createaccount' => false ), 'user' => array( 'move' => true, 'upload' => true, ), 'inactive' => array( // for show only ), ), That should give upload and move (the normal "autoconfirmed" rights) to all users in fishbowl wikis without needing to put them in a "confirmed" group first. If that's not working, then we need to fix that.
Cary is requesting add/rm for groups that already exist, so discussion about their usefulness is irrelevant here. Changes are live.
(In reply to comment #3) > (In reply to comment #1) > > "confirmed" is apparently being implemented to give upload rights to brand-new > > accounts. There is probably a better way to implement this. > > Hmm, is this necessary? > > Under groupOverrides in InitialiseSettings, we have: [snip] > That should give upload and move (the normal "autoconfirmed" rights) to all > users in fishbowl wikis without needing to put them in a "confirmed" group > first. If that's not working, then we need to fix that. It's working, it's just that there are more rights in the confirmed group: collectionsaveasuserpage, collectionsaveascommunitypage, autoconfirmed (= right to edit semiprotected pages) and skipcaptcha, so the group isn't technically unnecessary. The inactive group is, but that seems to be acknowledged by the comment. Since there's nothing obviously superfluous or useless going on here, I'm gonna give this a rest unless and until it's decided something should be done about this situation (which, admittedly, is a little weird) and I'm asked to change something.
please update, I had the names of user groups wrong. Please change: 'import', 'transwiki', 'inactive', 'confirmed' to 'importer', 'transwiki importer', 'inactive user', 'confirmed user' Fault me for thinking the actual user group names were consistent with what I believed to have seen on other wikis. Cary
(In reply to comment #6) > please update, I had the names of user groups wrong. Are you sure? $ sql foundationwiki_p; mysql> select distinct(ug_group) from user_groups; +------------+ | ug_group | +------------+ | bot | | bureaucrat | | import | | inactive | | oversight | | steward | | sysop | | transwiki | +------------+ 8 rows in set (0.00 sec)
Oddly enough, those four are still grayed out. Not sure if this is being overridden somewhere else.
Yeah, something's borked. http://wikimediafoundation.org/wiki/Special:ListGroupRights has (0), (1), etc. under "Administrators" and "Bureaucrats".
Fixed. I had accidentally added the AddGroups lines to groupOverrides instead.
