-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
In the previous discussion (about Special:Desysop), it was proposed to merge the user rights pages (Special:Userrights, Special:Makesysop, Special:Makebot, Special:GiveRollback, and now also Special:Desysop) into the page Special:Userrights, using configuration settings. It seems to be a good time to propose it:
I've merged these special pages to Special:Userrights using configuration settings in http://svn.wikimedia.org/viewvc/mediawiki/branches/rotem/userrights , which is an improved user rights page.
This proposed system adds the following features to Special:Userrights: * Flexible configuration settings for a limited interface – for example, you can allow bureaucrats to grant only these permissions and revoke only those permissions, and allow the stewards to do everything. * Checkboxes instead of lists, mainly because it's possible to disable them separately while it's not possible in lists. * Changing the permissions of remote users for stewards, controllable by a permission ("userrights_remote"), like in the stewards interface of Special:Makesysop. * Log comment, to explain the change, like in Makebot.
You can either download and test it directly, or watch the following images:
http://img150.imageshack.us/my.php?image=mediawikinewuserrightsbureaucratslm... The limited interface for bureaucrats, like it can be set in Wikimedia sites.
http://img84.imageshack.us/my.php?image=mediawikinewuserrightsstewardsgg7.pn... The full interface for stewards, like it can be set in Wikimedia sites, editing a remote user.
This change should deprecate Makesysop, Makebot, GiveRollback and Desysop and make them implementable by using only configuration settings. However, these extensions may be kept for old versions, and for sites which were not updated. (There seems to be a compatibility issue with Special:Makesysop because one of its core functions (HTMLSelectGroups) was removed, but it can be defined in SpecialMakesysop.php or SpecialMakesysop_body.php as a class function.)
Additional technical information may be found in http://www.mediawiki.org/wiki/User:Rotemliss/User_rights_suggestion#How_to_u... . You can also read the other parts of the page, but it's a bit old and not updated in some parts. You can also ask here about anything unclear.
What do you think about this implementation? Which changes should be done? Do you think some features should be added, or dropped?
Thank you very much for the feedback.
- -- #define Name RotemLiss #define Mail mail-AT-rotemliss-DOT-com #define Site www.rotemliss.com
#define KeyFingerPrint 4AFD 8579 A449 4267 BED9 38E5 6EF8 5B1F EBDE 7AC0
On 15/08/06, Rotem Liss mail@rotemliss.com wrote:
- Checkboxes instead of lists, mainly because it's possible to disable
them separately while it's not possible in lists.
Just omit printing out the <option value=""... tag, then. A metric ton of checkboxes will *not* lead to a neat UI, nor a usable one. Lists have their own problems, but it's the lesser of two evils.
Rob Church
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rob Church wrote:
On 15/08/06, Rotem Liss mail@rotemliss.com wrote:
- Checkboxes instead of lists, mainly because it's possible to disable
them separately while it's not possible in lists.
Just omit printing out the <option value=""... tag, then. A metric ton of checkboxes will *not* lead to a neat UI, nor a usable one. Lists have their own problems, but it's the lesser of two evils.
Rob Church
Here is an example of this suggestion:
http://img148.imageshack.us/my.php?image=mediawikinewuserrightsbureaucrats2e... The limited bureaucrats interface, like the first image.
http://img66.imageshack.us/my.php?image=mediawikinewuserrightsstewards2ca7.p... The full stewards interface editing a remote user, like the second image.
In the limited interface, it's a bit odd to see nothing in "Member of:", and can cause some confusion. However, I agree that there is a problem with a long list of groups.
I think that the select lists may be better than the long list of checkboxes (especially when there are many groups), and I've replaced the first interface to the second one. However, another possibility is using a checkboxes list in columns of 6 groups each, if the list is too long.
Thanks for the feedback.
- -- #define Name RotemLiss #define Mail mail-AT-rotemliss-DOT-com #define Site www.rotemliss.com
#define KeyFingerPrint 4AFD 8579 A449 4267 BED9 38E5 6EF8 5B1F EBDE 7AC0
Rotem Liss wrote:
- Checkboxes instead of lists, mainly because it's possible to disable
them separately while it's not possible in lists.
Hmm? It's certainly possible to disable options separately in a select box: see for example http://vyznev.net/misc/disabled-option-test.html.
Mind you, pre-selected disabled options don't work quite as you'd expect, at least not in all browsers: they can still be deselected by clicking another option.
One solution could be a list of checkboxes in a scrollable <div>, using the CSS "overflow: auto" property (and an explicit height in ems); see for example http://vyznev.net/misc/scrollable-checkbox-list.html.
wikitech-l@lists.wikimedia.org