Preparing for Jira 10.1
This documentation is intended for Jira developers who want to ensure that their existing apps are compatible with Jira Software Data Center 10.1 and Jira Service Management Data Center 10.1.
Starting from Jira 10.1, we've moved the communication about Jira Software Data Center and Jira Service Management Data Center development releases to this page. With this transition, we aim to provide partners and developers with a single source of information about improvements and changes to our products.
You can continue using the Atlassian Developer community for discussion and support. For archive release announcements, check out our changelog.
Latest version
Here you can find information about the latest EAPs.
Application | Date | Number | Version (Maven) | Downloads |
|---|---|---|---|---|
Jira Software |
| 10.1.0-EAP02 | 10.1.0-m0003 | |
Jira Service Management |
| 10.1.0-EAP02 | 10.1.0-m0003 |
Summary of changes
This section provides an overview of the changes we intend to make so that you can start thinking about their impact on your apps. Once the updates are ready, we'll indicate when they’ve been implemented and in which milestone.
Jira Software and Jira Service Management common features
Webhooks auditing
Status: IMPLEMENTED (EAP 02)
We’re adding three new auditing events to the audit service’s jira.webhooks.auditing.category category and with the event type WEBHOOK:
jira.webhooks.auditing.webhook.addedjira.webhooks.auditing.webhook.modifiedjira.webhooks.auditing.webhook.deleted
This event will include:
- The
idof the webhook being altered as part of the affected object - The webhook
uri - The values that have been changed, if relevant
Share usage data
Status: IMPLEMENTED (EAP 01)
We’re introducing a new way of sharing instance usage data with us. Now, the Analytics feature is called Usage data sharing and gives you more control of what you share with us.
If you decide to share the usage data of your instance, we’ll start collecting aggregated and de-identified data that we’ll use to improve the performance and scalability of our products. This knowledge will also help us communicate more effectively during a security incident, ensuring we can provide targeted advice and updates to secure your data. At the same time, we don’t collect content from within your instance.
Automation rule validation
Status: IMPLEMENTED (EAP 01)
We’re now indicating if there are any configuration errors when you open an existing rule. This helps to identify and fix rule configuration before publishing.
New login experience with two-step verification
Status: IN PROGRESS (EAP 01)
This feature isn’t for production use. Make sure to only test it on isolated instances.
To improve the security of the Jira login experience, we’re working on a solution that provides a second authentication layer. The new login process supports a built-in two-step verification (2SV) capability using a time-based one-time password (TOTP) generated by an authentication app as a second factor.
While we’re still working on this feature, you can test the changes and validate them with your integrations. To enable the new login experience, set the JVM system property -Datlassian.authentication.legacy.mode=true to false.
Check out our recent Atlassian developer changelog entry and explore how to manage two-step verification.
Upgraded dependencies
Status: IMPLEMENTED (EAP 01)
We've upgraded several first- and third-party dependencies.
Jira Service Management features
Streamline your request intake process
Status: IMPLEMENTED (EAP 02)
You can now add restrictions on request types to control who can raise a specific request type and make sure that requests get routed to the appropriate channels. For example, you can restrict sensitive request types like employee pay hike to just managers and HR staff. The restrictions apply to both the customer portal and the issue view. Only people (help-seekers, agents, including admins) with explicit access to that request type can create these requests. They can also raise requests on behalf of people who don’t have access from the customer portal (and also through the Reporter field in the issue view).
Others who don’t have access to that request type, won’t be able to raise that request as they won’t see it available as an option - even via search. They can only see them if they’ve been added as a request participant after the request has been created.
Note that restrictions can’t be applied to request types used in email channels, allowing anonymous users to send requests through these channels.
Automation access restrictions
Status: IMPLEMENTED (EAP 01)
With the ability to add restrictions to request types in Jira Service Management, we’ve changed the following automations:
- Create servicedesk request
- Edit issue (only if the request type value changes)
- Transition issue (only if the request type value changes)
Jira automation will now check if the rule actor has access to create the request type used in any of your automation rules.