User:Skizzerz/grouppermissions
From MediaWiki.org
Contents |
[edit] Actual
This is what has been actually accomplished so far). Note that this just means that I've coded it and such, it hasn't been committed to svn yet.
[edit] Stage 1
Note: some things from the envisioned stage 3 have been put onto this list, since the defaults don't change anything and many (non-wikimedia) wiki owners could benefit from such things.
- Add $wgRevokePermissions as a means of removing permissions from users belonging to specific user groups. The syntax is identical to $wgGroupPermissions, except that the function is the exact opposite :)
- Modify Special:ListGroupRights so that it displays revoked permissions as well (the display of assigned vs. revoked is changeable via css).
- Add APCOND_BLOCKED as a means to autopromote blocked users into specific groups (could be used in conjunction with $wgRevokePermissions to prevent blocked sysops from unblocking themselves, etc.).
- Modify Special:UserRights:
- Modify static HTML checkbox listing of groups into an associative array so that extensions may modify what groups are displayed/checked/irreversible/etc. via the new "UserrightsGroupCheckbox" hook. This hook could also be used to create entirely new columns in the display besides the normal "can be modified"/"cannot be modified" (e.g. a "global groups" column so that local and global groups for a user can all be modified via one form).
- New hook "UserrightsSaveUserGroups" to allow extensions last-minute changing of what groups are being assigned/revoked (e.g. if both local and global groups were placed on the Userrights form, this could ensure that global groups aren't assigned locally and vice versa).
[edit] Envisioned
This is my sandbox of sorts for toying around with various ideas to make MediaWiki's permissions system more granular.
- Stage 1 will focus primarily on editing permissions and permissions used to access administrative functions. These changes will benefit wikis that wish to restrict certain abilities such as the ability to edit and create discussion pages (e.g. if they have their own forums that they want to use instead of discussion pages). This stage will also completely separate the edit and create rights, so that one would be able to create new pages but not edit existing ones.
- Stage 2 will focus primarily on reading permissions. These changes will benefit wikis that wish to keep their page source secret, or that wish to restrict access to default special pages that they feel are inappropriate for anonymous visitors to see. This stage will not be started until stage 1 is completed with positive feedback and the changes mentioned in stage 2 are approved by the head developers (brion, Tim Starling, etc.), since reading restrictions can be viewed as "anti-wiki"
- Stage 3 will focus primarily on a backend redesign. This will move group permission assignments into the database so that they can be extended functionality-wise (e.g. the ability to assign permissions to individual users as well as groups, the ability to inherit permissions from other groups, and the ability to revoke assigned permissions (effectively making a "blocked users" group possible). This stage is beyond the initial scope of the project on my todo list and will require careful consideration and testing before implementation.
[edit] Stage 1
- If edit is a global toggle for all editing permissions, change that behavior so that it isn't.
- Add edittalk right to branch of editing article spaces and talk spaces (like how createpage and createtalk are separated).
- Change functionality of edit so that it only allows editing of article spaces (leaving editing of talk spaces up to edittalk).
- more? Please leave ideas on my talk page.
