Stewards' handbook

User groups and rights adjustment

Single wikis

Stewards can use Special:Userrights on Meta to adjust users' access on any Orain wiki by checking or unchecking specific groups. Each group is assigned a set of rights in the MediaWiki configuration, listed by Special:ListGroupRights on each wiki.

1. Enter the user name.
   • The format must be "Username@database_prefix" (for users on other wikis) or "Username" (for users on Meta).
   • The first letter of the name must be upper-case (unless the wiki allows case-sensitive first letters in names).
   • The database prefix consists of the project name followed by wiki.
2. Click "Edit user groups". A new box will appear showing you what groups the user is already in, and which other groups are available.
3. Reassign the groups.
   • To assign a new group, check the appropriate group.
   • To remove a group, uncheck the appropriate group.
4. Click "Save user groups".

Rights

The following groups can be manipulated (among others on some wikis):

• Administrator
• Bot
• Bureaucrat

• Restricted groups
  • CheckUser

• Very restricted groups
  • Steward – Do not manipulate the steward flag on any wiki except Meta unless a new steward has been granted access. The right may be manipulated on other wikis as well but only if there is an absolute need.

Encoding problems

Many browsers have difficulty manipulating user names in non-Latin characters. There are two ways to get around this problem:

• Enter the URL-encoded name through the URL.
  1. First, get the URL-encoded name:
     • Copy it from the address bar of your browser while viewing their user page;
     • or, type "{{urlencode:{{PAGENAME}}}}" on the user's page, preview, and copy the text.
  2. Go to Special:Userrights, and in the address bar add "?user=" followed by the URL-encoded name. For example, http://meta.orain.org/wiki/Special:Userrights?user=Foo+Bar.
• Enter the user id (for example, "#55@testwiki" for user #55 on the Test wiki). There are a few ways to determine the user ID:
  • Ask the user. They can find it on Special:Preferences on that wiki.
  • If the user has edited on that wiki, you can find the ID by exporting that revision (if it is the latest) or exporting the whole history and locating that revision. Once located, look for the number inside "<id></id>" under "<contributor>" (make sure you're not getting the revision ID under "<revision>").

Globally and wiki sets

Global accounts have the same name and password reserved on all public Orain wikis (except previously-existing unattached local accounts). These global accounts can be assigned global groups, which give the user certain rights on all wikis where their global account can log in.

Note that a right is a specific access (like "edit-interface"), and cannot be given to a user directly; a group is an abstract grouping of rights (like "steward").

Managing groups

Stewards can create, edit, or delete a global group using Special:GlobalGroupPermissions. The scope of each wiki can be global (all public wikis), or defined for a specific set of wikis.

• Edit:
  1. In the "Existing groups" box, click "View and edit permissions" for the group you want to edit.
  2. A list of possible rights will appear. Check the rights the group are to have and uncheck those they are not to have.
  3. If the group needs access on specific wikis (instead of globally), select the set of wikis in the drop down menu above the list of rights (see Managing sets of wikis).
  4. Enter the reason for the change in the textbox below.
  5. Click "Save changes to group permissions". The changes will be applied immediately.

• Create:
  1. Enter the group name in the "Create a new group" textbox.
  2. Click "Assign permissions".
  3. Check at least one right, and if applicable select the scope (see step 2 onward how to edit above).

• Delete:
  1. Uncheck all its rights (see how to edit above).
  2. The group can be recreated later, and all former members will regain the same rights.

Managing group membership

Stewards can edit global accounts' membership using Special:GlobalGroupMembership. Placing a global account in global groups will give them all the rights assigned to that group on all public wikis.

1. Enter the global account's user name in the textbox.
2. Select a wiki where they have a local account from the drop-down menu.
3. Click "Edit user groups". A "Edit user groups" box will appear below.
4. Check the global groups to assign. (Even if they are similarly named, global and local groups are not necessarily identical!)
5. Enter the reason for the change in the textbox.
6. Click "Save User Groups".

Managing sets of wikis (for global groups)

Stewards can define 'wiki sets' using Special:EditWikiSets, lists of wikis where global groups can be given access (instead of globally). It's not necessary to create a set of all wikis: that is the default for global groups if no set is selected.

1. If you're creating a new set, click "Create a new set". Otherwise, click "view/edit" beside the name of the existing set to edit.
2. Enter the set's name in the 'name' box. This is for the convenience of stewards, and can be changed any time.
3. Select the appropriate type in the 'type' box (opt-in or opt-out).
4. Enter the database prefixes, one per line, in the 'wiki' box.
5. Enter the summary or reason for your change, which will appear in the global rights log.

Managing global accounts

Stewards can access unification information about a particular global account, unattach local accounts from the global account, delete the global account (restoring all local accounts), and lock out access to the account using Special:CentralAuth (see logs).

Warning: Accounts should never be locked except in cases of certain bad faith. Locking the account (not to be confused with global blocking for IPs) will cause the user to log out, and prevent their login on all wikis by rejecting their password. There is no indication of what happened to the user, so they have no possibility of appeal or knowing the reason for the lock.

Global account deletion

Stewards can, via Special:CentralAuth, delete global accounts. This should only be done when there is a compelling reason. Requests such as "I don't want it" are not sufficient to warrant a deletion.

• Requests to delete the global accounts of vandals should not be performed at all, as this would interfere with the ability to lock the account in case of a spread of the abuse.
• If a user has renamed themselves globally and left behind an empty global account, that global account may be deleted to free the old username. While this is possible, the user should consider leaving the global account in place in order to prevent users from creating a new account under the old name, which would be linked in previous signatures and community discussions.
• Users should be warned that preferences (including passwords and email addresses) will be reset to their pre-merge values and that they will lose any global group membership which they previously had. Local accounts will not be otherwise affected and cannot be deleted.
• Some bot owners may request a deletion of the global account if it interferes with proper functioning of the bot. Of course, non-unified bots are not eligible for the "global bot" flag, and if the bot login password has changed during the time it was unified, that password will be reset to the pre-unification password.
• Warning: Once a global account is deleted, it cannot be reversed by stewards.

Unmerging local accounts from the global account

If a local project wishes to rename a vandal account, unmerge only that project from the vandal's global account, even if it's the only project in the global account. If there is a valid reason to not want the global account to be visible after the rename, the global account should be hidden instead of deleted, as deleting it would simply open that account name to recreation.

Global access restriction

IP address blocks

Stewards can block IP addresses and CIDR ranges (up to /16 in size) on all public Orain wikis using Special:GlobalBlock, and remove a global block using Special:GlobalUnblock. Current global blocks are listed on Special:GlobalBlockList and logged on Special:Log/gblblock.

Globally blocked IPs cannot edit any page on any wiki except Meta (which allows users to appeal on Meta). When a global block conflicts with a local block, the strongest block will apply; for example, a global anonymous-only block will be overridden by a local full block.

Local administrators can unblock a globally-blocked address on single wikis using Special:GlobalBlockWhitelist on those wikis, and customize the error message using MediaWiki:Globalblocking-blocked. If a local administrator wishes to locally whitelist an IP, it is best practice to contact a steward beforehand in order to verify a whitelist is appropriate.

Global account lock (& hide)

See "Managing global accounts" above.

Guidelines for processing requests

User access

1. Check the Steward requests/Permissions page regularly
2. Check that the procedure on that page has been followed and that the request does not violate any policies or guidelines (see the following sections for details)
3. If the request is valid, fulfill it using Special:Userrights (see above for instructions)
4. Mark the request as fulfilled as appropriate.
5. Leave the request on Steward requests/Permissions to allow follow-up comments and questions.

General advice

• Checking facts: If a user claims they already have a certain right, you can verify this by checking Special:Listusers on the local project. If the steward has any doubts about the request, they should discuss with one or more regular users of the local project.
• Promoting very new users: There is no approved policy regarding the promotion of very new users for projects with no local community. New users should generally not be given rights until they have spent more time editing projects. However, stewards might grant new users temporary rights until a community has time to build up, at which point it can hold a vote to confirm the user's status.

Administrator and bureaucrat rights

• If the wiki has a community, the community should have approved the user's request, generally on a local request page. The user should wait at least a week—perhaps two if the community is very small—before placing his request on Meta.
• If the wiki has no community, or if it has too few active users to hold a meaningful discussion of the issue, it is probably advisable to grant temporary rather than permanent rights.
• Be sure the community does not already have a local active bureaucrat. Stewards should only grant administrator and bureaucrat requests on wikis with no local active bureaucrats.

Removal of access

• If a user requests that his own rights be removed, check that he has confirmed his identity.
• If a user requests that another user's rights be removed, be sure that the action complies with the local wiki's policy on removal of rights.

Temporary rights

• The precise duration is a matter of discretion.
• After granting the request, move the request to the temporary rights section—and state clearly the date on which the rights are to be removed.
• Check the subsection occasionally and remove access from users whose expiry dates have passed.