OrbitalWP uses a two-layer permission system. The first layer assigns permissions to WordPress roles. The second layer grants permissions on individual tasks to specific users.
Quick Start Guide
- Go to Orbital → Settings → Permissions
- Select a WordPress role from the dropdown
- Check the permissions you want that role to have
- Click Save
How OrbitalWP Checks Permissions
When a user tries to view or edit a task by visiting the kanban, timeline/gantt chart or individual task edit screen, OrbitalWP checks permissions in this order:
- Admin check – Users with the WordPress
manage_optionscapability bypass all permission checks - Task-specific override – Checks if this user has been granted access to this specific task
- Role-based permission – Checks if the user’s role has the required permission
If any check passes, access is granted.
Role-Based Permissions
Permissions are assigned to WordPress roles, not individual users. When a user has multiple roles, they receive the combined permissions of all roles.
Core permissions:
| Permission | What it allows |
|---|---|
| Read Assigned Tasks | View tasks where you are the assignee. Can mark tasks complete in Kanban. |
| Create and Edit Own Tasks | Create tasks. Edit tasks where you are the author (the person who created the task). |
| Read All Tasks | View every task in the system. No editing. |
| Edit All Tasks | Edit any task regardless of who created it. |
| Approve Tasks | Change approval status and close tasks. |
| Manage Assignees | Assign tasks to other users. |
“Own” vs “All” permissions:
Permissions ending in “own” check whether you created the task. Permissions ending in “all” ignore who created it.
Example: Sarah has edit_own_tasks. She creates Task A and is assigned to Task B (created by someone else). Sarah can edit Task A because she created it. She cannot edit Task B – being assigned to a task is not the same as owning it. She can drag the task to the “Complete” lane in the kanban board.
Task-Specific Overrides
Admins can grant individual users access to specific tasks. This is useful when someone needs to work on a task but their role doesn’t normally allow it.
Overrides can only grant access. You cannot use overrides to remove access that a role provides.
To grant a task override:
- Open the task in the editor
- Find the Task Permissions metabox
- Select a user and the capability to grant (read, edit, approve, manage assignee, or delete)
- Click Grant
Field-Level Restrictions
Three fields require specific permissions regardless of general edit access:
| Field | Required Permission | What it controls |
|---|---|---|
| Approval Status | approve_tasks | Whether the task is pending, approved, rejected, or needs revision |
| Closed | approve_tasks | Whether the task is closed (archived) |
| Assignee | manage_assignees | Who is assigned to work on the task |
A user with edit_all_tasks can change task titles, descriptions, dates, priority, and custom fields. They cannot change approval status, close tasks, or reassign tasks unless they also have approve_tasks or manage_assignees.
Subtask Inheritance
Permissions flow down the task hierarchy. When you have access to a parent task, you automatically have the same access to all its subtasks.
This applies to both role-based permissions and task-specific overrides.
Example: Admin grants User A “edit” access to Task #100. User A can now edit Task #100 and every subtask underneath it, including subtasks of subtasks.
Important Details
Approvers need edit access too. The approve_tasks permission only unlocks the approval and closed fields. To actually open the task editor, users also need edit_all_tasks. Without it, they can see the task but not access the edit screen where the approval field lives.
Assignment is not ownership. Being assigned to a task does not make you the owner. Ownership is determined by who created the task (the post author in WordPress terms). This distinction matters for edit_own_tasks – you can only edit tasks you created, not tasks assigned to you.
Overrides check the root parent. When you access a subtask, the system looks up the hierarchy to find the top-level parent task and checks overrides there. You don’t need to grant access to every subtask individually.
Related Features
- Custom Fields – All custom fields follow the same edit permission rules
- Kanban Board – Displays only tasks the user has permission to view
- Reports – Access controlled by the separate
view_reportspermission