opschain admin jsm-requests
integrations:jira-service-management
Read and write Jira Service Management requests through the integration's single audited write door: every JSM write OpsChain makes goes through these verbs, is project-scope checked, and lands as an event on the audit spine.
Comments are always posted as JSM internal notes — there is
deliberately no customer-visible-comment capability anywhere on this
surface, so a drafted customer reply can only ever land as an internal
note a human reviews and posts as themselves. Resolution is
evidence-linked: resolve records the typed jsm:request reference on
the resolving change, posts the internal evidence comment and performs
the resolving transition.
| Subcommand | Purpose |
|---|---|
links | The jsm:request / jira:issue typed references recorded on governance metadata blocks (only subjects you may read). |
comment <request-key> | Post an internal note. |
transition <request-key> <transition> | Move a request through a workflow transition. |
set-fields <request-key> | Add/remove labels and set issue fields. |
resolve <request-key> | Evidence-linked resolution. |
Each write verb requires an updatable determination on its own rule
path under /admin (/admin/integrations/jsm/requests/comment,
…/transition, …/fields, …/resolve — a plain /admin rule covers
them all by prefix; a rule on one path grants exactly that verb) plus
the integrations:jira-service-management entitlement; links serves
any caller, filtered to the subjects they may read. Exit codes: 0 on
success, 1 when a call fails, 2 for usage errors.
See also
opschain docs integrations-jsm— the whole integration.opschain docs cli/approvals-set-metadata— recording references by hand.