Jira 9.0 への準備



アトラシアン コミュニティをご利用ください。


This documentation is intended for Jira developers who want to ensure that their existing apps are compatible with Jira 9.0 



ここでは最新の EAP についての情報をご案内します。

アプリケーション / 日付

EAP 番号

バージョン (Maven)


Jira Core/Software





Source files (Core)

Source files (Software)

Jira Service Management





ソース ファイル


In this section we'll provide an overview of the changes we intend to make, so you can start thinking how it might impact your apps. Once they're ready, we'll indicate when a change has been implemented, and in which milestone. 

Automation for Jira (Data Center)

Status: IMPLEMENTED (eap 01)

With the release of Jira 9, Automation for Jira will become a native feature, bringing additional value to Data Center customers. This feature will be available both in Jira Software and Jira Service Management for automated, effective work. Automation for Jira will continue to be available in Jira 9 also for Server customers but will require an existing paid license.

The feature is still under development and minor changes related to configuration of the feature may be introduced.

Limit excessive activity with the Guardrails Tool

Status: IN PROGRESS (eap 01)

To help you minimize performance drops or crashes resulting from exceeding a certain number of items per data dimension in your Jira instance, we’ve created the Guardrails Tool.

With this tool, Administrators can moderate a user group’s activity by setting a global limit on the number of specific items its members can create. For example, if you rely heavily on automation, you can limit the number of comments a bot account can add to an issue, which can help boost the performance of loading the issue view.

Additionally, Jira will send all Administrators an email notification every time it detects that a particular limit has been reached, is close to being reached, or has been exceeded.

Learn how to manage and configure the Guardrails Tool

The feature is still under development and its behavior, configuration, and name are subject to change. Additionally, in Jira 9.0 EAP 01, the feature is limited to controlling the number of comments created per issue.

The “View on board” feature gets a redesign for better performance

Status: IN PROGRESS (eap 02)

We’re replacing the old “View on board” feature with an entirely new experience aimed at improving the responsiveness of searching for boards that contain a particular issue.

Now, instead of searching through every board in the system, we’re limiting the search to only those boards that make explicit mention of an issue’s project key and your recently viewed boards. As a result, you’ll get more meaningful results much quicker than before.

The feature is still under development and minor changes related to configuration of the feature may be introduced.

Lazy-loading workflow transitions

Status: IMPLEMENTED (eap 01)

We’ve moved all the transition buttons to the dropdown menu. We're now rendering all of the Jira transitions in the dropdown asynchronously on-demand after a user opens the dropdown.

We’ve also removed the status field and View workflow link from the issue details section. The View workflow link is now shown as an option in the dropdown. The current status is presented in the trigger label.

What do I need to know?

  • For complicated workflows, the dropdown will be very tall and hard to use in windows with small heights.

  • The dropdown is now wider than before that so it can be clipped in windows with a very small width.

  • We cannot distinguish between the case that the user has no permissions to transition the status or if the issue is already in a status that has no possible transitions. For such cases, we display user assistance.

Lazy-loading attachments' thumbnails on issue view

Status: IMPLEMENTED (eap 01)

We’ve sped up the loading time of issues with a significant number of attachments. With the new functionality, thumbnails generation is deferred and asynchronous for the issue view by default. It speeds up page loading and reduces the amount of data processed at once.

To disable the functionality you need to setcom.atlassian.jira.thumbnailsDeferredGeneration.disabled parameter.

The attachment lazy-loading feature outside of the Issue view is disabled by default.

To enable the functionality you need to set com.atlassian.jira.allThumbnailsDeferred.enabledin /secure/SiteDarkFeatures!default.jspa parameter.

Activity Tabs improvements

Status: IN PROGRESS (eap 01)

As part of broader Issue View improvements, we’re optimizing the way activity items such as Comments, History, Work Logs, and the All tab are displayed and organized.

In EAP 01, we’ve focused on Comments but we will ship further improvements in the upcoming EAP releases.

From now on, Jira won’t load all items at once. Instead, it will show 10 items (e.g. comments) on a page. The user can still see all comments but will have control over the presented elements, loading 10 older or newer elements with one click. In addition to that, we’ve changed the way sorting works so that the user has easy access to both the oldest and newest items (so far, Jira reordered the newest elements only).

What do I need to know?

If you want to display your content in the All tab, you will have to implement a new API interface. The documentation and an example of a code for that will be delivered with the next EAP.

Popper replaces Tipsy in AUI 9.3.5

Status: IMPLEMENTED (eap 01)

We’ve upgraded AUI to version 9.3.5, which replaces the Tipsy tooltip generation library with Popper. To make sure that your tooltips still work with the upgraded AUI, you may need to make some changes:

  • AUI no longer supports the data-tooltip attribute. Instead, use the title attribute on the element to which a tooltip should be attached.

  • Tooltips will appear even if the title is empty. To prevent that from happening, destroy the tooltip by calling the $el.tooltip('destroy') function.

  • To pass HTML markup to the tooltip, call $el.tooltip({ html: true }).

Replace the tipsy.revalidate() method with $el.tooltip('destroy').

Restricting anonymous access to REST endpoints

Status: IMPLEMENTED (eap 01)

We’ve restricted anonymous access to the following REST API endpoints:

  • /rest/api/2/issueLinkType

  • /rest/api/2/priority

  • /rest/api/2/projectCategory

  • /rest/api/2/resolution

  • /rest/api/2/status

  • /rest/api/2/statuscategory

  • /rest/api/2/projectvalidate/key?key=

  • /rest/api/2/jql/autocompletedata/

  • /rest/api/latest/avatar/project/system

  • /rest/api/2/field

  • /rest/api/2/screens

  • /rest/api/1.0/issues/<issueId>/ActionsAndOperations

From now on, anonymous users attempting to perform GET requests on the previously listed endpoints will receive a “401 Unauthorized” response code.

Improved XSRF protection

Status: IMPLEMENTED (eap 01)

We’ve changed the XSRF protection default policy for web actions:

  • XSRF (or CSRF, Cross-Site Request Forgery) is an old attack class and Jira is already equipped with XSRF countermeasures since Jira 4.1 (2009) - token checks - for both REST API and WebWork routes (aka web actions). However, before Jira 9 web actions were only protected if their code was annotated with the @RequiresXsrfCheck annotation, meaning it is the developers' responsibility to opt-in for XSRF token checks provided by Jira Core. In the wild, the opt-in approach means a risk of unprotected web actions and a successful XSRF attack.

  • This will change in Jira 9. Web actions invoked with POST/PUT/PATCH/DELETE HTTP methods (or actually whatever HTTP method other than GET, HEAD, OPTIONS or TRACE) will be subject to XSRF token checks by default unless the action code is annotated with @DoesNotRequireXsrfCheck a new explicit opt-out annotation.

  • To temporarily revert the default to the old one (Jira 8’s opt-in XSRF check policy) the jira.webactions.request.method.dependent.xsrf.checks.disable feature flag may be used.

What is changing?

Changes may be required for web actions invoked with POST/PUT/PATCH/DELETE having no @RequiresXsrfCheck annotation in Jira 8. Here are the general guidelines to follow while adapting to the new XSRF policy:

For truly safe actions, i.e. actions without state modifying side-effects (like pure reads or searches) simply change your front-end pieces to use GET (or HEAD or OPTIONS) HTTP method instead of POST/PUT/PATCH/DELETE. If you have a good reason to stick to POST/PUT/PATCH/DELETE (e.g. GET URL may become too long for certain supported browsers, therefore you choose to make POST as a workaround for browser’s limitation) - you may want to either:

- annotate your action with @DoesNotRequireXsrfCheck - but remember to use it with caution and to justify each usage in code comments,

- add an XSRF token as you would do for state-modifying actions.

For all other actions (i.e. for unsafe / state-modifying actions) change the front-end pieces to include XSRF token in the atl_token request parameter - exactly same way as you would do implementing action with @RequiresXsrfCheck in Jira 8.

API の重大な変更

Status: IN PROGRESS (eap 01)

Work on API breaking changes is ongoing. We will ship further improvements in the upcoming EAP releases.

Removed API classes and methods

The following API classes and methods were previously deprecated and are now removed:













getGroup(@Nullable String groupName)
getGroupObject(@Nullable String groupName)
createUserWithNotification(String username, String password, String email, String fullname, int userEventType)
createUserWithNotification(String username, String password, String email, String fullname, Long directoryId, int userEventType)
createUserNoNotification(String username, String password, String emailAddress, String displayName)
createUserNoNotification(String username, String password, String emailAddress, String displayName, Long directoryId)
createUser(@Nonnull final UserDetails userData, final boolean sendEmail, final int eventType, @Nullable Set<ApplicationKey> applicationKeys)
canActivateNumberOfUsers(int numUsers)
getUser(String userName)
getUserByKey(@Nullable String userkey)
getUserByName(String username)
getUserObject(String userName)
addToJiraUsePermission(ApplicationUser user)
getUsersInGroupNames(Collection<String> groupNames)
getUsersInGroups(Collection<Group> groups)




getUser(final @Nullable String userName)
getUserObject(final @Nullable String userName)
getUserEvenWhenUnknown(@Nullable String userName)














forIssue(long, String)











API classes and methods moved to Jira Core


API class / method added



Added forceStrongConsistency, which was needed in jira-core and may be needed in situations when consistency is important, like in the external communication or security context.

This parameter must force implementation to avoid returning the stale data, for example cached data.

Note: This may affect the performance, so use only when really necessary.

XStream allowlist for improved safety

Status: IMPLEMENTED (eap 02)

XStream is used for storing default values of custom fields inside the database. It serializes the default value to the XML and deserializes it back when it’s retrieved back. There is a security risk that lies in the deserialization part. If someone has access to the database, they can put XML containing malicious code that would be executed during the deserialization process. To prevent it, XStream 1.4.18 introduced allowlist, which contains the names of the classes that can be deserialized. If a class is not there, deserialization will fail with an exception. Jira 9.0 uses XStream 1.4.18 with the allowlist by default.

What’s changed?

Some apps that add custom field types will have to extend the allowlist with the class of its transport object. It’s required only if the class is not already on the allowlist. The current elements are listed below. If a line starts with class, it means that only the given class is allowed. If it starts with hierarchy, all its descendants are allowed:

class java.io.File
class java.lang.Class
class java.lang.Object
class java.lang.StackTraceElement
class java.lang.String
class java.lang.StringBuffer
class java.net.URI
class java.net.URL
class java.nio.charset.Charset
class java.text.DecimalFormatSymbols
class java.time.Duration
class java.time.Instant
class java.time.LocalDate
class java.time.LocalDateTime
class java.time.LocalTime
class java.time.MonthDay
class java.time.OffsetDateTime
class java.time.OffsetTime
class java.time.Period
class java.time.Ser
class java.time.Year
class java.time.YearMonth
class java.time.ZonedDateTime
class java.time.chrono.HijrahDate
class java.time.chrono.JapaneseDate
class java.time.chrono.JapaneseEra
class java.time.chrono.MinguoDate
class java.time.chrono.Ser
class java.time.chrono.ThaiBuddhistDate
class java.time.temporal.ValueRange
class java.time.temporal.WeekFields
class java.util.BitSet
class java.util.Currency
class java.util.Date
class java.util.Locale
class java.util.regex.Pattern
hierarchy java.lang.Enum
hierarchy java.lang.Number
hierarchy java.lang.StringBuilder
hierarchy java.lang.Throwable
hierarchy java.lang.reflect.Member
hierarchy java.nio.file.Path
hierarchy java.sql.Date
hierarchy java.sql.Time
hierarchy java.sql.Timestamp
hierarchy java.time.Clock
hierarchy java.time.ZoneId
hierarchy java.time.chrono.Chronology
hierarchy java.util.Calendar
hierarchy java.util.Collection
hierarchy java.util.Map
hierarchy java.util.Map.Entry
hierarchy java.util.TimeZone
hierarchy java.util.UUID

Apart from that, all primitives and arrays are allowed. Find the definition of a transport object in our documentation.

Extending the allowlist

We’ve introduced com.atlassian.jira.security.serialization.XmlPluginAllowlistProvider that can be used for listing the classes that have to be added to the allowlist. Here’s an example implementation:

package com.atlassian.tutorial.jira.customfields;

import com.atlassian.diff.CharacterChunk;
import com.atlassian.jira.security.serialization.XmlPluginAllowlistProvider;

import javax.validation.constraints.NotNull;
import java.util.HashSet;
import java.util.Set;

public class AllowlistProvider implements XmlPluginAllowlistProvider {
public @NotNull Set<String> getAllowlistedClasses() {
Set<String> set = new HashSet<>();
return set;

To be effective, the implementation has to be specified as a module inside the atlassian-plugin.xml file. The name of the module is xml-plugin-allowlist and it needs to have a key (some unique string) and class attributes. For example:

<xml-plugin-allowlist key="plugin.extensions" class="com.atlassian.tutorial.jira.customfields

SLA thread processing configuration


Status: IMPLEMENTED (eap 02)

We’ve added a new SLA configuration setting that allows you to select the off-thread processing mode:

  • Multi-threaded serialized processing (Recommended). Cluster efficient, recoverable, and resilient. Should be the default processor.

  • Multi-threaded in-memory processing. Legacy processing mode. Only revert to it temporarily if instructed.

  • No background processing. All processing will be done in the request thread, locking the response until it’s finished. You might experience a significant delay to the response time.

To configure your SLA off-thread processing mode:

  1. Go to Administration > Applications.

  2. Select SLA configuration.

  3. Find the SLA threads row and select Configure.


  • It takes a long time to load any page (over 2 mins for batch.js). This seems to be only present for a very small amount of users.

最終更新日: 2022 年 2 月 21 日


Powered by Confluence and Scroll Viewport.