pub const ISSUE_TRANSITION: &str = "\
Move an issue through a workflow transition.
```
ytcli issue transition PROJ-1
ytcli issue transition PROJ-1 close
ytcli issue transition PROJ-1 closed # the status; the id is found
ytcli issue transition PROJ-1 close --resolution fixed
ytcli issue transition PROJ-1 close -r wontFix --set comment=\"not this quarter\"
ytcli issue transition PROJ-1 PROJ-2 --to close -r fixed --yes
```
Without an id it lists what is available from the current status, which is the
only reliable way to learn the ids: they are defined per workflow, not globally.
A target status is accepted where an id is — `closed` as well as `close`, by key
or by the name Tracker displays. The id is tried first, so the ordinary call is
still one request; only when that fails is the workflow asked what reaches that
status. The id that worked is what gets printed, so the next call can skip the
second request.
A transition can require fields, and closing usually requires a resolution:
without one Tracker refuses with the names of the fields it wanted, in the
organisation's own language. `--resolution` is the one everybody needs;
`--set key=value` covers the rest, and takes field keys the way `issue update`
does — `ytcli dict list --kind resolutions` names the resolutions, and
`ytcli queue fields PROJ` the rest.
More than one issue takes the same workflow step in one request, and needs
`--yes` and `--to`: with a list of keys there is no unambiguous place left for a
bare transition id. The answer is `changed N of M` plus the id of the change,
and a reason for every issue whose workflow refused the step — an issue that was
not in a status the transition starts from is one of them, so a partial tally
here is ordinary rather than a fault.";