Atlassian CLI - "acli jira workitem edit" cannot set custom fields, unlike "create"

[Warren_ Jodi]

Note: These ticket contents were written by AI, but I experienced the problem as a human and couldn't find my own workaround.

Summary

acli jira workitem create --from-json accepts custom field values via the additionalAttributes key, and this works correctly. The equivalent acli jira workitem edit --from-json rejects every shape of custom-field payload I have tried, making it impossible to update custom fields on existing tickets via acli. This forces users to fall back to the web UI or to call the REST API directly with curl, defeating the purpose of having a CLI for scripted ticket maintenance.

Expected behaviour

acli jira workitem edit --from-json <payload> should accept the same additionalAttributes shape as create --from-json, allowing custom field values (e.g. Acceptance Criteria, Story Points, Epic Link) to be updated on existing work items.

Actual behaviour

The Go JSON decoder rejects custom-field payloads with json: unknown field "<key>". The advertised edit schema (visible via acli jira workitem edit --generate-json) is a strict subset of the create schema and contains only:

• issues
• summary
• type
• description
• assignee
• labelsToAdd
• labelsToRemove

Steps to reproduce

1. Create a Jira Cloud work item that has a populated custom field (for example an ADF doc in customfield_NNNNN).
2. Attempt to update that custom field via acli edit --from-json. Every wrapper I tried fails the same way:

1. additionalAttributes (works on create, fails on edit)

$ cat payload-1.json
{
  "issues": ["ABC-12345"],
  "additionalAttributes": {
    "customfield_12345": { "type": "doc", "version": 1, "content": [ ... ] }
  }
}
$ acli jira workitem edit --from-json payload-1.json --yes
✗ Error: json: unknown field "additionalAttributes"

2. customfield_NNNNN at the top level

$ cat payload-2.json
{
  "issues": ["ABC-12345"],
  "customfield_12345": { "type": "doc", "version": 1, "content": [ ... ] }
}
$ acli jira workitem edit --from-json payload-2.json --yes
✗ Error: json: unknown field "customfield_10966"

3. fields wrapper (the underlying REST API shape)

$ cat payload-3.json
{
  "issues": ["ABC-12345"],
  "fields": {
    "customfield_12345": { "type": "doc", "version": 1, "content": [ ... ] }
  }
}
$ acli jira workitem edit --from-json payload-3.json --yes
✗ Error: json: unknown field "fields"

4. customFields wrapper

$ cat payload-4.json
{
  "issues": ["ABC-12345"],
  "customFields": {
    "customfield_12345": { "type": "doc", "version": 1, "content": [ ... ] }
  }
}
$ acli jira workitem edit --from-json payload-4.json --yes
✗ Error: json: unknown field "customFields"

5. Human-readable field name

$ cat payload-5.json
{
  "issues": ["ABC-12345"],
  "Acceptance Criteria": { "type": "doc", "version": 1, "content": [ ... ] }
}
$ acli jira workitem edit --from-json payload-5.json --yes
✗ Error: json: unknown field "Acceptance Criteria"

For comparison, create --from-json accepts the additionalAttributes shape from payload 1 without issue, and the resulting ticket renders the custom field correctly. The same JSON, sent to edit, is rejected outright by the strict decoder.

Impact

This blocks any automated workflow that needs to amend custom-field values on existing tickets — common cases include:

• Updating Acceptance Criteria after a planning conversation
• Adjusting Story Points after sizing
• Setting or changing an Epic Link
• Any project-specific custom field maintained from CI The Jira REST API PUT /rest/api/3/issue/{key}handles this with {"fields": {...}} — so this is purely an acli wrapper gap, not a Jira capability gap.

Suggested fix

Extend the edit --from-json decoder to accept additionalAttributes (matching the create schema) and pass its contents through to the underlying PUT /rest/api/3/issue/{key} call's fields object. Updating acli jira workitem edit --generate-json to include additionalAttributes in the template would also help discoverability.

Workarounds currently in use

• Web UI editing for one-off updates.
• Raw curl against PUT /rest/api/3/issue/{key} with the API token from the macOS Keychain entry acli(base64-encoded with a go-keyring-base64: prefix).
• Delete and re-create the ticket via create --from-json — loses the key, only viable for tickets with no comments, links, or watchers.

Environment

Field	Value
acli version	acli version 1.3.18-stable
OS	macOS (darwin)
Site	Jira Cloud
Authentication	API token stored via acli jira auth login (macOS Keychain, acli service)