All abilities require the capability returned by LH_Tasks_task_post_type_class::return_required_capability() (default edit_others_posts, filterable via lh_tasks_return_required_capability). This applies uniformly regardless of a task’s assigned_to/assignee; assignment is enforced as an additional identity check inside claim-next-task, complete-task, fail-task, reassign-task and renew-claim, not as a substitute for this capability gate. edit-task is the sole unconditional override.
From 1.12.0 each ability is its own class under includes/abilities/, extending LH_Tasks_ability_base, and LH_Tasks_abilities_class (includes/lh-tasks-abilities-class.php) registers the category and loads them when the Abilities API asks. The base class builds every registration, so an ability cannot leave out its annotations or output schema, closes every input (unknown parameters are rejected), and ends each description with a permission sentence generated from the same method check_permission() enforces, so the documented capability cannot drift from the enforced one. Shared schema pieces and format_task(), the shape returned by get-task and list-tasks, live on the base class, along with return_task_schema() (1.13.0), the typed schema of that shape, which is get-task‘s output schema and the item schema of list-tasks (1.17.1).
Workflow status inputs (edit-task‘s status and reassign-task‘s new_status) use status_property() (1.17.1), an enum of the keys from return_statuses(). edit_task() and reassign_task() store whatever status they are given, so the schema enum is what stops a mistyped key reaching the status table; PHP callers of those methods must pass a real key themselves.
Task fields (1.14.0)
format_task() takes an optional list of field names and builds a task one field at a time through format_task_field(), in schema order. With no list it returns every field, which is what get-task and claim-next-task use. With a list, only the lookups those fields need run: the Markdown conversion only for description_markdown, the status-table row only for status, assignee, assigned_to, retry_count and max_retries, get_waiting_on() only for is_blocked and waiting_on, and the term lookups only for queue, task_type and priority. return_task_fields() lists every field from return_task_schema(), so a new schema property becomes requestable automatically; format_task_field() also needs a case for it unless it is plain post meta.
Priority (1.15.0)
The priority input of create-task and update-task, and the priority filter of list-tasks, take their allowed values from LH_Tasks_priority_class::return_slugs() (low, normal, high, urgent). get-task and list-tasks return the task’s priority term slug, empty if it has none. The abilities are unchanged at the edges from when priority was post meta; see Architecture notes for the taxonomy.
list-tasks (1.13.0)
list-tasks builds one SQL query over the posts table, the status table, the due date meta and the dependency table, so every filter, sort and the total run in the database. Two pieces are shared rather than copied: whether a task is blocked comes from LH_Tasks_dependencies_class::return_unsatisfied_blockers_sql(), the same definition the claim query uses, and the priority rank comes from LH_Tasks_priority_class::return_rank_sql() (since 1.15.0, the order meta of the task’s priority term), which the claim query also orders by.
The default status group, open, is return_open_statuses(); terminal is return_terminal_statuses(). Deferred is in neither, so it only appears with status_group: all or when named. Dates in filters are site-local; created_after and updated_after are converted to GMT, and updated means the later of the post’s modified time and the status table’s updated_at, so a claim or status change counts as an update.
From 1.14.0 rows are compact by default (#150452): return_default_list_fields() gives task_id, title, status, queue, task_type, priority, due_date, assignee, assigned_to, is_blocked, waiting_on, source_plugin and source_post_id, so 20 rows come to about 6 KB instead of 100 KB or more. The fields input names any other fields (its enum is return_task_fields()), and task_id is always added. include_progress_log is kept as an alias that adds progress_log. Callers that need descriptions or payloads must ask for them in fields, or use get-task.
