Summary of changes

Here we inform you about the changes Atlassian will make in Jira 8.10. This will allow you to consider how these changes will affect your current Jira configuration before updating.

OAuth 2.0 support for incoming mail

Status:IMPLEMENTED (eap 02)

In response to Google and Microsoft deprecating Basic Authentication, Atlassian is 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)

Large number of custom fields can negatively impact performance and indexing time in Jira. To minimise this impact, Atlassian is introducing a new optimization that reduces the number of called field indexers.

Now, sorting markers for custom fields are no longer stored if there are no corresponding values for a specific problem.  Additionally, indexers will be executed only when custom field’s values exist for a particular issue and the custom field is visible and has scope scope assigned for that issue.

For now, all these improvements affect only Jira built-in custom fields. Atlassian is 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).

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.

User anonymization (GDPR) improvements

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:

• Mentions in the issue history
• Mentions in the project description
• Reporters and creators of issue collectors
• Full name in issue history (Assignee, Reporter, Single- and Multi-user picker custom fields)
• Mentions in text custom fields’ default value

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 changes

To make the anonymization of deleted users possible, Atlassian has 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.

The following change has also been added 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.

Atlassian has 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();
}