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)

[Ben Spillane]

Hi Warren_ Jodi,

My assessment is the behaviour your seeing is a current gap in the acli wrapper for "edit work item".

To add weight to this theory you can run the commands: 

• acli jira workitem create --generate-json
• acli jira workitem edit --generate-json

You will see the supported json shape includes additionalAttributes in create but not in edit.

I would be inclined to raise a support ticket with Atlassian to confirm.

Regards,

Ben

[Warren_ Jodi]

@Ben Spillane Thank you for checking too, it's exactly what I found.

Do you know the best way to create tickets or raise tickets for acli? I don't seem to be able to do so on https://support.atlassian.com/contact/.

[Ben Spillane]

Hi @Warren_ Jodi  did you manage to find an avenue for raising a ticket?

You're required to be signed in to log tickets. Also the support options available are based on the app subscription level. For example, I know some free-tier subscriptions have fewer support options than paid plans.

I hope this helps.

Ben

[Warren_ Jodi]

@Ben Spillane Unfortunately not. It turns out that you need to be an admin to raise tickets with Atlassian if you're on a paid tier, so I'm going through the very laborious process of asking several different people at my org to raise this one by one. I suspect it won't be raised as it's not important from their POV.