Jira 8.10 への準備

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

変更の概要

In this section we'll provide an overview of the changes we intend to make in Jira 8.10, 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. 

受信メールの OAuth 2.0 サポート

Status: IMPLEMENTED(eap 02)

In response to Google and Microsoft deprecating Basic Authentication, we are adding OAuth 2.0 authentication methods for incoming email (so far using the IMAP and POP3 protocols). We’ll also backport it to the supported Enterprise releases. If you currently use email to create issues and issue comments, you will need to reconfigure your incoming mail settings. 

OAuth 2.0 support will mean changes in to the incoming mail settings and the way you configure the incoming email server. Learn more about setting up the integration or get developer insight. 

View the custom fields that take longest to index DATA CENTER

Status: IMPLEMENTED (eap 01)

When you experience a sudden degradation in indexing performance, it might be because a custom field takes long to index. Normally, re-indexing time is not evenly distributed and there are several fields which take up most of the indexing time. This can be challenging, especially at scale. 

Now, instead of checking the logs for the stats you can view them in Jira. Click Actions > Custom field indexing for a specific node to view the data and take action to improve the performance. 

With this report art hand, you can test your Data Center-approved apps to see what impact they might have at Jira indexing and improve the custom fields they introduce as you go.

Improved custom fields indexing DATA CENTER

Status: IMPLEMENTED (eap 02)

大量のカスタム フィールドがあると、Jira のパフォーマンスやインデックス作成時間に悪影響を及ぼす可能性があります。この影響を最小化するために、フィールド インデックスの機能が呼ばれる数を減らす、新しい最適化機能を導入します。
特定の課題で値が存在しないときに、カスタム フィールドの並べ替えマーカーを保持することを廃止しました。また、すべてのインデックス機能は、特定の課題でカスタム フィールドの値が存在し、そのカスタム フィールドが表示されていて、その課題にスコープが割り当てられている場合にのみ実行されます。 

For now, all these improvements affect only Jira built-in custom fields. We’re also opening an experimental API to help you leverage these improvements (more details will soon be published on the Developer Community).
This is a complex change in the core functionality of Jira. In case you observe unpredicted behaviour around custom fields, contact customer support and or disable this functionality by using system properties (jira.cfv.driven.indexing.disabled, jira.local.context.indexing.disabled, jira.skip.indexing.null.disabled).

この変更を活用するには、完全な再インデックスを実行する必要があります。

Read more about the changes here. 

Stale nodes automatically removed DATA CENTER

Status: IMPLEMENTED (eap 02)

Now, you do not need to remove stale nodes manually. Nodes that show no heartbeat for two days are automatically moved offline, and those that are offline are removed from cluster after another two days.

ユーザーの匿名化 (GDPR) の改善

Status: IMPLEMENTED (eap 02)

Extending the scope of anonymization

The initial user anonymization came with some limitations that we continue to fix in newer versions. In Jira 8.10, you'll be able to anonymize the following items:

• 課題コレクターの報告者と作成者
• Full name in issue history (Assignee, Reporter, Single- and Multi-user picker custom fields)

For a list of existing and fixed limitations, see Anonymizing users.

Anonymizing deleted users

Until now, you couldn't anonymize users that have already been deleted, because Jira couldn't convert their deleted username into a user key that is needed for the anonymization. That's fixed now, and you can anonymize deleted users by going to Administration > User management > Anonymization, and entering the username.

When anonymizing a deleted user, you'll see the deleted label next to their username. They will also lack some additional information, like email address, profile link, or full name.

REST-API の変更点

To make the anonymization of deleted users possible, we've introduced the following REST API changes:

• Added the includeDeleted parameter to the get user query. This allows to retrieve deleted users, and can only be used by Jira admins.

• Added the deleted field to the response returned by this query.

The get user query should work just like before the changes—the new deleted field will be available, but the rest of the response won’t change.

We’ve also added the following change to the Java API:

/**
 * Checks if given user is deleted user.
 * Deleted user exists in jira app_users DB table (has user key and username) but does not exist in crowd (no user data eg. Full name, email etc.).
 *
 * @param user possible deleted user object - i.e. received from {@link #getUserByKeyEvenWhenUnknown(String)} or {@link #getUserByNameEvenWhenUnknown(String)}
 * @return <code>true</code> if given user is user existing in app_users DB table but does not exist in crowd, <code>false</code> otherwise (also when given object is <code>null</code>)
 * @see #getUserByKeyEvenWhenUnknown(String)
 * @see #getUserByNameEvenWhenUnknown(String)
 * @since 8.10
 */
@ExperimentalApi
boolean isUserDeleted(@Nullable ApplicationUser user);

Implementing validation logic

When a user is about to be anonymized, Jira performs some validations—these can check if the user is active, is not a system admin, and so on. As an app developer, you might need to perform additional checks, for example to see if the target user for ownership transfer has the right role.

Until now, you couldn't really get any error messages for these checks, apart from viewing the logs or the REST API responses.

We’ve implemented a new method that allows you to implement a validation logic and return errors in case it fails. It’s executed before the anonymization starts, allowing the executor to fix the problems quickly and try again before any changes are made.

The method has been added to the com.atlassian.Jira.user.anonymize.AnonymizationHandler interface:

/**
* Allows handlers to prevent the anonymization if it would break business logic constraints.
* <p>
* As an example, ownership transfer handler can ensure that an entity can only be transferred to
* a user with a particular role, e.g. only to another admin.
* <p>
* <strong>The calculations done here should be as quick as possible not to degrade the user experience!</strong>
* Only business logic constraints should be checked here. You can assume that the passed in parameters are otherwise
* valid, e.g. the user to transfer the entity to exists and is not disabled.
*
* @return an {@link ErrorCollection}, containing <strong>translated</strong> business logic validation errors if there were any, null otherwise
*
* @since v8.10
*/
@ExperimentalSpi
default ErrorCollection validateBusinessLogic(AnonymizationParameters anonymizationParameters) {
  return ErrorCollections.empty();
}