Jira 8.21 への準備

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

 

9.0.0-rc01

9.0.0-m0002

EAP

Source files (Core)

Source files (Software)

Jira Service Management

 

5.0.0-rc01

5.0.0-m0002

EAP

ソース ファイル

変更の概要

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 eliminate performance drops or crashes resulting from exceeding a certain number of entities in your Jira instance (for example, comments, active projects, or epics), we’ve created the Guardrails Tool.

The tool enables System Administrators to 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 out 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/2346583/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 adopting 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:

com.atlassian.jira.action.JiraActionSupport

com.atlassian.jira.upgrade.ConnectionKeeper

com.atlassian.jira.config.database.DatabaseConfig#isHSql

com.atlassian.jira.config.database.LegacyHsqlDatasourceInfo

com.atlassian.jira.task.com.atlassian.jira.task.TaskManager#shutdownAndWait(long)

com.atlassian.jira.issue.index.IssueIndexer#indexIssues

com.atlassian.jira.issue.index.IssueIndexer#deindexIssues

com.atlassian.jira.issue.fields.CustomFieldImpl

com.atlassian.jira.config.webwork#JiraActionFactory

com.atlassian.jira.util.index.IndexLifecycleManager#reIndexAllIssuesInBackground

com.atlassian.jira.util.index.IndexLifecycleManager#isIndexingEnabled

com.atlassian.jira.util.collect.LRUMap

com.atlassian.jira.user.util.UserUtil
getTotalUserCount()
clearActiveUserCount()
getUsers()
getAllApplicationUsers()
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)
getActiveUserCount()
canActivateNumberOfUsers(int numUsers)
getUser(String userName)
getUserByKey(@Nullable String userkey)
getUserByName(String username)
getUserObject(String userName)
getAdministrators()
getSystemAdministrators()
addToJiraUsePermission(ApplicationUser user)
getUsersInGroupNames(Collection<String> groupNames)
getUsersInGroups(Collection<Group> groups)

com.atlassian.jira.user.util.UserUtil

getUsers()

com.atlassian.jira.user.util.UserManager

getAllUsers()
getUsers()
getUser(final @Nullable String userName)
getUserObject(final @Nullable String userName)
getUserEvenWhenUnknown(@Nullable String userName)
getAllGroups()
getGroups()

com.atlassian.jira.user.UserUtils#getAllUsers

com.atlassian.jira.user.preferences.PreferenceKeys#USER_JQL_AUTOCOMPLETE_DISABLED

com.atlassian.jira.issue.fields.util#VersionHelperBean

com.atlassian.jira.issue.customfields.CustomFieldUtils#getDateFormat

com.atlassian.jira.issue.customfields.CustomFieldUtils#getDateTimeFormat

com.atlassian.jira.issue.customfields.CustomFieldUtils#getTimeFormat

com.atlassian.jira.issue.customfields.searchers#UserPickerSearcher

com.atlassian.jira.issue.customfields.config.item#VersionOptionsConfigItem

com.atlassian.jira.issue.comparator.UserBestNameComparator

com.atlassian.jira.issue.changehistory.ChangeHistoryManager

com.atlassian.jira.issue.changehistory.DefaultChangeHistoryManager

findAllPossibleValues()
findMovedIssue()
getPreviousIssueKey(Long)
getPreviousIssueKeys(String)

com.atlassian.jira.issue.changehistory.ChangeHistoryItem
getUser()
getFrom()
getTo()
getFromValue()
getToValue()

com.atlassian.jira.issue.changehistory.ChangeHistoryItem.Builder
withId(long)
inChangeGroup(long)
inProject(long)
forIssue(long, String)

com.atlassian.jira.config.ConstantsManager#convertToConstantObjects

com.atlassian.jira.config.ConstantsManager#getStatusObjects

com.atlassian.jira.config.ConstantsManager#getIssueTypeObject

com.atlassian.jira.config.ConstantsManager#getResolutionObject

com.atlassian.jira.config.ConstantsManager#getResolutionObjects

com.atlassian.jira.config.ConstantsManager#getDefaultPriorityObject

com.atlassian.jira.config.ConstantsManager#getPriorityObjects

com.atlassian.jira.config.properties.JiraSystemProperties#isOnDemand

com.atlassian.jira.config.ConstantsManager#refresh

com.atlassian.jira.config.FeatureManager#isOnDemand

API classes and methods moved to Jira Core

com.atlassian.jira.web.action.RedirectSanitiserImpl

API class / method added

注意

com.atlassian.jira.bc.user.search.UserSearchParams

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.


既知の問題

  • Adaptivist ScriptRunner for Jira is broken. groovyrunner-6.42.0.jar. Need compatible release from the vendor.

  • 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 年 1 月 19 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.