pub const ISSUE_UPDATE: &str = "\
Change fields of one or more issues.
```
ytcli issue update PROJ-1 --assignee login
ytcli issue update PROJ-1 --set storyPoints=3
ytcli issue update PROJ-1 PROJ-2 --set storyPoints=3 --yes
ytcli issue update PROJ-1 --set 'summary=\"3\"' --dry-run
ytcli issue update PROJ-1 --description-file ./body.md
```
`--description` replaces the description in full — Tracker keeps no history of
what was there — and takes `-` for stdin; `--description-file` reads it from a
file instead.
`--set` takes any field, custom ones included. A value that parses as JSON is
sent as JSON, so `--set storyPoints=3` sends the number 3. The cost of that
guess is that a summary which happens to look like a number becomes one, so
`key:=json` says it outright: `--set 'summary:=\"3\"'` writes the string, and
invalid JSON after `:=` is refused rather than quietly becoming text.
`ytcli queue fields PROJ` lists the keys.
More than one issue needs `--yes`: one issue is the ordinary case, several is
irreversible at scale.
Several keys are one request, not one each. Tracker checks the whole list before
it writes anything — an unknown key is refused, naming it, with nothing changed —
then applies the change in the background, and this waits for it. The answer is
a tally, `changed N of M`, and a line per issue that did not change with
Tracker's reason for each. The bulk change's id is printed either way; it is the
only handle on the work afterwards.
`--no-wait` prints that id and returns as soon as Tracker has accepted the
change. Success then means accepted, not done — `ytcli bulk status <id>` is how
you find out which.
Keys that resolve through two profiles in two organisations cannot be one
request, so those go one at a time, stopping at the first failure rather than
leaving you to work out how far it got. The tally is the same either way.
An update that would change nothing is refused rather than sent.";