Roles and permissions
This document describes how ProjectWikit decides what somebody may do: roles, the permission list, per-category overrides, the sanctions a site can put on a member, and which powers belong to the whole instance rather than to one site. The screens that hold these settings are described in Site administration.
ProjectWikit splits permissions down to single tasks, and each admin screen answers to its own permission. You can give a role only the Tickets permissions and let it enter the admin panel, which makes posts such as "ticket reviewer" or "application reviewer": people who handle their own kind of work without holding the whole admin panel.
The model
One ProjectWikit instance serves one or more sites.
- An account belongs to the instance. The same account signs in on every site of the instance, and its name, display name, email address and profile are the same everywhere.
- A role belongs to one site. Holding a role on one site grants nothing on another.
- Permissions come from roles. An account's permissions on a site are worked out from the roles it holds there.
- A superuser is above all of this. An active superuser has every permission on every site of the instance and cannot be sanctioned.
Every site has two built-in roles that are never assigned by hand:
| Role | Held by |
|---|---|
everyone | Everyone, signed in or not |
registered | Every signed-in account |
The roles an account is given on a site come on top of those two.
Sites created with pwikit createsite also start with two ordinary roles, admin and member, which can be changed or deleted; see Site administration.
What a role holds
Each role holds one decision per permission:
| Value | Meaning |
|---|---|
| Allow | The role grants the permission |
| Deny | The role refuses the permission, and the refusal wins over any grant |
| Inherit | The role says nothing; other roles decide. When none of the account's roles allows it, the account does not have the permission |
NoteInherit and Deny both leave a permission ungranted, but they work very differently. Inherit means the role says nothing: if any other role the member holds, including
everyoneandregistered, allows the permission, the member has it. Deny overrides every allow: if any role the member holds denies a permission, the member does not have it, whatever the other roles say.When a role should simply not give a permission, use Inherit. Setting Deny on
everyoneorregisteredtakes the permission away from everyone except superusers.
A role also carries:
- Can enter the admin panel: whether the role opens the admin panel at all. The screens inside it still need their own permissions.
- Rank: a number that decides who may edit whom. An account may only edit accounts whose number is larger than its own. Superusers may edit anyone.
How a decision is made
For one account, on one site, about one page or forum object, in this order:
- A deactivated account has no permissions, not even reading.
- An active superuser has every permission. Nothing below applies.
- The grants of every role held are added together. A permission granted by any role is granted.
- Category overrides replace what a role says for the category the page is in. See below.
- Every refusal is applied. If any role refuses a permission, or a category override refuses it for a role the account holds, the account does not have it — even if another role grants it.
- Object rules apply. Locked pages and threads, authorship and hidden forum sections adjust the result; see Locks, authors and the forum.
- An unverified email address removes the write permissions when the site requires verification. See Registration and accounts.
- The site's sanctions are applied last. See Sanctions.
Category overrides
Every page category can override what one role says, for pages in that category and their comment threads only. Overrides are set on the Page categories screen of the admin panel and cover only the page and forum permissions; every other permission is always decided for the whole site. Entries set to Allow or Deny replace the role's own value for those permissions; entries left on Inherit keep it.
Typical uses:
- A
sandboxcategory whereregisteredis allowed Create pages and Edit pages. - An
admincategory whereeveryoneandregisteredare denied View pages, so only roles that allow it there can read those pages.
An override cannot bring back a permission that another role refuses: step 5 runs after the override. To grant a permission in one category only, make sure no role the account holds refuses it.
Locks, authors and the forum
| Situation | Effect |
|---|---|
| Page is locked | Without Lock pages, an account loses Edit pages, Edit page tags, Move pages, Manage page files, Delete pages and Manage page authors on that page |
| Account is an author of an unlocked page | Gains Manage page authors on that page. A locked page gives authors nothing extra |
| Account started the thread | May edit that thread |
| Account wrote the post | May edit its own post while it may create forum posts on the site |
| Thread is locked | Without Lock forum threads, an account cannot comment, reply, edit or delete posts, or edit, pin or move the thread |
| Account's forum access is off through Forum active or Forum inactive until | The same restrictions as a locked thread, in every thread |
| Section is Staff only | Needs View hidden forum sections to be seen |
The permission list
Permissions are grouped as Pages, Forum, Social, Tickets, Member actions and Admin panel. Two of the groups are worth reading before the rest:
- Member actions decides what an administrator may do to a member of this site. Each sanction below has its own permission, so "may silence" and "may ban" are given separately.
- Admin panel decides which screens open at all. Holding Manage users opens the member list and member pages; acting on a member still needs a permission from Member actions.
The matrix shows each permission's label and code.
| Permission | Code | Allows |
|---|---|---|
| Pages | ||
| View pages | view_articles | Reading pages |
| Rate pages | rate_articles | Rating pages |
| Create pages | create_articles | Creating pages |
| Edit pages | edit_articles | Editing source, title and parent page, reverting; opens the Pages screen |
| Edit page tags | tag_articles | Changing a page's tags |
| Move pages | move_articles | Renaming and moving pages |
| Lock pages | lock_articles | Locking and unlocking pages, and keeping all rights on locked pages |
| Manage page files | manage_article_files | Uploading, renaming and deleting attachments |
| Delete pages | delete_articles | Deleting pages |
| Reset page ratings | reset_article_votes | Clearing all votes of a page |
| Comment on pages | comment_articles | Posting page comments |
| View page comments | view_article_comments | Reading page comments |
| Manage page authors | manage_article_authors | Changing a page's authors, together with Edit pages |
| Forum | ||
| View forum posts | view_forum_posts | Reading posts |
| Create forum posts | create_forum_posts | Replying in threads |
| Edit forum posts | edit_forum_posts | Editing anyone's posts |
| Delete forum posts | delete_forum_posts | Deleting posts |
| View forum threads | view_forum_threads | Reading threads |
| Create forum threads | create_forum_threads | Starting threads |
| Edit forum threads | edit_forum_threads | Changing any thread's title and description |
| Pin forum threads | pin_forum_threads | Pinning threads |
| Lock forum threads | lock_forum_threads | Locking threads, and posting in locked threads |
| Move forum threads | move_forum_threads | Moving threads to another category |
| View forum sections | view_forum_sections | Seeing sections |
| View hidden forum sections | view_hidden_forum_sections | Seeing sections marked Staff only |
| View forum categories | view_forum_categories | Seeing forum categories |
| Social | ||
| Send private messages | send_direct_message | Sending private messages |
| Tickets | ||
| View user reports | view_user_reports | The User reports screen |
| View user tickets | view_user_tickets | The Support tickets screen |
| Review membership applications | review_membership_applications | The Membership applications screen |
| Member actions | ||
| Ban members | ban_members | Banning a member from this site |
| Silence members | mute_members | Silencing a member on this site |
| Restrict member editing | restrict_member_editing | Taking page editing away from a member on this site |
| Restrict member rating | restrict_member_rating | Taking rating away from a member on this site |
| Reset member ratings | reset_member_votes | Clearing the votes a member cast on this site |
| Invite members | invite_members | Creating accounts, invite links, claim links and account activation |
| Manage bot accounts | manage_bots | Creating bot accounts |
| Admin panel | ||
| Manage users | manage_users | Opening the Users and Invite links screens, and member pages |
| Manage roles | manage_roles | The Roles and Role categories screens |
| Manage site | manage_site | The Site settings and Themes screens |
| View admin log | view_actions_log | The Admin log screen and the dashboard's recent actions |
| Manage categories | manage_categories | The Page categories screen |
| Manage tags | manage_tags | The Tags and Tag categories screens |
| Manage forum | manage_forum | The three forum screens |
| View sensitive information | view_sensitive_info | Account email addresses |
| View vote times | view_votes_timestamp | When each vote was cast, in rating details and account activity |
| Manage system updates | manage_updates | Nothing at present |
| Manage permission settings | manage_permissions | Permission matrices, category overrides, assigning roles, the role fields of the site settings, and the role granted on membership applications |
Sanctions
A sanction is what one site has taken away from one of its members. Sanctions are held per site: the same account can be banned on one site of the instance and untouched on another.
| Sanction | Takes away | Needs |
|---|---|---|
| Ban | Everything the other three take away | Ban members |
| Silence | Commenting, starting threads, replying, editing and deleting posts, editing, pinning and moving threads | Silence members |
| No editing | Creating, editing, tagging, moving, locking and deleting pages, managing attachments and authors, resetting votes | Restrict member editing |
| No rating | Rating pages | Restrict member rating |
Rules that hold for all of them:
- A sanctioned member can still read. Reading pages, comments and the forum is never taken away, and signing in still works.
- Private messages are never taken away, because they do not belong to one site.
- A sanction can be given an end time. It stops applying by itself when that time passes; the record stays visible in the member page. Leaving the time empty makes it last until somebody lifts it.
- A reason can be recorded with each sanction.
- Superusers cannot be sanctioned.
A sanction is set on the member page in the admin panel, in the Sanctions on this site section. Each sanction shows only to accounts holding the matching permission.
Site powers and instance powers
The account itself is shared by every site of the instance, so anything written on the account is reserved for superusers. A site administrator can act inside the site, and nowhere else.
| Action | Who | Reaches |
|---|---|---|
| Ban, silence, restrict editing or rating | A role holding the matching permission | This site |
| Clear the votes a member cast | Reset member ratings | This site |
| Assign roles | Manage permission settings | This site |
| Create accounts, invite links, claim links, bots | Invite members / Manage bot accounts | This site |
| Change a username, display name, profile text or email address | Superuser | The instance |
| Deactivate an account, so that it cannot sign in anywhere | Superuser | The instance |
| Turn the forum off for an account across the instance | Superuser | The instance |
| Take private messaging away from an account | Superuser | The instance |
| Grant or remove superuser | Superuser | The instance |
On a member page, an administrator who is not a superuser sees these account settings as text and cannot change them.
Differences from Wikidot
| Wikidot | ProjectWikit | |
|---|---|---|
| Who may do what | Fixed classes: anyone, members, moderators, administrators | Any number of roles, each holding a decision per permission |
| Permission detail | One setting per action per category | A separate permission per action, and a category may override any of them for any role |
| Several roles at once | A member is in one class | An account holds any number of roles; grants add up and any refusal wins |
| Banning | Blocks a member from the site | Four separate sanctions per site, each with an optional end time; the account itself is untouched |
| Account-wide action | Not applicable | Reserved for superusers |
| Where the settings live | Site Manager | The admin panel, described in Site administration |
Wikidot's per-category permission table has no direct equivalent, because a category override here names roles rather than classes. To reproduce a Wikidot setup, make one role for each class the wiki used and give the categories overrides for those roles.