User:X!/URS

This is a planning and information page for Unblock Request System (URS).

Mission
The mission of URS is to provide an organized, intuitive interface for blocked users to discuss terms of their unblock in private with trusted administrators.

Users
There are 4 types of users of URS. These are not mutually exclusive, so one user can be classified in two or more types of users.


 * 1) Blocked users - users who are requesting an unblock. They want to access the frontend for requesting and negotiating their unblock, as well as 1 part of the api for an RSS feed.
 * 2) Wikipedia administrators - administrators on Wikipedia who negotiate and unblock users. They want to access the frontend for discussing and closing requests, as well as preferences for their user account on the tool.
 * 3) Tool administrators - Users who have higher rights on the tool than the Wikipedia administrators. They have access to the backend, used for administrating users, approving admins, and other maintenance tasks.
 * 4) IRC Bot - A bot that hangs out in the unblock channel on IRC that would give status reports when asked, or at a set interval. Interacts with the api application.

Applications
There are 3 types of applications in URS, each one aimed at a different user.


 * 1) API - The API is similar to the MediaWiki API (in fact, it uses the same code) in that it returns results in XML, JSON, PHP, YAML, etc formats that are generated by the backend. There are 3 possible uses for it, 2 are aimed at the IRC Bot, and 1 is at the blocked users.
 * 2) Backend - The backend is where the tool admins can administrate the workings of the tool. They can edit and delete requests, approve and block wiki admins, and edit the templates that users can use.
 * 3) Frontend - This is where the meat is. It is used by 2 users: the blocked users and the wiki admins. They blocked editors can post requests here, check the status, and post replies. The admins can view a list of requests, edit requests, reply, close requests, ban blocked editors, and change their account preferences.

Stories
Each application has several dedicated purposes. This describes all the features of each application.

Story A1: Get current requests
This module is secured with a username and password, which the bot must use to get the private list. The list provides a list of open requests, with information such as the IP, number of replies, etc. The bot can also refine this query by providing a limit of entries, by filtering IP, username, etc.

Story A2: Get a single request
This module provides similar info to A1, except that it only lists 1 certain entry, and it has the content of all the replies included with the info about the request. It is also secured with a username and password.

Story A3: RSS feed
Unlike this other stories, this is meant to be accessed by the blocked user with an RSS reader. It is not protected by a username and password, but rather by a token that they are given when they make the request. It is a feed of all the comments made on the request, and nothing else

Backend
All of these stories are meant to be accessed only with a username and password, so it is not mentioned individually in each description.

Story B1: An admin can edit and delete requests
The admin views a list of requests, and can both edit and delete them as needed.

Story B2: An admin can approve users
The admin views a list of users, which can be filtered to view only unapproved users. They then can approve the user to edit requests. Until then, the user cannot read requests or edit them until they are approved.

The approval process goes like this:


 * 1) User applies for an account
 * 2) User makes post on talk page confirming
 * 3) User verifies email address
 * 4) Admin approved once steps 2 and 3 are completed

Story B3: An admin can block abusive users
If necessary, to prevent abuse, an admin can block a user. They can provide a reason for the block, as well as an expiry.

Story FB1: Users can post a request
The user fills out a form with username or IP address, reason for unblock, email, etc. If a username is not given, it will use the users current IP address. If no block is found, on the username, IP, or an autoblock, it will reject the request. If no reason is given, it will reject the request. If the username/IP/email is blocked, it will reject the request.

Once the request is made, the user verifies their email with a confirm page (Story FB2), and it is then pushed live.

Story FB2: Users can confirm their email address
This is accessed only with a link in an email message. If the token provided matches the database, it approves the request and pushes it live out of the holding area. An email is then sent with a link to the request page (Story FB3), with a secret token that they can access it with.

Story FB3: User can check the status of their request
This area is protected by a token they the user is provided after verifying their email address. If they provide the right token, their request is shown. It shows all the block info, the username, and a list of public replies. They can see the admin that made each reply, timestamp, and content of the reply. The content is passed through the en.wikipedia parser, so it can use templates stored on enwiki, images hosted on commons, and all the wikimarkup on Wikipedia.

Story FB4: User can reply to their request
If a concern is made, they can make another comment to the request, just as admins are able to do.

Frontend (wiki admins)
This is all protected with a username and password, so it is not worth mentioning in each story.

Story FA1: An admin can view a list of requests
The admin can view all the currently open requests, which can be filtered by IP, date, number of replies, block type, status of request, etc. The list is paginated, so they can view up to ## request at a time before going to the next page.

Story FA2: An admin can view a request
Similar to story FB3, all the blockinfo is shown, the username, and the parsed replies.

Story FA3: The admin can reply to the request
There are two types of replies: public, and private. Public replies can be viewed by both the user and the admins, while private replies can only be viewed by the admins. It has a textbox for the content of the reply, as well as a dropdown for changing the status of the request (new, on hold, denied, accepted). This also provides for the ability to close a request, by choosing "denied" or "accepted". This does not remove the request from the main page, so other admins can review it. After 30 days, it is removed and archived automatically.

Story FA4: An admin can ban an IP, username, block ID, or email address
The admin can block a user, etc by visiting this module. They enter the user to be blocked, a time of expiry, and a reason.

Story FA5: sfDoctrineApplyPlugin pages
To handle the user administration, URS will be using the sfDoctrineApplyPlugin. This provides account application, email confirmation, user settings, etc. The details are not too important, because it's all in the README.