Extension:WhiteList/User's Guide

Manager Usage: Whitelist Access Editor
The Whitelist Access Editor is divided into two sections. The top portion entitled Current information for Some User details all of the currently whitelisted wiki pages for the selected restricted user. The bottom portion entitled Add new pages to Some User's whitelist is for defining new whitelist pages for the currently selected restricted user.

Current Whitelist Pages
This table contains 6 columns. Each row corresponds to one whitelisted page for the currently selected restricted user. The title of this page is in the Wiki Page column. A manager can verify that this page really should be whitelisted by clicking on the title which takes then to that page. The other columns to the right are detailed below:
 * Access Type - lists what kind of access was given to the resitricted user for this page. There are only two options: edit and view.
 * Expires On - lists when the restricted user's whitelist access for this page will automatically expire. This could be a date, either in the future, which means that the restricted user still has the ability to access that page, or it could be a date in the past, which means that the restricted user's whitelist access to this page has expired. A blank entry means that there is no expiration date for access of this page.
 * Last Modified By - lists the name of the manager who last modified the permissions this restricted user's access to this page.
 * Last Modified On - lists the date on which the manager who last modified the permissions this restricted user's access to this page did so.

The manager interacts with this restricted user's current permissions by selecting one or more pages in the Modify column by clicking on the checkboxes. In case the manager wants to interact with all listed pages at once, they can click on the All or None links in the column heading which checks or clears all checkboxes, respectively. The action to perform on the pages checked in the Modify column are detailed below the table. A manager can select only one of the following actions: Once the pages and the action are defined, the manager needs to click on the Process button.
 * Change Expiry Date - set the Expires On date for all selected pages to the date defined in the New Date field to the left. For manager's convenience, clicking on New Date brings up a JavaScript calendar. Remember, the New Date can be left blank to indicate that page access will never expire.
 * Set to Edit - set the Access Type permissions for all selected pages to Edit.
 * Set to View - set the Access Type permissions for all selected pages to View (read only).
 * Remove - removes all selected pages from the restricted user's whitelist

New Whitelist Pages
This table contains a textbox which can be used to add new wiki pages to the restricted user's whitelist access. The entries are all treated as wiki titles (both articles and categories, both existent and nonexistent) and are parsed as one title per line. It is also possible to use the % or the * character as a whildcard when entering new pages.

Once all new pages are defined, the manager needs to define what kind of access to give to the restricted user for all of these pages. The manager can define: Once the pages and the action are defined, the manager needs to click on the Process button.
 * Expiry Date - defines when the restricted user's access to all of the newly defined pages will expire. Remember, the manager can enter the date either with the JavaScript calendar by clicking on the Expiry Date link, or they can leave it blank to make the access never expire.
 * Set to View or Set to Edit - defines whether the access type for all newly defined pages should be View or Edit.

The wildcard feature should be used with caution because it may open up access to more pages than what is truly needed. That is why upon pressing the Process button, the manager can review their submission and see the expanded list of current pages that match the wildcard pattern. There are a couple of caveats with the usage of wildcards:
 * 1) Currently, usage of wildcards on the Media and Special namespaces is not allowed.
 * 2) If the first character is a wildcard, then it is assumed that this pattern should match all namespaces
 * 3) If a page is whitelisted, then its sibling talk page is also whitelisted (and vice versa)
 * 4) if a page is whitelisted and it is a redirect to another page, that other page will also be whitelisted

Restricted User Usage: My Pages
As it was pointed out earlier, restricted users can find out which pages they are restricted to by clicking on their My Pages personal URL (typically in the upper right hand corner of every page). Clicking on this link actually takes them to Special:WhiteList page.



As can be seen above, the restricted users will see not only the pages that were explicitly whitelisted for them by a manager, but also whitelisted pages implicit in the extension (see Advanced Extension Configuration for details on configuring $wgWhiteListOverride). Additionally, restricted users can request access to more pages by filling out the form on the right which will send the selected manager an email notifying them of the request.

This page is effectively blocked for every non-restricted users because for them it does not make sense to see page restrictions since they are not restricted. However, non-restricted users may have a need to sometimes see which pages restricted users are allowed to see. To do so, non-restricted users can go do Special:WhiteList/userid where userid is the user ID of a restricted user. Note: this functionality is different than the one allotted for managers via Special:WhiteListEdit; managers can add/remove/change permissions for a restricted user's whitelist, whereas non-restricted users who are not managers can only view restricted user's whitelist.