This post is a whinge. I wish that issue type schemes were exposed via JIRA’s REST API, and I know that Atlassian doesn’t intend to provide that. (also here)
My add-on creates an issue type, and I’d love to be able to add that new issue type to particular projects. Since there’s no REST API for that, I have to carefully instruct the user to do it themselves, and it’s a royal pain in the proverbial.
I’m after your empathy, people. Smother me with love.
I’d love to know more about why some of these decisions not to implement REST APIs have been made.
Atlassian have been pushing Cloud for a while now, but trying to develop anything like the P2 add-ons we (and customers) are used to is, well, impossible without a more complete API.
I can appreciate that Atlassian might not be willing to share all their internal decision making with us, but the responses you’ve linked to just feed developer and customer frustration that we can’t make JIRA do what we’d like to.
Is anyone aware of a roadmap for Cloud? So we know which features we’ll never be able to build for our add-ons?
Hi guys,
Thanks for your feedback. I have been blessed to have been put in charge of the roadmaps for both the JIRA Cloud ecosystem/APIs and our roadmap for project configuration in JIRA Cloud.
We are actively working on major changes to project configuration – issue types, workflows, screens, fields, permissions, etc. This is cited by users as the biggest source of complexity in JIRA.
Introducing new public APIs for many of the schemes would hinder our ability to make improvements and lock us into the existing project configuration model, which we know to be too complex for most users to understand. Certainly, the reason why an add-on wants these APIs to begin with is to make changes to configuration automatically so you don’t have to rely on users to do it.
We are planning to introduce a new simpler API-driven model for project configuration that will support both a new UI and a more straightforward REST API. We will absolutely share more details as soon as possible – we are trying to unravel some of the oldest, most intricate code in JIRA.
At a higher level, we recognize that there are some types of plugins that were quite common in P2 that we either can’t or won’t build APIs to support as add-ons with Atlassian Connect in JIRA. We are working on both clarifying our roadmap and investments for JIRA Cloud for add-on developers over the next year and how we will communicate them. We will certainly share updates on the developer community site here, and if you’re coming to AtlasCamp in Barcelona, I’ll be speaking on these topics as well.
Cheers,
Dave Meyer
Senior Product Manager, JIRA
I’m definitively in the “I’ve got an addon that I want to port but can’t without this” camp(I don’t think I can get further into the camp - I’m probably the flag holder).
That said if you look at how Atlassian Connect is designed it’s all around the fact that Addons shouldn’t be able to do evil things (shouldn’t is the keyword here). I totally and understand this(and if you’ve explored at the API around Issue Type scheme switching in p2 you’d appreciate this).
I’m hoping that as any new api’s are designed/reworked that (both p2 and AC) they make sure that I can’t break them. So I’m hoping that there isn’t a 1:1 mapping from java API to rest APIs.
Just my $0.02
Thanks Dave, that’s a great response - I look forward to hearing more at AtlasCamp 
I understand, redesigning is hard, but we can’t just wait for a years. We need to get all project transitions per status [JRACLOUD-67784] Whitelist Workflow Rest API - Create and track feature requests for Atlassian products.
Could you please provide us with workaround?
Any progress on this?
We need to edit issue types of projects from the API in Jira Cloud
Hi @jpardobl and @dzagorovsky,
My comments from a year ago are still accurate. Major changes to the data model behind Jira project configuration are complex and take singificant time. The first step in our progress towards a new model (which will eventually provide new public APIs) are independent projects that can be created with the new Agility project template. We will add more configuration capabilities and APIs to independent projects in the future.
Regards,
Dave Meyer