✓ OAuth 2.0 support for incoming mail
✓ View the custom fields that take longest to index
✓ Improved custom fields indexing
✓ Stale nodes automatically removed
✓ User anonymization (GDPR) improvements
✓ Erweiterung des Umfangs der Anonymisierung
✓ Anonymizing deleted users
✓ REST API changes
✓ Implementing validation logic
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:
|
---|
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.
|
---|