Content
View differences
Updated by Alexander Coles about 1 month ago
**As** a developer or automation using the `op` CLI
**I want to** create, update, inspect and link work packages in a single invocation with all fields set
**so that** I can script ticket-filing, triage and reporting workflows end-to-end without falling back to the web UI or the raw API.
## Acceptance criteria
* `op create workpackage` accepts flags for the full set of fields a user would normally fill in: `--parent`, `--description` (string or `@file`), `--assignee`, `--status`, `--version`, `--category`, `--relates-to` / `--blocks` / `--duplicates`.
* `op update workpackage` accepts the same set, so bare tickets created earlier can be fully populated in one batch.
* `op create workpackage --from-file tickets.yaml` (or similar) creates multiple work packages from a structured file, with templated fields and per-ticket overrides.
* Attachments can be ingested from a URL, not only a local file path (`op update workpackage --attach-url <url>`). Accepts URLs that require Bearer auth.
* `op inspect workpackage` can print the full rendered body, parent, children and relations — not just the summary. A machine-readable form is available via `--json` on every `inspect` and `list` subcommand.
* Project-level commands accept the friendly identifier (`op inspect project communicator-stream`), not only the numeric id.
* `op search` supports `workpackage` and `project` subcommands, at least by subject / identifier.
## Technical notes
* The gap I ran into most often: every ticket needed parent + description + screenshot attachments set after creation, because `op create workpackage` only supports `[subject] -p -t`. Filing 8 related follow-up tickets took 8 supervised rounds instead of one scripted loop.
* `op inspect project communicator-stream` today errors with _"invalid project id. Must be a number"_, which contradicts the product's own move toward semantic identifiers.
## Permissions and visibility
- * Users continue to see and can only create work packages they already have permission for — the expanded flags don't don't introduce new permission surface.
-
* No change on instances that don't don't have semantic identifiers enabled.
## Translations
- * No user-facing strings — CLI-only.
## Out of scope
* A general-purpose scripting DSL. The ask is for one-shot, flag-driven invocations. Pipeline / query composition is a separate thread.
* Changes to the REST API. All of the above can be built on top of existing endpoints.
**I want to** create, update, inspect and link work packages in a single invocation with all fields set
**so that** I can script ticket-filing, triage and reporting workflows end-to-end without falling back to the web UI or the raw API.
##
* `op create workpackage` accepts flags for the full set of fields a user would normally fill in: `--parent`, `--description` (string or `@file`), `--assignee`, `--status`, `--version`, `--category`, `--relates-to` / `--blocks` / `--duplicates`.
* `op update workpackage` accepts the same set, so bare tickets created earlier can be fully populated in one batch.
* `op create workpackage --from-file tickets.yaml` (or similar) creates multiple work packages from a structured file, with templated fields and per-ticket overrides.
* Attachments can be ingested from a URL, not only a local file path (`op update workpackage --attach-url <url>`). Accepts URLs that require Bearer auth.
* `op inspect workpackage` can print the full rendered body, parent, children and relations — not just the summary. A machine-readable form is available via `--json` on every `inspect` and `list` subcommand.
* Project-level commands accept the friendly identifier (`op inspect project communicator-stream`), not only the numeric id.
* `op search` supports `workpackage` and `project` subcommands, at least by subject / identifier.
## Technical notes
* The gap I ran into most often: every ticket needed parent + description + screenshot attachments set after creation, because `op create workpackage` only supports `[subject] -p -t`. Filing 8 related follow-up tickets took 8 supervised rounds instead of one scripted loop.
* `op inspect project communicator-stream` today errors with _"invalid project id. Must be a number"_, which contradicts the product's own move toward semantic identifiers.
##
-
-
*
-
## Out of scope
* A general-purpose scripting DSL. The ask is for one-shot, flag-driven invocations. Pipeline / query composition is a separate thread.
* Changes to the REST API. All of the above can be built on top of existing endpoints.