✓ OAuth 2.0 for incoming mail
✓ User anonymization (GDPR) improvements
✓ More insight into your custom fields (Data Center)
✓ Stale nodes automatically removed (Data Center)
✓ Optimized custom fields (Data Center)
OAuth 2.0 for incoming mail
Google and Microsoft are planning to deprecate basic authentication. This means that if you’re using one of these email providers (as your mail server in Jira) and create requests or issues via email, you will need to reconfigure your mail servers to use the OAuth 2.0 authentication method instead. Without these updates, your emails won’t land in the comfy Jira mailbox once Google and Microsoft put their plan in motion.
Jira 8.10 and Jira Service Desk 4.10 introduce support for OAuth 2.0, which was one of the most important goals of this release. For mail servers, used in Jira Core and Jira Software projects, you can use OAuth 2.0 for both Google and Microsoft, but for Jira Service Desk’s email channels Atlassian only support Google for now, and they are planning to add Microsoft soon.
Follow these steps to use OAuth 2.0:
- All Jira applications: Integrate Jira with OAuth 2.0.
- Jira Core and Jira Software projects: Reconfigure mail servers to use OAuth 2.0.
- Jira Service Desk projects: Reconfigure email channels to use OAuth 2.0.
The following features live in the Jira platform, which means they’re available for the whole Jira family — Jira Core, Jira Software, and Jira Service Desk.
User anonymization (GDPR) improvements
Back in Jira Service Desk 4.7, user anonymization was introduced to help you stay compliant with General Data Protection Regulation (GDPR). The initial feature came with some limitations that Atlassian continues to fix in newer versions. In this release, they have extended the scope of anonymization to include the following items:
- Reporters and creators of issue collectors
- Full name in the issue history (Assignee, Reporter, Single- and Multi-user picker fields)
- Ability to anonymize users that have already been deleted
If you have already anonymized some users, you can anonymize them again, in which case Atlassian’ll take care of the newly supported items and make your users disappear in a puff of GDPR.
More insight into your custom fields DATA CENTER
If you’ve ever wondered which of your custom fields make Jira indexing a drag, the Atlassian team can show you the culprit. No need to dig in the logs because the information is now easily accessible. The Custom field indexing page we’ve created show you top 10 fields that take longest to index allowing you to analyze the instance and take action. This is especially helpful in enterprise environments as custom fields can sometimes be challenging at scale.
To view the information, go to Administration > System > Clustering. Once you’re there, hit Actions > Custom field indexing.
Stale nodes automatically removed DATA CENTER
Automation was already introduced to your cluster maintenance. Now, you don’t have to remove the offline nodes from your cluster manually or move the nodes that report no heartbeat offline. After two days of a node reporting no heartbeat it’s automatically moved offline, and after two days of remaining in the offline state, it’s automatically removed from the cluster. So you can put your feet up and watch as we do cluster maintenance for you. Learn more
Optimized custom fields DATA CENTER
Large number of custom fields can negatively impact performance and indexing time in Jira. To minimize this impact, Atlassian is introducing a new optimization that reduces the number of called fields indexers.
Now, they won’t be storing sorting markers for custom fields when values don’t exist for a particular issue. 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 assigned for that issue.