Hi developer community,
Jira Cloud Ecosystem team here with some updates on the extensibility work we’ve shipped since the last FY20 summary posted on CDAC in July. I’d also like to share what we’re working on and what the plans are for the near future. This is post #1 of a 3 part series with updates across Jira Cloud Ecosystem, Confluence Cloud Ecosystem, and Migrations Platform. Happy reading!
As a reminder, our priority here on the Ecosystem team is to unblock migrating customers by ensuring all critical server Marketplace apps are available in cloud, with a viable migration path. We rely on you, our developer community, to help shape our roadmap by submitting feature suggestions to highlight the extensibility gaps which are blocking you from delivering a cloud equivalent. I am happy to share the extensibility work we completed has contributed to 78 server apps released in cloud in the first half of Atlassian FY21, which is almost a 100% increase compared to H2FY20 .
Jira team has been working on project configuration APIs and Forge extensibility. Below you’ll find a number of new APIs and other improvements we’ve made in the last few months.
APIs shipped recently
The team has been busy with project configuration extensibility in Jira Cloud. Here’s a list of APIs we’ve shipped.
- Create issue type scheme
- Delete issue type scheme
- Update issue type scheme
- Add issue types to issue type scheme
- Delete issue type from issue type scheme
- Change order of issue types
API for workflow schemes management: Assign workflow scheme to project
APIs for screens management (announced in this December post on CDAC)
Screen schemes management
Issue type screen schemes management
- Create issue type screen scheme
- Delete issue type screen scheme
- Update issue type screen scheme
- Append mappings to issue type screen scheme
- Remove mappings from issue type screen scheme"
- Update issue type screen scheme default screen scheme
APIs for custom field options management
APIs to manage custom field options was one of the top asks from cloud app developers. Until now, we’ve offered a partial REST API. Now you can remove custom field options and manage non-default contexts. These APIs were also raised as a blocker for achieving feature parity between server apps and their cloud equivalents. Thanks for reaching out to us and helping to validate this need.
- Get custom field options (context)
- Update custom field options (context)
- Create custom field options (context)
- Reorder custom field options (context)
- Delete custom field options (context)
With the new APIs shipped, we’ve deprecated legacy APIs for custom field options, they will no longer be available starting from May 7, 2021. If you’re using the legacy APIs, please change your apps to use the new ones. The deprecated legacy APIs are:
- Get options for field (deprecated)
- Update custom field options (deprecated)
- Create custom field options (deprecated)
- Get custom field option (deprecated)
APIs for custom field context management
- Get custom field contexts
- Create custom field context
- Get issue types for custom field context
- Get custom field contexts for projects and issue types
- Get project mappings for custom field context
- Update custom field context
- Delete custom field context
- Add issue types to context
- Remove issue types from context
- Assign custom field context to projects
- Remove custom field context from projects
We’ve introduced webhook trace header to trace the origin of a webhook. For example, apps can use the webhook trace header to:
- differentiate between webhooks triggered by various REST API requests
- track a webhook’s delivery
- attach other data for use when a webhook arrives
We’ve updated our documentation on rate limiting in Jira and Confluence to help you anticipate rate limiting and manage your app response. We’ll soon be publishing updates on this topic to provide as much guidance as possible to assist app developers in handling app data migrations from server to cloud.
There is also a range of new content in the Atlassian Developer Guide including, but not limited to, an overview of differences between cloud, server, and Data Center apps and an overview of app hosting.
Jira Forge extension points
While our focus is on shipping new APIs for Connect, we also plan to have all of these APIs available in Forge. Forge is getting ready for general availability (mid-late February) and the team on Jira is making sure the extension points and the UX are in their final shape.
Among the new Forge capabilities in Jira you will find:
For more updates on Forge platform development, see the changelog.
What’s coming next?
ICYMI, you can watch cards on our Atlassian Platform Roadmap for Developers Trello board to see what we’re planning.
- Our team is currently working on APIs for Workflow management. For status notifications of this piece of work you can watch this card on the roadmap.
- Regarding issues beyond Workflow APIs, we currently work ACJIRA-2087 to allow fetching a list of Jira projects with a certain property set. We’re also investigating the possibility to register webhooks dynamically through REST API by 3LO apps (ACJIRA-1632).
- In the last extensibility recap post back in July, you’ve shared your need to open the Jira issue edit dialog from an app (ACJIRA-495). We’ve planned to work on this in February and March and expect to share some updates in a few weeks’ time.
In Forge, we are working on the global page extension for admins. Watch this card on our roadmap for updates. We’ll also add a new Datetime custom field. Next up, we are looking at Project page for end-users extension point and the possibility to create custom field types as a Forge app.
BTW, it’s great to hear that you are watching cards on the roadmap, thanks for the feedback!
You can check other public issues in the “Short Term Backlog” status here on ACJIRA. It is a new status on the ACJIRA project in ecosystem.atlassian.net to reflect issues we plan to work on in the near future.
Customer app migrations from server to cloud
We’ve welcomed many new cloud apps on the Marketplace this year, however, a number of your apps do not have migration path documentation available for customers in the Cloud Migration Assistants. When looking at customer usage of the app assessment functionality of our Cloud Migration Assistants, we’ve found that both availability of the app in cloud and documentation of the migration process (even if there is no need to migrate data) affects customers’ decisions to retain the app during the migration to cloud. If your app is available in both server and cloud, you need to take the following steps to make your migration path available to customers:
- Create and surface your migration path (and feature difference) documentation. For the link to be reflected in the Cloud Migration Assistant app, you need to update your migration path information adding the URL using this Marketplace API. If your app has no feature differences and/or does not require app data migration, please write documentation (like Balsamiq has done). This helps reassure customers that migration with your app won’t be a problem.
- Request to have your migration path featured in our public Knowledge Base article that is surfaced to customers and Atlassian Field teams who are assessing a migration to cloud. You can do so by submitting a request to Marketplace Support Team.
We want to hear from you!
We’re keen to know if you encounter any blockers when building apps for Jira Cloud.