User:Prodego/URS

For the unblock request system

Internal

 * Webmail-esqe interface to facilitate discussion (Split screen)
 * Replies to and from user
 * Internal comments
 * Automatically detect autoblocks (ask X! for info on how to do this)
 * Show block meta data, as well as the request email
 * Per block stats (other requests from this email, this IP, this BLOCK (for range blocks)
 * Meta stats? [who's blocks are disputed the most?]
 * Banning of requests from IPs? Emails? Users? Blocks?
 * IRC reporting of new requests and changes of request states (i.e.: "closed > declined")
 * I've completed the IRC bot, so this is trivial to complete. ( X! ·  talk )  · @207  · 03:57, 6 August 2009 (UTC)
 * View all requests from a block, all requests from an email address, all requests from an IP...

Public

 * Ability to directly take block information from the block message (via URL parameters)
 * Ability to check that either the IP making the request or the username entered into the request form is indeed blocked before submitting the request.
 * Ensure that all needed info is present, and a unblock message is present
 * Confirm email address of requester
 * How to prevent abuse of this?
 * Identify the username of the person responding to the request
 * Ability to transfer "ticket"/"thread" to another responder?
 * Automatic notification e-mail to current responder on reply to thread/ticket?
 * Should the person automatically be asked to create an account? Only for anon-only IP blocks maybe?
 * Block identification from blockid
 * API and toolserver methods
 * Send blockid, and IP, and username automagically. Prodego  talk  23:10, 4 August 2009 (UTC)

User administration

 * Approval system for users
 * Data to store: username, email address(?), preferences(??)
 * Ability to rename users
 * Ability to suspend access
 * Changing password system:?

Queue administration

 * Allow for user creation of canned replies
 * Statuses of requests
 * Awaiting reply
 * Awaiting review
 * Closed
 * Account created
 * Block lifted
 * Declined
 * Sortable queue
 * Default: Requests awaiting review (oldest at top)
 * All open requests
 * All requests await reply
 * Archive of old requests?
 * Ability to merge new requests into existing threads
 * Automatic merge?
 * Ability to 'unmerge'?

Technical jargon

 * ✅ Implement Smarty to 1) allow translation, and 2) get rid of hacky echos, print_footers, and the message table.
 * Alternatively we could code a wfMsg like system ourselves rather than depending on a framework.
 * That is what my edit counter uses, and let me tell you, it's a little more difficult. If it wasn't already written and working just right, I would move it over. It's not the best of methods. ( X! ·  talk )  · @802  · 18:14, 4 August 2009 (UTC)
 * Done. I wrote my own alternative to Smarty, as Smarty is too complicated for our needs. The documentation for the replacement is at User:X!/PHPtemp. ( X! ·  talk )  · @185  · 03:26, 8 August 2009 (UTC)
 * Try to keep whole front-end (internal AND public) in a single index.php file that calls on classes which rather than spreading it out among many files like ACC does (which has index.php, acc.php, users.php, statistics.php, etc.).
 * Ensure that interface can be easily configured without issue for test installations and installs meant for wikis other than enwiki.
 * This means that there should be NO hardcoding whatsoever. Any variables that depend on the site should go on the Config.php.dist file.
 * Password reset system: Three fields: Current password, New password, Confirm New Password.
 * Email reset system: Ask for new email. Put current date into database. Put md5 string into database. Send user link with md5 string in it to confirm the new email. If confirmed after the date the user reset the email, it rejects the email. Otherwise, it changes the email in the database.
 * Classes to create:
 * Autoloader
 * Setup
 * Debug
 * index.php:
 * Define URS, so that only the main interface can be accessed
 * Include Config and Autoloader files
 * Create 3 instances of Database class: $wgDatabaseRead, $wgDatabaseWrite, $wgEnwikiDatabase
 * Load Setup class, which will get $_POST, $_GET, $_SESSION, and $_COOKIE variables; tell which class we want to load.
 * Follow through with the excecution
 * http://toolserver.org/~soxred93/ursdoc/
 * Coding conventions: /Conventions

Database Layout

 * ban (stores IP, Email, and Username bans)
 * ban_id (unique id)
 * ban_type
 * 0 = IP
 * 1 = Email
 * 2 = Username
 * ban_target (what is banned)
 * ban_user (The user who banned)
 * ban_timestamp
 * ban_reason
 * ban_expiry (when it expires)
 * ban_status (whether or not this ban is still in effect)
 * bot (stores commands)
 * bot_cmd (the commands the bot recieves in IRC)
 * bot_rights (what rights you must have to execute it, as an integer. See bot_rights table below)
 * bot_function (what function the bot executes)
 * bot_fork (whether or not it should fork)
 * bot_rights (stores user rights)
 * br_n!u@h (stores the user in N!U@H format)
 * br_nick (stores the nick)
 * br_uid (stores the user's userid on the tool)
 * br_rights (integer value)
 * 0 = no rights
 * 1 = admin
 * 2 = developer
 * 3 = root
 * bot_help_msg (stores bot help messages)
 * bhm_cmd (stores which command the help is for, same as bot_cmd above)
 * bhm_text (the actual text)
 * bhm_param (optional parameters)
 * bot_msg (stores the messages that the commands will say
 * bm_id (stores a unique ID)
 * bm_text
 * comments
 * com_id (unique ID of comment, allows hiding/deleting)
 * com_req (same as req_id)
 * com_user (user)
 * com_text (the actual comment)
 * com_timestamp
 * com_hidden (boolean value of whether or not the comment is hidden)
 * com_closed (whether or not this is a comment that was given for closure of a request)
 * com_result (see req_status below)
 * logging
 * request (the actual requests)
 * req_id (unique ID)
 * req_type
 * 0 = autoblock
 * 1 = direct user block
 * 2 = direct IP block
 * 3 = rangeblock
 * req_name (IP or username)
 * req_ip (IP that the user used to request unblocking)
 * req_email
 * req_email_date (date that email confirmation was sent)
 * req_email_code (secret code the user must enter)
 * req_status
 * 0 = awaiting email confirmation
 * 1 = open
 * 2 = closed, block lifted
 * 3 = closed, account created
 * 4 = closed, declined
 * req_reason (why the user thinks they should be unblocked)
 * req_assignee
 * req_block_id (the ID of the block)
 * user (Stores each tool user)
 * user_id (unique ID)
 * user_wiki_id (id on Wikipedia)
 * user_name (obvious)
 * user_password (Password, that is an md5 hash of - - )
 * user_email (Stores the current email address)
 * user_new_email (Stores the pending email address while it is being confirmed)
 * user_new_email_date (Stores the date that the email confirmation was sent)
 * user_new_email_code (Stores the secret code the user must enter)
 * user_registration (Date the person joined)
 * user_last_active (when the user was last active)
 * user_suspended (boolean value of whether the user is suspended)
 * user_approved (boolean value of whether the user is approved)
 * user_rights (integer value)
 * 0 = user
 * 1 = admin
 * user_preferences
 * up_user (user ID)
 * up_property (preference name)
 * up_value (preference value)
 * up_user (user ID)
 * up_property (preference name)
 * up_value (preference value)