SOIT v1.7.0

SOIT v1.7.0 Approval Assignment Release Notes

Status: released on 2026-10-03 as tag v1.7.0 (commit 6f66810); soit-cli 1.7.0 is on PyPI.

Highlights

• Approval requests name who decides them. A request can be assigned to
  members (assignee_user_ids) and workspace roles (assignee_roles: Owner,
  Admin or Dev); only those members, and the holders of those roles when the
  decision is taken, may approve or reject it. A member removed from the
  workspace or no longer holding the role can no longer decide. A request
  with no assignees keeps the rule so far: any member who can write decides.
  The requester and the workspace's Owners and Admins may still cancel.
• A ToolSpec's policy.approval takes approvers and timeout_seconds, so
  every request a tool opens, from an agent, a workflow node, a direct call or
  MCP, is assigned and has a deadline.
• Requests expire. A request nobody decided by its deadline closes as
  expired, which counts as a rejection everywhere: the call never runs.
  Nothing approves a request on its own.
• Approvers can delegate a request to another member who can decide, and
  every decision, closing and delegation is kept in the request's history
  (GET /api/v1/observe/approvals/{id}/decisions).
• A workflow run stopped for approval continues on the server once the request
  is decided, as the member who started it; nobody has to resume it by hand.
  It continues exactly once, however often the decision event arrives and
  whoever resumes it by hand at the same moment.
• Approval requests notify their approvers when opened, the new approver when
  delegated, and the requester when they expire, through members'
  notification preferences and the workspace's channels.
• Govern › Approvals shows each request's approvers and deadline, filters
  to the requests assigned to you, offers Approve and Reject only where you
  may decide, and opens a request's details, history, delegation and
  cancellation.
• Includes the v1.6.1 approval fixes. See Approvals.

Database Compatibility

• Fresh installations migrate from base to 20261003100000.
• One migration is added: 20261003100000 adds assignee_user_ids,
  assignee_roles and expires_at to approval_requests and the
  approval_decisions table. Existing requests stay unassigned and never
  expire.
• The supported N-1 upgrade range is 20260927160000..20261003100000: a
  v1.6.x database (20261002120000) upgrades in place.
• The migration has a downgrade. Downgrading to 20261002120000 drops the
  assignees, the deadlines and the whole decision history. Restoring the
  backup taken before the upgrade is the preferred way back.

Upgrading

1. Back up the database and object storage
   (backup and restore runbook).
2. Run alembic upgrade head (the compose migrate service does this), then
   restart the API, the workers and the web console on the new images. No
   setting is added; keep APPROVAL_SWEEPER_ENABLED=true on the API service,
   which now also expires overdue requests.
3. Behaviour changes to review:
   • A decision on a workflow approval resumes the run on the server. A
     client that resumes such runs itself may now get 409 because the run
     is already resuming; treat it as done.
   • Owners and Admins are notified of approval requests nobody is assigned
     to (category task); members can switch the category off in their
     notification preferences.
   • Approval responses carry can_decide, can_cancel and
     assigned_to_me, and approval events carry the request's requester,
     assignees and deadline; approval.delegated is a new event.
   • Once a ToolSpec declares approvers or timeout_seconds, earlier
     versions refuse it; do not roll back past v1.7.0 after using them.

Known Limitations

• Escalation to other approvers when a deadline passes, assigning requests by
  policy rule, and multi-step or quorum approvals are not included.
• Nobody is reminded before a request expires; its requester is told after.
• A workspace cannot yet forbid members from approving their own requests.
• A direct tool call or MCP call still runs only when its caller sends it
  again after the decision.
• A workflow run whose starter left the workspace waits for a resume by hand.
• The known limitations of v1.6.0 still apply, except where the changelog
  lists them as fixed.