Status Management API shipped to Jira Cloud

Hi developer community,

We would like to inform you about recent additions to our REST APIs.

We’ve added 5 new endpoints to manage statuses.

Bulk get statuses Bulk get statuses - Returns a list of the statuses specified by one or more status IDs.
Search statuses paginated - Returns a paginated list of statuses that match a search on name or project.
Bulk create statuses - Creates statuses for a global or project scope.
Bulk update statuses - Updates statuses by ID.
Bulk delete statuses - Deletes statuses by ID if they’re not being used.

In addition to that the GET APIs (“Bulk get statuses” and “Search Status Paginated”)
will have an expand option that will return the usages for these statuses (Project + IssueTypes).

You have any feedback or question for us, please leave us a comment below.

Thank you,
The Workflows Team.

4 Likes

Hello @LuisLainez,

Thanks for making these available!

The documentation says “Connect apps cannot access this REST resource” on each of them. Any plans to make them available for connect apps?

2 Likes

@LuisLainez ,

I’m going to go further than @ben2 and cordially request you to either immediately make these resources available for Atlassian Connect, or make a public statement that Connect is a deprecated platform.

It is completely, utterly, wholesomely unacceptable that Atlassian does not have the guts to own their decisions and threat their BILLION DOLLAR revenue generating Marketplace Partner community with blatant disrespect by simply letting the currently dominant platform for creating Cloud apps fade away in favour of a platform that has been prematurely announced GA for political reasons but is still years away from actually being able to cater complex apps.

Atlassian, do better!

CC: @Bentley @dmorrow @ibuchanan @msuntinger

18 Likes

Hi!
@remie , @ben2 - It was our intention to make it available for connect immediately from the get go and it is a mistake on the connect integration process.
We are going to solve it ASAP - apologies for the mistake and we will update the channel as soon as the documentation is updated.
The permissions for Connect for the GET requests are READ and the PUT/POST/DELETE ones is ADMIN.
Thanks for pointing it out,
Luis.

2 Likes

Just an update on the above @remie @ben2 and all.
The endpoints ARE available for Connect Apps - The problem is just a small hiccups with the extraction of Connect permissions by the docs. We are working to solve it so the docs reflect the Connect reality.
The permissions for Connect for the GET requests are READ and the PUT/POST/DELETE ones is ADMIN .
Apologies again for the scare!
Luis

8 Likes

Thanks a lot for checking @LuisLainez and sorry for the false alarm :slight_smile: Glad to hear that it will be reflected in the documentation as intended.

2 Likes

Lol: I just received feedback yesterday from a user that loves the app but wanted better functionality around statuses. I informed them this morning that the desired functionality didn’t exist. And just received an email this evening that Atlassian has released the endpoints for the desired functionality. Don’t know if Atlassian is spying on me or its just a coincidence. :crazy_face:

Either way, I’ll take it as an admin I am fully aware of the importance of this new functionality via the API. Kudos and thank you for the updates. :nerd_face:

3 Likes

@LuisLainez quick fyi, I am using the new “Search statuses paginated” and noticed that the total and maxResults are currently reversed.

  • Total is currently functioning as maxResults
  • maxResults is currently functioning as Total.

Not a big deal as I just reversed them in my code, but figured you all would want to know this for consistency with the other end-points in the API. :nerd_face:

I’ll keep an eye out for this fix so I can be sure to reverse it in my code as well.

4 Likes

@LuisLainez quick question regarding the deletion of a status. I have a user that tried to delete a status and received the following:

  • ERROR [400]: There was an error saving the workflows

I was able to reproduce this error by using a status in an inactive workflow, which makes sense. But currently, I can only tell the user if the status is used by a project or issue type, not if it’s used by a workflow.

Are there plans to provide this information under “expand=usages” area? That would be great as it would allow my app to inform the admins if they can/cannot delete the status and if not, which workflow to go to and remove before removing the status. I currently give them a list of projects where the status is being used—debating on listing out the issue types.

Thanks in advance for your awesome work (as well as your team :sunglasses:)

1 Like

Hey @LorenzoPhillips ,
Thanks for the feedback!
The pagination variables was actually a touchy subject, as in some endpoints they work as we’ve implemented it and in some others they way you did.
We figured that given the request, number of elements and links to next and previous pages all the information to navigate the pages was there.
But I will raise this again with the team and let you know if we change it.

As for the usages, you raise a valid point (inactive workflows). The status still won’t be deleted (as it’s used) but you have no way to know.
As the API is designed using expands, it’d be another expand.
Right now there is no immediate plan for it, but I’ll update you here if there is.
Thanks again for all you feedback, I’ll pass it on to the team!
Luis.