Streamline your request intake process

Streamline your request intake process
For: ADMINS

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. 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.

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
For: ADMINS

With the ability to add restrictions to request types in Jira Service Management, we’ve changed the following automations. Jira automation will now check if the rule actor has access to create the request type used in any of your automation rules.

• Create servicedesk request
• Edit issue (only if the request type value changes)
• Transition issue (only if the request type value changes)

OAuth 2.0 for Application Links supporting 3LO
For: ADMINS
We’re now offering OAuth 2.0 as a more secure protocol for integrating our applications together via application links. This will also ensure you can maintain connected workloads between Atlassian on-premises and FedRAMP Cloud applications.

Explore how to upgrade your configuration

JDK 17 with the Java 16 language level
For: ADMINS
In the Jira 10.0 release notes we announced that Java 17 is now the default language level. We want to clarify that even though Jira was recompiled in JDK 17, Java 16 was used as the compilation language level.

Share usage data
For: ADMINS
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.

You own your data and decide what you share with us:

Basic data collects performance metrics and instance metadata to monitor security and performance.
Advanced data additionally includes feature usage. We’ll use this information to improve existing features and prioritize work on the new features that best suit your needs.
Disabled data sharing means no data is being collected.

Automation rule validation
For: ADMINS

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.

Webhooks auditing
For: ADMINS

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.added
• jira.webhooks.auditing.webhook.modified
• jira.webhooks.auditing.webhook.deleted
  This event will include:
• The id of the webhook being altered as part of the affected object
• The webhook uri
• The values that have been changed, if relevant