@prefix sioc: . @prefix dc: . @prefix dcterms: . @prefix xsd: . @prefix content: . @prefix rdf: . @prefix rdfs: . a sioc:Post ; dc:title "Staff controls in the UI" ; dcterms:identifier 153086 ; dc:modified "2026-11-01T16:32:08Z"^^xsd:dateTime ; dc:created "2026-11-01T16:32:08Z"^^xsd:dateTime ; sioc:link ; sioc:has_creator ; sioc:has_container ; content:encoded "

Since 1.29.0 (#153082) everything the edit-task ability does to a task’s workflow can be done in the UI too: MCP abilities are never the only route to an action. Both routes below go through LH_Tasks_task_actions_class::edit_task(), so the change is logged as an admin_override entry and fires the same actions as the ability. Both need the task capability (staff).

Block editor

The Task queue panel has a Change status control with every workflow status, a Release claim button while the task is claimed, and a Reset retries button once retries have been used, each with a way to undo before saving. Releasing the claim on a Claimed or In Progress task also sets it back to New. Changes save with Update, logged with the note “Changed in the block editor.”

They go through their own REST field, lh_tasks_workflow (status, claimed_by, retry_count; edit context, task capability), not lh_tasks. The block editor only sends fields that were edited, so a save that changes only the due date never carries a stale status back over a claim an agent made meanwhile. claimed_by and retry_count only ever release or reset: sending 0 clears them, and any other value changes nothing. Unknown statuses, and status changes on a task with no queue record, refuse the whole save. lh_tasks_info also returns statuses, the value and label pairs for the control.

Task page

  • Staff get a Staff form on every task: status, release the claim (naming who holds it), reset retries (showing how many are used), and an optional note that only staff see. A note on its own is added as an ordinary note.
  • On a master task’s checklist, staff get a Resolve button on each open subtask they cannot mark done themselves, such as a fee a captain has paid. It posts to the master’s page and comes back there, and the master resolves on its own when its last subtask is finished.

edit_task() changes

  • Refuses a status that is not in return_statuses() (lh_tasks_invalid_status), and a status or claim change on a task with no queue record (lh_tasks_no_status_row). Before, PHP callers could store any key.
  • Logs to_assigned_to when the assignment changes and claim_released_from when a claim is released.
  • Fires lh_tasks_task_completed when it moves a task into Resolved or Closed from any other status, so follow-up reminders and notifications are cleared as on every other route to a finished task. Before, a staff resolve left them in place.

Other abilities

Review and add-note were already open to staff on the task page, and the editor’s Assigned to picker covers staff reassignment. Complete, fail, reassign and renew-claim are claim-holder actions for agents; staff reach the same end states with the status control.

"^^rdf:XMLLiteral ; sioc:content "Part of: LH TasksSince 1.29.0 (#153082) everything the edit-task ability does to a task’s workflow can be done in the UI too: MCP abilities are never the only route to an action. Both routes below go through LH_Tasks_task_actions_class::edit_task(), so the change is logged as an admin_override entry and fires the same actions as the ability. Both need the task capability (staff).Block editorThe Task queue panel has a Change status control with every workflow status, a Release claim button while the task is claimed, and a Reset retries button once retries have been used, each with a way to undo before saving. Releasing the claim on a Claimed or In Progress task also sets it back to New. Changes save with Update, logged with the note “Changed in the block editor.”They go through their own REST field, lh_tasks_workflow (status, claimed_by, retry_count; edit context, task capability), not lh_tasks. The block editor only sends fields that were edited, so a save that changes only the due date never carries a stale status back over a claim an agent made meanwhile. claimed_by and retry_count only ever release or reset: sending 0 clears them, and any other value changes nothing. Unknown statuses, and status changes on a task with no queue record, refuse the whole save. lh_tasks_info also returns statuses, the value and label pairs for the control.Task pageStaff get a Staff form on every task: status, release the claim (naming who holds it), reset retries (showing how many are used), and an optional note that only staff see. A note on its own is added as an ordinary note.On a master task’s checklist, staff get a Resolve button on each open subtask they cannot mark done themselves, such as a fee a captain has paid. It posts to the master’s page and comes back there, and the master resolves on its own when its last subtask is finished.edit_task() changesRefuses a status that is not in return_statuses() (lh_tasks_invalid_status), and a status or claim change on a task with no queue record (lh_tasks_no_status_row). Before, PHP callers could store any key.Logs to_assigned_to when the assignment changes and claim_released_from when a claim is released.Fires lh_tasks_task_completed when it moves a task into Resolved or Closed from any other status, so follow-up reminders and notifications are cleared as on every other route to a finished task. Before, a staff resolve left them in place.Other abilitiesReview and add-note were already open to staff on the task page, and the editor’s Assigned to picker covers staff reassignment. Complete, fail, reassign and renew-claim are claim-holder actions for agents; staff reach the same end states with the status control." ; sioc:topic . rdfs:seeAlso . rdfs:seeAlso .