June 2020 Atlassian Release Highlights

Back To Blog

Hooray! Time for a small party, because this is the 1st year anniversary of this blog covering the highlights of Atlassian Server and Data Center product updates. It’s not always easy to find time to write this monthly blog, but we did it and will continue to do so. Hope you all appreciate the effort!

To celebrate, from this month onwards, we will start covering Advanced Roadmaps for Jira (formerly Jira Portfolio) releases for the Server and Data Center platforms as well! Next to a quick overview of the latest features added to Advanced Roadmaps, the new features and bugfixes for Confluence, Bitbucket Server and Jira will be discussed as well. Continue reading for more details!

Enterprise releases → Long Term Support (LTS) releases

We’ve been covering Enterprise releases for a while now. For readers who don’t know what this is; Enterprise releases are designed to help customers feel confidently upgrade large, complex instances – ones that require significant planning to upgrade. Atlassian offers these releases for Jira Software, Jira Service Desk, Confluence, and, as of December, for Bitbucket Server and DC.

Since this month, Atlassian updated the name of these releases to Long Term Support (LTS) releases and Atlassian also updated their security bug fix policy. In short, they will now backport critical security bug fixes and when architecturally possible, will backport all other security bug fixes to Long Term Support releases as well. Great news!

As TMC ALM, we provide services for keeping your Atlassian tools up-to-date. We have a lot of experience with upgrading Atlassian environments safely and securely. Your data and business continuation has our top priority! When looking at Atlassian from a Platinum partner perspective we notice a significant trend at Atlassian. Although this is a monthly release update, when we zoom out and look at Atlassian (feature) development, in general, we see that the main focus is at Data Center and the Cloud. To learn more about what this trend or the new releases mean for you and your organisation, please check out our services page or contact us.


Advanced Roadmaps for Jira June’s Release Highlights (formerly Jira Portfolio)

Previous Advanced Roadmaps Release Highlights 3.20 – 3.27

First, let’s start with some of the more important release highlights of the recent past. A very big change is the rebranding of Portfolio to Advanced Roadmaps for Jira. This is introduced in version 3.27

Summary of interesting added features in the older releases:

  • Sort issues by custom number fields
  • Sort issues based on single-choice select custom field values.
  • A new issue search bar is added which can be used to search for specific issues in the plan.
  • Status color parity between Portfolio and Jira.
  • New velocity insights in sprint capacity details: Graphical insights on your team’s velocity at a glance and a link to the View velocity chart.
  • Save plan views: possibility to save a certain view with selected fields on a plan to easily jump to that view.
  • Export a plan’s information to CSV. Including rolled-up values
  • Roll-up dates in plans
  • Releases grouped by unreleased and released
  • Very powerful feature: Edit dates for future sprints in Jira. The sprint dates set in Jira are used in the plan.
  • Share a direct link to a saved view

Advanced Roadmaps for Jira 3.28

A very interesting feature is added in this version. Since the introduction of Portfolio 3.x is was not possible to define a different team capacity for future sprints. This resulted in a fixed capacity for all sprints which is often not useful during a holiday period.

  • Edit sprint capacity directly on your timeline.

In this version, it is possible to define a deviating capacity for specific future sprints.

Advanced Roadmaps for Jira 3.29

Other interesting features are added in June as part of version 3.29.

  • Visualize and plan for dependencies (early access feature).

With this feature, it is possible to visualize the dependencies between issues.

  • Manage all warnings in one place

With this feature it becomes possible to define which warnings should be made visible in the plan.

Our advice

Atlassian frequently delivers new versions of Advanced Roadmaps, sometimes weekly. They are very actively adding interesting features.

We recommend version 3.29 due to the interesting added features.


Jira’s June Release Highlights

Jira 8.9.1

On June 16th, Atlassian release bugfix release 8.9.1 for Jira. This bugfix release contains a couple of bugfixes worth noting:

  • Since Jira 8.3 the integration between Jira and Bitbucket can cause an error in the logs and development panel of an issue if the request size is large. There are a few workarounds, but Atlassian fixed this in a number of releases including 8.9.1: 8.6.2, 8.7.2, 8.5.5, 8.8.2 and 8.10.0. Check out JSWSERVER-20190 for more details.
  • Under a specific scenario, when doing a Bulk Change to Edit Issues, Jira ends up with a NULL value under the issuenum column of the jiraissue table, causing indexing failures with Reindex All FAILED error. This issue has been fixed from Jira 8.9.1 onwards (JSWSERVER-16473).
  • Since Jira 8.8, editing an issue with cascading select without child option clears the parent option and information about the removed parent option is stored in the issue history (JRASERVER-71099).

Next to these bugfixes, a bunch of security fixes have been implemented as well; some of them are backported to the latest LTS release (marked with [LTS version]):

  • CVE-2020-4028: Affected versions of Atlassian Jira Server and Data Center allow remote attackers to view sensitive information via an Information Disclosure vulnerability in Login. This issue has been fixed from Jira 8.9.1 onwards, but Atlassian also mentions that if the fix is causing problems it can be disabled by adding to Jira a dark feature flag: jira.redirect.anonymous.404.errors.disabled (JRASERVER-71175).
    In Long Term Support releases 8.5.6 and 7.13.15, this fix will be included, but disabled by default.
    So, be extra careful when updating past 8.9 from, Atlassian isn’t mentioning this for fun.
  • CVE-2020-4025, CVE-2020-4022, CVE-2020-4024: remote attackers were able to inject arbitrary HTML or JavaScript via a Cross-Site Scripting (XSS) vulnerability issue attachments (JRASERVER-71114, JRASERVER-71107, JRASERVER-71113) [LTS 8.5.5].
  • CVE-2020-14167: remote attackers were able to impact the application’s availability via a Denial of Service (DoS) vulnerability in Dashboard & Gadgets (JRASERVER-71197) [LTS 8.5.5].
  • CVE-2020-14168: remote attackers were able to access outgoing emails between a Jira instance and the SMTP server via man-in-the-middle (MITM) vulnerability (JRASERVER-71198) [LTS 8.5.7].
  • CVE-2020-14169: remote attackers were able to inject arbitrary HTML or JavaScript via a Cross-Site Scripting (XSS) vulnerability (CVE-2020-14169).

Jira 8.10.0

The 8.10 feature release of Jira was released on June 23rd and contains some interesting feature additions, especially for Data Center:

  • Microsoft and Google are planning to disable Basic Authentication, hence Atlassian added OAuth 2.0 support to the incoming mail configuration.
  • The below GDPR anonymization improvements have been added. Note that if you have already anonymized users, you can anonymize them again, in which case the following improvements will be executed as well.
    • 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
  • For Data Center a very interesting feature has been added; a custom field indexing page. This shows you top 10 fields that take the longest to index allowing you to analyse the instance and take action.
    Check out: Jira Administration → System → Clustering → Actions → Custom field indexing.
    Additionally, Atlassian optimized how custom fields are indexed. In short, sorting markers for custom fields won’t be stored when values don’t exist for a particular issue and indexers will be executed only when custom field’s values exist for a particular issue and the custom field is visible and has a scope assigned for that issue.

A number of bug fixes are also fixed in this release, most of them are also covered in the Jira 8.9.1 highlights, but one long outstanding (2017) bug has been fixed in the Jira 8.10 release:

  • When user tries to edit the “User picker* custom field in the issue detail view, the following javascript error will be shown: Exception: Uncaught TypeError: Cannot read property ‘scrollTop’ of undefined (JSWSERVER-16073).

Jira Service Desk 4.9.1

Besides the bug fixes mentioned in the Jira 8.9.1 release highlights, the JSD 4.9.1 bugfix release contains 1 major bugfix specifically for JSD:

  • This bug causes all recalculations of SLAs with the “Comment: for customers” condition to be wrongly recalculated and corrupted. For example, SLAs that should have been paused/stopped, are still running (JSDSERVER-6857).

Jira Service Desk 4.10.0

JSD release 4.10.0 contains only one specific JSD feature and a few bugfixes on top of the what was covered in the Jira 8.10.0 release highlights:

  • The REST API now supports retrieving the Portal IDs. Although the Service Desk ID and Portal ID will match most of the time, this is not always the case.
  • CVE-2020-14166: remote attackers were able to inject arbitrary HTML or JavaScript via a Cross-Site Scripting (XSS) vulnerability in API and Integrations (JSDSERVER-6895).
  • Editing a Customer Request Type in the right sidebar did not trigger notifications to be sent (JSDSERVER-6814).
  • In some cases, if an incoming mail used to reply to an existing ticket contains attachments which names match the names of attachments that are already in the ticket, the mail will fail to be processed (JSDSERVER-6884).

Our advice

A lot of security fixes have been implemented in Jira 8.9.1 (JSD 4.9.1. Although these were mostly minor issues, a bunch of them have been backported to the LTS 8.5.5 release.

All these security fixes are also available in Jira 8.10.0 and JSD 4.10.0, hence we recommend to upgrade to this version if you are on a Jira version before Jira 8.9.1.

For the Long Term Support (LTS), formerly Enterprise release customers, we strongly advise upgrading to Jira 8.5.5 like we did last month.


Confluence’s June Release Highlights

Confluence 7.5.1 and 7.5.2

Five fixes in total are included in the latest Confluence 7.5.1 and 7.5.2 bugfix releases. We cover the three worth noting ones:

  • CVE-2020-4027: remote attackers with system administration permissions were able to bypass velocity template injection mitigations via an injection vulnerability in custom user macros (CONFSERVER-59898).
  • A bug first reported in 2014 is now fixed! The Total Remaining Estimate values are not showing in Jira issue macro in Confluence (CONFSERVER-34149).
  • And another one from 2015 concerning the breadcrumbs trail to overlap the page title has also been fixed (CONFSERVER-39913).
    Related to this, also a bug has been fixed where this happens when opening the spaces menu (CONFSERVER-59692).

Confluence 7.6.0

Right on the brink of the end of this month, June 30th, Atlassian released Confluence 7.6; a new feature release. Although, it might not be as interesting as you might expect:

  • For Data Center customer, the advanced coverage in the audit log now includes more user-triggered events:
    • moving pages and blog posts
    • sharing details on pages and blog posts
    • access requests to pages and blog posts and the resulting access grants
  • A bug that has been reported back in 2018 has been fixed. From Confluence 7.6 onwards, the login date timestamp in Confluence’s User details page will also be updated when a user logs in using Confluence’s SSO 2.0 (Atlassian Crowd) feature (CONFSERVER-55855).

Our advice

Unless you are an Atlassian Crowd user, the Confluence 7.6.0 release any additional neat features of bugfixes. Though it does contain the bugfixes from both 7.5.1 and 7.5.2.

That’s why we suggest upgrading to Confluence 7.6.0 if anything that was covered this month sounds necessary for you. If not, we suggest you wait for a more interesting release to upgrade to.

For the Long Term Support (LTS), formerly Enterprise release customers, Atlassian released the first bugfix release for the LTS 7 release on June 11th. Bugs included in Confluence 7.4.1 are the ones that were fixed in Confluence 7.5.0 covered in last month’s edition. Upgrading is not a must but might be valuable.

Another thing concerning the companion app, it is now possible to set trusted domains/sites before rolling out the Companion app to all users. Setting your Confluence URL as a trusted domain means users don’t have to select ‘Trust this domain’ when they edit a file for the first time. Set your trusted domains with an environment variable or during the MSI installation for your users, to make it less of a burden to use this app.


Bitbucket’s June Release Highlights

Bitbucket 7.2.5

On June 17th, Atlassian released the bugfix release Bitbucket 7.2.5, including the following fixes:

  • For Data Center, if a mirror sync (git fetch) idle times out, fetched items are left on-disk as temporary files. Due to the sync failure, the mirror will schedule a new sync. This retry process is indefinite with a incremental retry-wait time. This causes a buildup of objects/pack/tmp_pack_* files which can lead to disk exhaustion (BSERV-12278).
  • Attempting to merge a pull request using one of the “rebase” merge strategies (“Rebase and merge” or “Rebase fast-forward”) can time out when there are no files in the top-level of the target branch and the first file is encountered within a subdirectory more than 1 level deep (BSERV-12406).
  • After certain types of forced updates to pull requests, it’s possible (due to another bug, which remains undiagnosed) to end up with both the source and target branches on the pull request referencing the same commit. When that happens, the pull request becomes unviewable in the UI due to an error running git merge-base (BSERV-12388).

Bitbucket 7.3.0 and 7.3.1

The Bitbucket 7.3.1 bugfix was released on June 17th, together with the above covered Bitbucket 7.2.5. Hence, these two contain the exact same bugfixes.

The highlights of what’s new and fixed in Bitbucket 7.3.0, the latest feature release which was released on June 2nd, are the following:

  • Important change when upgrading to 7.3, the delete source branch after merging checkbox will now be checked by default when you merge a pull request. If this isn’t your preferred setting, you can change it and Bitbucket will remember your choice in your user’s profile for next time (so no cookie storage).
     
  • Support for Git 2.27 has been added.
  • More audit log events have been added. Checkout Audit log events in Bitbucket for more details.
  • The number of “scm-refs” has been increased and is now set to 8, but the end value is proportional to a configurable scaling factor, which defaults to the number of CPUs reported by the JVM. For example, if the JVM reports 8 CPUs, the system will default to 8×8=64 “scm-refs” tickets.
  • Token expiry has been added to improve security around token usage. Users can set when a new token will automatically expire. Admins are able to make the token expiry date mandatory and set the maximum number of days a token can be valid.

The most interesting bug fixes in Bitbucket 7.3.0:

  • Bitbucket truncates the diff view of a pull request such that all changes may not be visible. The fix for this bug has been backported to new bugfix releases for all Bitbucket 7 feature releases (BSERV-12309).
  • The Contribution Guideline on the Pull Request overview page is missing in since Bitbucket 7 (BSERV-12356).
  • When the Bitbucket GitGarbageTruck thread attempts to prune stale git objects on Windows Bitbucket instances, the attempt to delete the file fails because git places a read-only lock on all git objects – preventing the Java process from being able to delete the file (BSERV-12319) [LTS 6.10.5].
  • The mirror synchronization idle timeout (git) is too aggressive at 5 minutes, compared to the upstream default at 30 minutes. With large repositories, the upstream can spend over 5 minutes to gather data and send a response back to the client. This causes the sync operation to fail with a timeout before the upstream can send anything to the mirror (BSERV-12202) [LTS 6.10.5].
  • Since Bitbucket Server 5.10, on the Commits page, hovering over the tag labels shows both the tag name tooltip and the commit message tooltip (BSERV-10800).
  • When upgrading from Bitbucket from 6.x to 7.x version and the comment table in the database is empty (comments on files or pull requests), the upgrade will fail (BSERV-12315).

Our advice

Again Bitbucket 7.3.1 does not contain any critical fixes compared to 7.2.0. If you are on a version lower than 7.2.0, we do advise to upgrade to the latest 7.3.1 release.

Customer following the Long Term Support, formerly Enterprise releases can upgrade to Bitbucket 6.10.5, but it’s probably not worth the effort and downtime if you are already on Bitbucket 6.10.4.


Thanks for reading!

Read our blog Upgrade Best Practices for stress free upgrades or contact us if you have any (support) questions.

Door de site te te blijven gebruiken, gaat u akkoord met het gebruik van cookies. meer informatie

De cookie-instellingen op deze website zijn ingesteld op 'toestaan cookies "om u de beste surfervaring mogelijk. Als u doorgaat met deze website te gebruiken zonder het wijzigen van uw cookie-instellingen of u klikt op "Accepteren" hieronder dan bent u akkoord met deze instellingen.

Sluiten