Permissions

Permissions control who can see OrbitalWP tasks and what they can do with them.

The easiest way to understand the system is:

Roles set a user’s normal global access.
User-specific overrides record intentional exceptions for one person.
Ownership and assignment provide limited access in the context of a task.
Task-specific Permission Overrides grant access to one task tree (a task tree is the parent and all subtasks).
Approved task protections can still lock an action when a task is approved.

Access layer	What it answers
Role permissions	What can this user normally do throughout OrbitalWP?
User-specific overrides	What should be different for this particular user?
Ownership	Did the user author this task?
Assignment	Is the user responsible for this task or one of its ancestors?
Task-specific overrides	Was the user granted access to this particular task tree?
Approved task protections	Is this action currently locked by approval rules?

Role and user permissions are global. Ownership, assignment, task overrides, and approval locks are evaluated in the context of the task being used.

How This Fits In OrbitalWP

OrbitalWP permissions are task-focused. They do not simply decide whether someone is an administrator, manager, assignee, or viewer. Instead, OrbitalWP checks what the current user is allowed to do with the current task, field, page, or report.

That means two users can open the same task and see different controls. One user may be able to view the task only. Another may be able to edit dates and priority. Another may be able to approve the task or change its assignee. An assignee may be able to complete assigned work without having broad edit access to every task field.

Permissions also affect what appears in task views. Board View, List View, Timeline View, and Calendar View use task access before showing task data. If a user cannot read a task, that task should not appear for that user in those views.

Where To Find It

Administrators manage global permissions from the WordPress admin menu under Orbital > Permission Settings. The page has a Roles mode and a Users mode.

Use Roles to configure permissions for each non-administrator WordPress role.
Use Users to configure User-Specific Permission Overrides for individual users.
Use Users with Overrides to review users who already have user-specific permission changes.

Administrators can also manage access for a single task tree from the Permission Overrides box on the task edit screen. This box appears on saved top-level root tasks. Descendants inherit their overrides from the root and cannot own separate override rows.

Related access settings live under Orbital > Plugin Settings. In the General tab, the Access Control card contains Approved Task Protection and the Lock Approved Tasks checkbox. In the Notifications tab, Email Settings controls whether task emails can be sent.

Permission-related reports are available from Orbital > Reports when the current user can access reports. The Reports page heading is Task Reports, and the report selector can include Permission Overrides and Permission Access Inspector.

Before You Start

You need administrator access to open Permission Settings and manage task-specific Permission Overrides.
The administrator role is not listed with the other roles on Permission Settings because administrators always have all OrbitalWP global permissions.
Role permissions from every WordPress role assigned to a user are combined before user-specific overrides are applied.
User-specific overrides can grant a global permission or deny a global permission that the user would otherwise receive from their roles.
Task-specific overrides grant access to one root task and its descendants. They do not change the user’s global role permissions.
Task-specific overrides can only be set after a task has been created. If the task is new, save it first and refresh the edit screen.
Assignment is not the same as edit access. Being assigned can provide task visibility and completion access, but it does not automatically allow editing every field.

What You Can Do

Choose which roles can create, read, edit, approve, assign, delete, receive observer notifications, manage task taxonomy, or view reports.
Give one user custom global permissions without changing everyone who shares that user’s roles.
Deny a role-inherited permission for one user when that user needs narrower access.
Grant one user access to a specific task tree without changing their global permissions.
Allow a user to approve, close, assign, edit, read, or delete tasks in one specific task tree through task-specific overrides.
Review permission-related configuration and diagnostics from reports when report access is available.

Basic Workflow

Open Orbital > Permission Settings.
Select Roles and choose the role you want to configure.
Review the permission groups: Read Permissions, Edit Permissions, Special Permissions, and Feature Access.
Use the checkboxes to choose the role’s default access.
Use Summary if you want to preview the active permissions for that role.
Click Save Permissions.
If one user needs different access from their roles, switch to Users, use Select User, adjust the checkboxes, and click Save Permissions.
If one task tree needs an exception, open its saved root task in the task editor, find Permission Overrides, search to add a user, and toggle the task-specific permissions for that user.

How Global Permissions Are Combined

For anyone who is not an administrator, OrbitalWP calculates global permissions in this order:

It combines the OrbitalWP permissions from every WordPress role assigned to the user.
It applies any user-specific grants or denials.
It adds lower-level permissions included by the grants that remain.
It treats explicit user denials as final for those global permissions.
It removes any special permission whose required base permission is missing.

This preserves independent access. For example:

If Edit All Tasks is the only reason a user can read every task, denying Edit All Tasks removes that included read access.
If the user’s roles separately grant Edit All Tasks and Read All Tasks, denying only Edit All Tasks leaves Read All Tasks in place.
If Read All Tasks is explicitly denied for the user, that denial wins even when another permission would normally include it.

Administrators always have all OrbitalWP global permissions. User-specific overrides cannot narrow administrator authority.

Configure these permissions through Orbital > Permission Settings. Similarly named WordPress capabilities added by another plugin do not replace OrbitalWP’s configured role permissions.

Role Permissions

Role permissions are the normal global permissions for users in a WordPress role. If a user has multiple roles, OrbitalWP combines the permissions from all of them.

Permission	What it allows	Important limits
Create and Edit Own Tasks	Create tasks, edit tasks authored by the user, and create subtasks when the user can edit the proposed parent.	Does not allow changing approval, closed, or assignee fields.
Read All Tasks	Read every task without general editing rights.	Does not allow editing task fields.
Edit All Tasks	Edit ordinary fields on every task.	Does not include approval, closed, assignee, or deletion authority.
Approve Tasks	Change approval and closed status.	Requires Edit All Tasks. It does not grant edit access by itself.
Manage Assignees	Change task assignments.	Requires Edit All Tasks. It does not grant edit access by itself.
Delete Tasks	Trash or permanently delete tasks.	Requires Edit All Tasks. It does not grant edit access by itself.
Receive Notifications	Makes the user eligible for observer notifications on tasks they can already read.	Does not grant task access or guarantee that an email will be sent.
Manage Task Taxonomy	Create and manage task categories and tags.	Requires Create and Edit Own Tasks. Edit All Tasks also satisfies this requirement.
View Reports	Open the Reports screen.	Report results remain limited to tasks the user can access, and some reports may remain administrator-only.

Included Permissions Versus Required Permissions

These are different kinds of relationships.

Edit All Tasks includes Read All Tasks and Create and Edit Own Tasks. Create and Edit Own Tasks includes the supporting ability to read authored tasks and create subtasks where the parent can be edited.

Special permissions work in the opposite direction:

Special permission	Required permission
Approve Tasks	Edit All Tasks
Manage Assignees	Edit All Tasks
Delete Tasks	Edit All Tasks
Manage Task Taxonomy	Create and Edit Own Tasks

A required permission is not automatically granted by the special permission.

In Roles mode, OrbitalWP keeps selected permissions and their requirements together. In Users mode, OrbitalWP rejects contradictory changes and explains which required permission must be selected—or which dependent permission must be cleared. An explicit denial is never silently changed into a grant.

User-Specific Permission Overrides

User-specific overrides are global exceptions for one user. They are calculated against the combined baseline from every WordPress role assigned to that person.

The Permission Summary separates three different ideas:

From Roles shows the resolved permission baseline supplied by all the user’s roles.
Custom Overrides shows intentional user-specific permissions marked Granted or Denied.
Effective Permissions shows the final global result after role permissions, overrides, included permissions, explicit denials, and requirements are resolved.

A checked box does not necessarily represent a custom grant. It may already be checked because the permission comes from the user’s role baseline.

OrbitalWP stores only intentional differences:

Checking something the roles do not provide creates a positive user override.
Unchecking something the roles provide creates a negative user override.
Leaving the checkbox equal to the role baseline creates no override.

Saving without changing anything creates no custom permission rows. This means later role changes continue to affect the user unless an intentional user exception applies.

If a user has multiple roles, permissions from all those roles are combined. Removing a role recalculates the baseline, while meaningful user-specific exceptions remain in place.

The Users controls have distinct meanings:

Select All prepares all configurable global permissions for the user. Click Save Permissions to save.
Clear All prepares the user to have none of the configurable global permissions, including permissions otherwise inherited or calculated from the role baseline. Click Save Permissions to save.
Delete Override removes all custom grants and denials and immediately returns the user to their current role baseline.
Summary opens or closes the Permission Summary.
Save Permissions saves the selected user’s intentional exceptions.

Clear All and Delete Override are not the same. Use Clear All to deny the role baseline for that user. Use Delete Override to remove the exceptions and follow the roles again.

Assignment or a task-specific grant may still let a user reach particular tasks after their global permissions are cleared.

Task-Specific Permission Overrides

Task-specific overrides are administrator-granted permissions for one root task and every descendant beneath it.

Task override	Effect on that task tree
Read	Read the task and its descendants.
Edit	Read and edit ordinary task fields.
Approve	Change approval or closed state; also includes Edit and Read.
Manage Assignee	Change assignments; also includes Edit and Read.
Delete	Delete tasks; also includes Edit and Read.

These overrides are grant-only:

They cannot deny access the user already has.
They are stored on the top-level root task.
Descendants inherit them from that root.
Subtasks cannot own separate override rows.
Removing an override does not remove access supplied by roles, user permissions, ownership, or assignment.
A global user denial does not cancel an explicit grant for one task tree.
Access to one task tree does not grant broad access to other tasks, private collections, or new top-level task creation.

Global Approve Tasks, Manage Assignees, and Delete Tasks remain addon permissions requiring Edit All Tasks. Their similarly named task overrides are intentionally stronger for that one task tree because they include enough Read and Edit access to operate it.

Permission Override changes save automatically after an administrator toggles a task-specific permission.

Assignment Access

Ownership and assignment are different.

Ownership means the user authored the task. Create and Edit Own Tasks follows authorship, not assignment.

Assignment provides narrow task access:

A direct assignee can read the task and change its completed state.
Assignment to a parent or ancestor extends that read and completion access down through descendants.
Assignment does not flow upward. Assignment to a child does not reveal an otherwise unreadable parent.
Assignment alone does not permit changes to title, description, priority, dates, percent complete, custom fields, post status, approval, closed state, or assignee.
Approved-task protection can block completion changes for an assigned user.

Field-Level Restrictions

Some fields have stricter rules than general task editing. A user may be able to edit a task and still be unable to change one of these fields.

Approval status requires Approve Tasks or a task-specific Approve override.
Closed status requires Approve Tasks or a task-specific Approve override.
Assignee changes require Manage Assignees or a task-specific Manage Assignee override.
Completion can be changed by users with task edit access and by assigned users when the task is not locked.
User-created custom fields follow ordinary task edit access unless the field is one of the restricted workflow fields above.

Approval status appears on parent tasks, not subtasks. If a task is a subtask, approval controls are not shown for that subtask.

Approved Task Protection

Approved Task Protection is controlled from Orbital > Plugin Settings > General in the Access Control card. The setting label is Lock Approved Tasks.

When Lock Approved Tasks is enabled, approved tasks are protected from ordinary edits. Users without approval authority cannot edit approved tasks. Completion and percent complete controls may also show a lock. If a task or parent task is locked because it is approved, change the approval status first before trying to edit completion or progress.

Approved parent tasks can also lock completion and progress changes on descendant tasks. This prevents users from changing the progress of work that belongs under an approved parent until the parent approval status changes.

Important Controls And Settings

In Roles mode, Select All checks every configurable permission for the current role.
In Roles mode, Clear All removes the permission selections for the current role.
Reset to Default restores the default permissions for a role.
In Users mode, Select All prepares all configurable global permissions for the selected user. Click Save Permissions to save.
In Users mode, Clear All prepares denials that remove the selected user’s configurable global permissions, including permissions supplied by the role baseline. Click Save Permissions to save.
Delete Override immediately removes a user’s custom grants and denials so the user follows their current role baseline again.
Summary opens or closes the permission preview for the current role or selected user.
Save Permissions saves changes on the Permission Settings page.
Search to add a user… is used inside a root task’s Permission Overrides box to add a user to that task tree.
Permission Overrides task changes save automatically after you toggle a permission.

Clear All and Delete Override have different results in Users mode. Clear All creates user-specific denials. Delete Override removes those exceptions.

What Affects What You See

Different users can see different OrbitalWP menus, tasks, fields, reports, and controls. The result depends on several access layers.

Administrators can open Permission Settings and always have all OrbitalWP global permissions.
Users with global task permissions, accessible authored or assigned tasks, or task-specific overrides can see the Orbital admin menu.
The Permission Settings submenu is for administrators.
The Reports submenu appears for administrators and users with View Reports.
Task views show only tasks the user can read.
Read-only access can show task data without showing edit controls.
Task filters and closed-task preferences can hide tasks even when the user has permission to read them.
Timeline View and Calendar View depend on task dates, so tasks without dates may not appear there even if they appear in Board View or List View.
Approved Task Protection can lock completion and progress controls even when a user normally has edit access.

Permissions And Notifications

Receive Notifications does not give a user permission to read tasks. It only allows a readable-task observer to be considered for email notifications.

Even when a user has Receive Notifications, OrbitalWP still checks whether the user can read the task before rendering task email content. Emails can also be stopped by Enable Email Notifications, the individual Notification Types settings, Notify on Own Actions, Mute all notifications for my account, per-task mute state, or a missing email address.

On a task, the Notifications section can show Active or Muted when notifications are enabled. Muting a task affects that user’s task notifications without changing task permissions.

Deeper Notes

Global special permissions and task-specific overrides behave differently. Approve Tasks, Manage Assignees, and Delete Tasks are global addon permissions. They require Edit All Tasks and do not grant broad edit access by themselves. Task-specific Approve, Manage Assignee, and Delete overrides are stronger for one task tree because they include enough Read and Edit access to reach and operate those tasks.

Manage Task Taxonomy requires Create and Edit Own Tasks. Edit All Tasks includes Create and Edit Own Tasks, so it also satisfies that requirement.

Edit Own permissions are based on task authorship. If a user can edit their own tasks, that does not mean they can edit a task authored by someone else unless another access layer grants it.

Task-specific Read, Edit, Approve, Manage Assignee, and Delete overrides inherit from a root task to every descendant in its task tree. Set them on the root task when you want them to apply throughout that tree.

Report counts can differ between users because report queries respect task permissions. A user who can see fewer tasks may also see different report totals than an administrator.

Common Problems

I Cannot See Permission Settings

Permission Settings is an administrator-only area. Ask an administrator to open Orbital > Permission Settings and check your role or user-specific override.

Clear All Did Not Restore The User’s Role Permissions

Clear All creates the denials needed to clear the user’s effective global permissions. Use Delete Override when you want the user to follow their roles again.

A User Still Sees One Task After Clear All

Check whether the user owns the task, is assigned to it or an ancestor, or has a task-specific Permission Override. Those task-contextual access sources are separate from global user permissions.

Save Permissions Says One Permission Requires Another

Select the named required permission or clear the dependent permission, then save again. OrbitalWP will not turn an explicit denial into a grant.

A Checked Permission Appears Under From Roles Instead Of Custom Overrides

The permission is inherited from one or more of the user’s roles. Unchecking it creates a user-specific denial.

A Role Change Affected Several Users

That is expected. Role permissions form the baseline for every user assigned to that role. User-specific exceptions are applied afterward.

A User Cannot See The Orbital Menu

The user needs some form of OrbitalWP task access. Check whether the user has a role permission, a user-specific permission override, an accessible authored or assigned task, or a task-specific override.

A Task Is Missing From A View

First check read access. The task must be readable by the current user through global permissions, own-task access for its author, assignment, or a task-specific override. Then check filters, closed-task preferences, and whether the view requires dates. Timeline View and Calendar View need dates; Board View and List View can still show tasks without dates.

A User Can View A Task But Cannot Edit It

The user may have Read All Tasks, a Read task-specific override, or assignment access. Those can allow visibility without broad edit rights. Check whether the user has Create and Edit Own Tasks, Edit All Tasks, a task-specific Edit override, or authorship of the task when own-task access is being used.

A User Can Edit A Task But Cannot Change Approval, Closed, Or Assignee

Those are restricted workflow fields. Approval status and closed status require Approve Tasks or a task-specific Approve override. Assignee changes require Manage Assignees or a task-specific Manage Assignee override.

A Completion Or Progress Field Is Locked

The task or one of its parent tasks may be approved while Lock Approved Tasks is enabled. Change the approval status first, or ask someone with approval authority to review the task.

I Cannot Add Permission Overrides On A Subtask

Subtasks inherit task-specific overrides from their root task. Open the root task and use Permission Overrides there.

The Permission Overrides Box Says To Save The Task First

Task-specific overrides can only be set after the task exists. Save the task, refresh the edit screen, and then add the user in Permission Overrides.

Removing A Task Override Did Not Remove Access

The user may still have access through a role, a user-specific global grant, ownership, or assignment. Task overrides only add access; they cannot block another source.

A User Does Not Receive A Notification Email

Check task read access first. Then check Orbital > Plugin Settings > Notifications for Enable Email Notifications, the relevant Notification Types setting, Notify on Own Actions, Mute all notifications for my account, and whether the task itself is Muted for that user. Also confirm the user has a valid email address.

Reports Are Missing Or Counts Look Different

The user needs View Reports to access the Reports screen unless they are an administrator. Report results can also be permission-scoped, so a user with narrower task access may see different totals than an administrator.