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.
I’m going to go further than @BenRomberg 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.
Hi! @remie , @BenRomberg - 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.
Just an update on the above @remie@BenRomberg 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
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.
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.
@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 )
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.
We’ve also added the option to filter the results by status category: TODO , IN_PROGRESS , DONE .
Now, I would also like to hear from you. The Status API, as it is now, and what we already have - does it satisfy the needs for your apps? Are we missing any use cases that may be blocking your development? Please let us know!
Thanks!
Glad to hear that it will be reflected in the documentation as intended.
)