Skip to content

v0.3.13

Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 03 Oct 01:45
· 424 commits to main since this release

Added

  • Whoever wrote a task comment can change its text or delete it: POST /api/v2/tasks/{tid}/comments/{mid} and
    .../delete in the stable API, hub task comment-edit and hub task comment-delete, and MCP hub_task_comment_edit
    and hub_task_comment_delete. Neither wakes anyone. Deleted text is omitted from future supported reads, and
    the audit log keeps only change metadata. Copies already delivered to people, bots or external services remain. The task view shows "edited" beside an edited comment.
  • Service keys: a key another system, such as your product's backend, uses to file, update, close and reopen tasks,
    and nothing else. POST /api/v2/inbound/tasks takes the system's own key for each piece of work and makes one task
    match what it says now, so calls may come in any order and twice. The owner and the admins manage keys with
    hub service-key create|list|revoke (or /api/v2/service-keys); there is no Settings page for them yet
    (docs/service-keys.md).
  • Task types can let every bot comment and create subtasks (read), or also move, reassign and link tasks (work),
    through Settings → Types, the API, CLI and MCP. Ordinary company tasks are readable by default; these settings
    grant additional actions and never bypass a private task's participants.
  • A task can be renamed: title on POST /api/v2/tasks/{id}, hub_task_update and hub task update --title, for
    whoever may change its other fields. The new title gets the checks a new task's title would, is kept in the task's
    history, and becomes the subject of the task's own conversation.
  • Ticket numbers: a mover can make a custom type numbered, and each task created on it or moved onto it gets the
    team's next number (one sequence for the whole team), kept for good. A mover can keep an imported ticket's number
    (number on create, or once on a task that has none). #18945 names the task wherever an id does, and
    GET /api/v2/tasks?number=18945 finds it.
  • A task has a place within its step, step_rank: a task that enters a step joins its end (its top with top), and
    the people on it and movers can move it. GET /api/v2/tasks takes type and step filters and sort=step, the
    board filtered to a type orders its columns that way, and hub task list and hub_task_list take the same.
  • GET /api/v2/tasks?updated_since=<time> returns only the tasks changed after that time, for a client that polls, and
    brief=true leaves out their bodies and acceptance criteria.

Fixed

  • Completing a task keeps it Done, including self-requested bot tasks and recurring work. Closing is a separate decision; completed tasks no longer close automatically with age or when the next routine runs.
  • Tasks opened from a teammate page use the full shared task detail, including files, questions, comments and code links. On phones it fills the screen, and Back returns to the teammate page.
  • A task's updated time moves when a file is attached to it or archived, a link is removed, a linked pull request
    changes state, or a question on it is asked or answered, as it already did for its fields, comments and new links.

Changed

  • A task on a custom type is a ticket on that type's board, not an ask: the rule for a request to a person (a title
    that starts with a verb, the ask first, under 120 words) applies to General tasks only, in the API, MCP, hub and
    the dry run. A ticket still needs a title.
  • A bot's ticket on a custom type keeps its reference numbers and all-caps words: the plain-English title check
    applies to General tasks only.
  • Tickets on a numbered type stay out of their owner's Needs you, and the desktop count, unless one carries a question
    for that person; a declined ticket stays out of its requester's. General tasks and other types are listed as before.

Security

  • New ordinary tasks are readable by company people and bots. Private tasks limit future access to the requester and current assignee; bot defaults also protect requests assigned to sensitive bots. Existing known ordinary work remains visible; sensitive or ambiguous origins upgrade privately while retaining messages and attachments.