Allow granular permissions to be defined and assigned to roles.

Security will be implemented two-fold, firstly the User and Admin values in the status field on users will now be used for determining if a user is currently active or not. These checks will be done before applying roles to the current user.

The next stage is every page will implicitly require permissions at an action level. These permissions will mostly be defined implicitly, such as PageWelcomeTemplate/create, and as such don't need to be declared or tested by the page.

InternalPageBase will still handle the actual security barrier and displaying this to the user, but only in the capacity of implementing the decision. SecurityManager will be responsible for making the decision.

Identification checking will be done on a role-by-role basis. If a role requires (or rather, is not exempt) from identification checks, it won't be considered by SecurityManager in the list of rights granted to a user, unless the check is a rejection, in which case it will be considered to see if the user would have had that right to choose a more correct error condition (not allowed vs not identified)

User changes

• The user status column values will be replaced with "Active".
• The checkuser column will also be dropped.

Roles

Roles are to be defined in a single place, probably a static class called RoleConfiguration.

• Create three roles - user, admin and checkuser. Assign rights approximately as they are defined currently, skipping duplicated rights as needed, such that a checkuser access is distinct from tool admin, but such that they can perform the tasks they need to
• Role allocation to users will be done by a new database table storing a unique set of user IDs and role names. Table to be managed using the standard DataObject infrastructure.
• Migrate all users to relevant roles including log entries. This will probably require a PHP migration script rather than a SQL one. It can still tie in to the schemaversion stuff though, to ensure stuff is run in the correct order.
• Add new special role which (like public) is applied automatically to every single logged-in user. Every other role should be limited to "Active" users only

Page access control

• Kill off getSecurityConfiguration().
• Modify InternalPageBase to pass authorisation requests to a helper class.
• Create some way for pages to explicitly skip all access checks (so you don't get access denied errors because you're not logged in while loading the login form...). This is to only be used for "critical" pages that break the tool if they're forbidden at any time, such as the login form.
• Implement some explicit rights check barrier that pages can use for determining user access, similar to barrierTest in cases such as displaying an edit button vs a view button
• Kill off barrierTest() accesses from templates. This was a bad idea when I wrote it.

Security manager

Rough process will be:

1. Request received by security manager for rights check
2. Security manager requests roles for user.
3. Check identification status of user
4. Split roles user has by ($roleRequiresIdentification && $userIdentified || !$roleRequiresIdentification)
5. Cache steps 2 through 4.
6. Take first pile of roles and check the requested right exists in the set. If so, return success.
7. Take the second pile of roles and check the requested right exists in the set. If so, return ERR_NOT_IDENTIFIED.
8. Return general failure.

• Implement it
• Unit test the hell out of this.
• Caching (check performance when not remote)

Registration

• Generalise the registration form, so different instances can assign users to a different initial role.
• Figure out the UX for getting to the right signup form. Perhaps a pre-signup step along the lines of a wizard?

User management

• The standard promote/demote workflow actions are now not applicable. We need a way of granting/removing roles from users. Special:GroupPermissions is probably going to be the inspiration for this.
• Think of a way to stop tool admins granting themselves checkuser access. Probably something similar to $wgAddGroups defined in RoleConfiguration
• Adapt the user status buttons as applicable - probably won't need many changes. Remember this is on both the StatsUsers detail and the main usermanagement page.
• Show the roles a user is in somehow

Misc

• Update documentation
• Deprecate User::isCheckuser()
• Deprecate User::isAdmin()
• Deprecate User::isUser()

Todo checklist for various things

barrierTest Shenanigans

• main-with-data.tpl looks at a setBan barrier test, this needs to be ripped out, should be easy
• RequestData does a barrier test to check private data access. This must be moved, and is probably hard to deal with, as it makes assumptions that the reserving user is allowed private data access.
• templates/welcome-template/list.tpl
• templates/bans/banlist.tpl
• templates/email-management/main.tpl
• templates/email-management/template-table.tpl

Other assorted crap

• Comment::getForRequest() is flawed.
• Admin-only comments should probably be renamed.
• StatsInactiveUsers is causing problems
• PageUserManagement should show checkusers
• StatsUsers should show checkusers
• Make the navigation menu smarter - respect rights
• Figure out where the buttons on StatsUsers/detail went to
• User::getAllUsernames