I run this command:
acli jira workitem view <KEY> --fields '*all' --json
But the `transitions` property of the returned json object is null, even though I can confirm that it should have some transitions.
My understanding is that this is a bug, but I can't report it because in the contact page (https://support.atlassian.com/contact), when it asks "What is your URL?" and I enter mine, I get the "Sorry, we can't find this Cloud URL." error and I don't have any option to submit the bug.
Hi Adrian,
The null there isn't really a bug - it's that transitions aren't a field, they're an "expand" on the issue resource. So --fields '*all' will never populate them, because *all only pulls fields, and the available-transitions list is generated separately from the workflow based on the item's current status. That's why it comes back null even though "transitions" shows up on the issue object in the docs.
A few ways to actually get them:
The CLI-native route is the transition subcommand itself - it's built around the live transition list, so it's the intended way to see and use what's available from the current status rather than reading it off view:
acli jira workitem transition <KEY>
If you just want the raw data, the transitions live on their own sub-resource (this is what Enric pointed at):
GET /rest/api/3/issue/<KEY>/transitions
Or, if you'd rather get them inline with the rest of the issue in a single call, expand them instead of asking for them as a field:
GET /rest/api/3/issue/<KEY>?expand=transitions
and tack on expand=transitions.fields if you also want to see which fields each transition requires - each one comes back with a required: true/false, which is handy if you're going to script the transition afterwards.
One thing worth knowing either way: that list is both status- and permission-dependent. It only returns the transitions the authenticated user can actually perform from the item's current status, not every transition in the workflow - so if it looks shorter than you expected, that's usually why.
Hope that clears up the null!
You said this:
> A few ways to actually get them:
> The CLI-native route is the transition subcommand itself - it's built around the live transition list, so it's the intended way to see and use what's available from the current status rather than reading it off view:
But if I run the help of the transition command I get this:
```
$ acli jira workitem transition --help
Transitioning a work item can mean moving it to another status, or performing a looped transition where the transition allows you to perform an action but keep the work item in its current status.
Usage:
acli jira workitem transition [flags]
Examples:
# Transition work item with work item keys
$ acli jira workitem transition --key "KEY-1,KEY-2" --status "Done"
# Transition work item with JQL query
$ acli jira workitem transition --jql "project = TEAM" --status "In Progress"
# Transition work item with filter ID
$ acli jira workitem transition --filter 10001 --status "To Do" --yes
Flags:
--filter string Filter ID of work items to be transitioned
-h, --help Show help for command
--ignore-errors Ignore the errors and continue
--jql string JQL query for work items to be transitioned
--json Generate a JSON output
-k, --key string A list of work item keys to be transitioned
-s, --status string Status to transition the work item
-y, --yes Confirm transition without prompting
```
Doesn't seem like I can use `acli jira workitem transition` to see the transitions. According to this, I can only use that command to transition one workitem to a different status, but I can't really see what statuses are available using just the cli, which is exactly the thing that I am actually complaining about.
On the other hand, thanks for letting me know that "transitions" being null isn't a bug. Is there any way to control the "expands" with the cli by any chance?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Not via acli, no. workitem view only takes -f/--fields (plus --json and --web), there's no --expand equivalent, so the CLI can't surface expand-only data like transitions, changelog or renderedFields. For those you'd hit the REST resource directly, e.g.
GET /rest/api/3/issue/<KEY>?expand=transitions,changelog
You can still use acli to grab the key and curl the rest, but the expand itself has to go through the API.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I just created a feature request for this: https://jira.atlassian.com/browse/JIRAAUTOSERVER-1225
Thank you very much
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You're right, my bad. acli's transition command runs a transition, it doesn't list them, and view won't expand them either, so there's no acli flag that shows them. Quickest path is to hit the endpoint directly: GET /rest/api/3/issue/<KEY>/transitions (curl -u email:token). Same list, scoped to what you can actually do from the item's current status.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear @Adrian Cuadrado Chavarria
Atlassian documents --fields "*all" for acli jira workitem view, but transitions are normally fetched via Jira’s separate “Get transitions” REST endpoint, not as a normal issue field.
Use REST API as a workaround:
curl -s -u "$ATLASSIAN_EMAIL:$ATLASSIAN_API_TOKEN" "https://YOUR-SITE.atlassian.net/rest/api/3/issue/<KEY>/transitions"
Hope this helps
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That's exactly what I was doing precisely because I couldn't get the transitions. But what's even the point of returning the "transitions" property if it always comes null forcing us to use the rest endpoint? This should 100% be considered a bug, but I can't report it as such because of what I said about the contact page not detecting the cloud url.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
To report an issue, you need to have a paid subscription and you need to be in an admin role in the instance (project admin does not count in this case)
So if you are not an admin, ask one of your instance admin to raise the issue for you and share it with you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.