Welcome to the October 2020 edition of our monthly recurring blog post covering the highlights of Atlassian Server and Data Center product updates. For each product, we cover a selection of the most exciting new features, bug fixes and security advisories that were released in the last month.

In this month’s edition, Atlassian’s announcement to stop with Server products will be the main focus. But of course, we will cover this month’s releases as well, including the new Jira 8.13 LTS release.

Because of Atlassian’s Journey to the Cloud, TMC ALM will be doing the same basically. From next month onward, this blog series will focus on updates and changes in the Cloud products, updates and advise regarding Server to Cloud migration and Atlassian Cloud subscriptions. We will still be covering Server and Data Center release updates, although these will be discussed in less detail than you are used to at the moment.

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 solution 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.

Atlassian’s journey to the Cloud

---

Most of you should have received the news by now that Atlassian has published dates for the discontinuation of their Server products. For those we didn’t, here you can find the official announcement.

What this basically means is that you have three options:

1. Start planning your migration to the Cloud.
2. Switch to Data Center licenses.
3. Continue using unsupported Server products.

We will discuss the pros and cons of each option in detail.

Start planning your migration to the Cloud

This is of course the preferred route to take and the most sustainable in the long run. By moving to Atlassian’s Cloud, you will save on maintaining infrastructure, application maintenance and service availability for your users as the Cloud product is on average more reliable than a self-hosted Server instance. Also, with Cloud products, you get the Jira Automation app for free and with their premium subscription, even Advanced Roadmaps (formerly Portfolio) is included in Jira Software Cloud. A lot of new features are also expected for Atlassian Cloud. And last, but not least, Cloud pricing will become a lot more affordable than Data Center and Server pricing as Atlassian will be raising the on-premise pricing dramatically starting from February 2nd, 2021.

There are, however, also a number of limitations and Atlassian is actively trying to mitigate some of those. you can follow their Cloud improvements on their Cloud Roadmap.

Things you need to take into account when migrating to the Cloud:

• You can’t limit product access to your internal network only. For some businesses, this could be blocking. Although Atlassian shipped IP allow listing last month to their Cloud Premium plan offering.
• Most marketplace Cloud apps currently have limited functionality to their Server/DC counterpart or aren’t available at all on Cloud. This is mainly due to the limitations in the Cloud API compared to the far more open Server/DC API. Atlassian however, promises to work together with app developers in making their apps compatible for Cloud. This might take a while and probably will require you to make some concessions in the meantime.
• Multifactor authentication (MFA/2FA) can’t be enforced on Atlassian accounts with a domain that isn’t managed by the organization. This means that contractors should be provided with an organisation account or accept the fact that they might not have MFA enabled on their Atlassian accounts. For Q3/4 of 2021 Atlassian is planning to add minimum security requirements for users with access to your products that are not part of your organization. We hope that they will prioritize this more.
• Data residency is also a big issue for some companies when looking at SaaS products. Last quarter Atlassian shipped a feature that allows to pin your data residency to so-called realms, which represent Global, EU or US. More locations are on the roadmap for 2022. Read more about this feature and its limitations here.
  An important note here is that marketplace app data is handled by the app vendors and not Atlassian when talking Cloud apps. It is essential that you either review the app vendors statements on data handling and residency or contact them about it, before subscribing to an app or even starting a trial.
• Performance. Overall the Cloud applications feel far less snappy if you are used to their Server or Data Center counterparts, provided that they are well-hosted of course. Atlassian is constantly improving the performance of their cloud offering and has come a long way since their first cloud release.

There are of course more pros and cons, but we believe we have covered the most important ones. For more information or help in migrating to the Cloud, feel free to contact us.

Switch to Data Center

Switching to Data Center is currently only possible if you choose for a 500 user tier or higher for Jira Software and/or Confluence. For Jira Service Desk, the Data Center user tiers start at 50 agents and for Bitbucket with 25 users. Bamboo currently doesn’t have a Data Center offering, but Atlassian promised to soon release one.

The main benefit of Data Center products of Server products are the High Availability (HA) options, disaster recovery and zero downtime upgrades as well as added features that are not available in Server products.

Atlassian has announced that they will not be offering lower user tiers for Data Center in the short run. They did, however, announce that Data Center is here to stay and will not be discontinued in the foreseeable future.

For more information on Data Center products, feel free to contact us.

Continue using unsupported Server products

Though this is the least preferable option for both Atlassian as yourself, it is still an option. You could keep using the server products if you have once purchased a valid license. The same applies to apps. The Server products are pretty reliable and if you make sure you stick to the Long Term Support (LTS) releases, this could extend your time before needing to migrate. Also, it saves a lot of money, because you won’t be paying license and support fees anymore. On the other hand, there are some huge risks involved when you choose this path:

1. You no longer have support from Atlassian or marketplace app vendors, which can lead to the following issues:
   1. Problems that you are unable to solve, will stay unsolvable. Atlassian or app vendors won’t help you troubleshoot, provide product fixes or workarounds. On February 2nd, 2024 Atlassian will stop all support for their Server products!
   2. If you encounter database issues, like corruption, you will be most likely forced to restore a backup. Make sure you backup both the database as the filesystem and use a trustworthy database and backup solution.
   3. Any security vulnerabilities will stay unfixed if you can’t fix them yourself by modifying your reverse proxy or tomcat configuration. You might not even be aware of any security vulnerabilities as they might not even be published anymore.
2. You will not be able to upgrade your user tiers. Atlassian will stop up- and downgrades in user tiers on February 2nd, 2022 for Server products. So be sure to you have a big enough user tier for all of your server products to accommodate your business’ growth.
3. You will not be able to install/use new apps as Atlassian will stop selling new app licenses for existing Server licenses on February 2nd, 2023. Be sure to have purchased all the apps you need before this date!

Note that we will never advise you to follow this path, but if you do, we are able to provide you with support on keeping your environment up and running.

Please contact us for discussing your options and concerns.

Jira’s October Release Highlights

Jira 8.12.3 and Jira Service Desk 4.12.3

On October 7th, Atlassian releases Jira 8.12.3 and Jira Service Desk 4.12.3. This bugfix release includes 5 low priority bugfixes, but two of those have a major and critical severity rating and there’s one security vulnerability with a medium severity rating.

• Reindex fails because of null pointer exception thrown by CustomFieldValues due to a NULL value (JRASERVER-71633) [LTS 8.13.0].
• Since Jira 8.12, system functionalities like editing permissions, starting scripts, are failing to pop up the modal window in the browser. This has been fixed in Jira 8.12.3 (JRASERVER-71747) [LTS 8.13.1]
• CVE-2020-14184: Since Jira 8.4 remote attackers are able to inject arbitrary HTML or JavaScript via a Cross-Site Scripting (XSS) vulnerability in Jira issue filter export files. This has been fixed in Jira 8.12.3 (JRASERVER-71652) [LTS 8.13.1]

Jira 8.13 LTS

Jira 8.13 is the latest LTS release for the Jira 8 platform. No features have been added compared to the Jira 8.12 feature release, but it includes all new features that were added to Jira since the now previous Jira 8 LTS release, Jira 8.5. Also, all the bugfixes included in this release are also present in the Jira 8.12.3 release. In fact, the Jira 8.12.3 release contains more bugfixes than the Jira 8.13.0 release. That’s why Atlassian released Jira 8.13.1 LTS on November 2nd, which will be covered next month.

If you are currently on the Jira 8.5 LTS release and plan on upgrading to this latest release, the following new features will be newly available:

• When upgrading Jira, you no longer need to manually backup/copy configuration customization. These will be automatically copied to the new instance.
• The Users and roles page within project settings is updated and allows for more efficiently assigning roles to users and groups. This page works similar to Jira Cloud implementation now.
• Wildcard prefix search is now available, where before only suffix search was available (*keyword vs keyword*)
• The Jira REST API has been extended to fully automate creating new projects with specific workflow schemes.
• Burn-up charts are now also available in Server instead of just Cloud. This allows you to keep teams on track with a visual representation of a sprint’s scope and identify problems such as scope screen or a deviation from the planned project path.
• DC: rate limiting has been added which basically giving your Jira instance the power to self-protect against huge bursts of requests from scripts and automated integrations. Admins can control how many REST API requests automations and scripts can make, and how often they can make them.
• Anonymizing users for GDPR compliance has been added to the user management section. It allows Jira administrators to permanently remove personal details from a user’s profile, so the profile becomes anonymous.
• The default behaviour of the Enable HTML in custom field descriptions and list values items option has been changed. It will now be switched to OFF for new Jira installations and the upgraded ones that have never used it. If you have modified this option, you shouldn’t be affected, but it is recommended to check it to make sure it’s set correctly for your instance. (System > General configuration).
• The whole audit log has been completely overhauled and some great new features are available now, especially when you are on Data Center (DC).
• Advance sprint planning has been improved! The improvements include setting dates for planned sprints and updates on the sprint reporting side.
• The Velocity Report page has been revamped, you will be able to choose any date range that you’re interested in. The report will calculate the average velocity of all sprints completed within the chosen period of time and display it both over the table and in the chart itself.
• Microsoft and Google are planning to disable Basic Authentication, hence Atlassian added OAuth 2.0 support to the incoming mail configuration.
• DC: a custom field indexing page has been added. 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.
• Finally, Atlassian made the issue detail view optional on the Kanban and Sprint boards, e.g. you can now choose if Jira should show the issue detail view when clicking on an issue on the board: click on the Board button in the upper right corner and select the Hide detail view from the options.
• Admins now have an option to enable restricted sprint selection for users. When restricted, users can only select sprints when creating or editing an issue that belongs to the project the issue belongs to. Great improvement! The option can be found in Jira Administration → Jira Software Configuration → Relevant sprints. Users are still able to select unrelated sprints, but it will require an extra step, making the sprint selection process less error-prone.
• Admins will be able to edit and delete private filters and dashboards. So admins will be able to see all existing filters and dashboards, whether shared or private and choose how to handle them.
• @mention email notifications have been improved to further reduce the amount of notification spam from Jira.
• The embedded crowd has been upgraded, count on performance and stability improvements and clustering support.
• The Single user picker custom field type has been improved and now has the same look and feel like the user system fields such as Reporter and Assignee, i.e. showing the user’s avatar and full name.

Jira Service Desk 4.13 LTS

The same applies to Jira Service Desk 4.13, no new features nor bug fixes have been added compared to JSD 4.12.3. The JSD 4.13.1 release, which was released on November 2nd, does contain 3 specific JSD bugfixes which will be discussed in next month’s edition.

Here’s a quick overview of new JSD specific features you can start using when you upgrade from JSD 4.5 LTS to the latest JSD 4.13 LTS:

• Request sharing will be shared by default if the customer belongs to only one organisation. A setting has been added to modify the default behaviour: Administration > Applications > Jira Service Desk configuration (Organization management).
• The in JSD 4.1 introduced new portal experience is now default.
• Jira Service Desk now comes with a multilingual customer portal and help center. Translations can be added to your service desk for the most important items, including portal names, request types, and announcements.
• Queues are now sortable by columns and these settings are saved in the agent’s profile.
• New REST endpoints have been added to manage queues.
• Next and previous buttons have been added to the bottom of search results in the portal. So instead of customers having to navigate back to the search results page to view the next search result, they can click the next button on the currently opened search result to see the next search result.
• Sign-up verification has been added so customers can be required to verify their email addresses. This makes sure all customers are exactly who they say they are. Learn more.
• How agents in certain roles are treated by Jira Service Desk has been changed. Until now, agents acting as approvers or belonging to the customer’s organization were seen as customers, which affected SLAs and automation rules; e.g. when an agent (“customer”) commented on a request, the clock kept on ticking and the request status didn’t change, which brought a lot of confusion to true customers.
• Bulk actions are now available from queues!
• Duplicate e-mail attachments in requests are a thing of the past. With JSD 4.8.0, duplicate e-mail attachments are now detected and ignored, keeping the customer’s requests nice and clean.
• Request participant field is now available for customers on the create issue request form in the customer portal.
• JQL functionality has been added to search for declined requests. Before, it was only possible to search for approved requests using “Approval = approved()”. With JSD 4.8.0 it’s also possible to search for declined requests using “Approval = declined()”.
• 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.
• The satisfaction comment (CSAT) is now searchable with JQL.
• DC: Data Center versions of JSD now have advanced auditing capabilities to areas that are specific to Jira Service Desk.
• It is possible to integrate Confluence Cloud as a Knowledgebase.
• It is also now possible to integrate Jira Service Desk with Opsgenie and set up incident management for individual projects. This allows service desk agents to view ongoing incidents, create new ones to alert the Opsgenie teams right away, and link incidents to related requests to give everyone involved more context.
• The organization field has become sortable using JQL.

Our advice

Due to Atlassian’s Journey to the Cloud announcement and deprecating Server products in the next 3 years. For all Server customers, we suggest to start making plans on where you want your Atlassian data to be in 3 years. TMC ALM can help you with this and analyse your current environment and discuss your possibilities.

In the meantime, we strongly advise all Server customers to start sticking to the LTS releases of Server products. These are the most reliable releases and will provide the best compatibility for Cloud and DC migrations. For Jira and Jira Service Desk, this means you should start planning an upgrade to Jira 8.13.1 and/or Jira Service Desk 4.13.1.

For apps, the same applies. Make sure you upgrade to the stable versions of apps that are compatible with your LTS release. Also, look out for apps that are currently Server only. If a migration to the Atlassian Cloud is an option for you, stop purchasing these apps until the vendor starts supporting the Cloud environment with the same functionality. Another important factor to take into consideration is the data residency of the Cloud counterpart of your current apps. Look it up or contact the app vendors in which location they host and process their customer’s data.

Confluence’s October Release Highlights

Confluence 7.8.1

Confluence 7.8.1 was released on October 12th. This bugfix release contains 4 bug fixes, 3 of which can be considered major. At the moment of publishing this blog, Confluence 7.8.3 has also been released (Confluence 7.8.2 was an internal release) and will be covered in next month’s edition.

• A huge bug that causes all sorts of blocking symptoms has finally been fixed but has yet to be backported to the Confluence 7.4 LTS release. Note that this bug has been around since 2011 (Confluence 3.5).
  There is a workaround available when you suffer from this bug, which can be viewed in the related KB articles or in the bug report: CONFSERVER-22390.
  Symptoms include:
  • Using Documentation Theme, the Left-Side Navigation Bar is Blank and the Page Tree is Missing
  • Unable to Edit in Office and Edit in Word
  • Comment Box Disappears: $soyTemplateRendererHelper.getRenderedTemplateHtml
  • Browser Title Shows $docThemeHelper Instead of The Page Title
  • Missing buttons or the entire top bar with “$soyTemplateRendererHelper.getRenderedTemplateHtml” error message
• An anchor link’s name changes to <page title>#<anchor link name> after editing the page with Collaborative Editing switched on or set to limited (CONFSERVER-51690).
• Since Confluence 7.5, so the 7.4 LTS release is not affected, when you delete a version of an attachment attached to a page, any labels added to the page will be automatically removed (CONFSERVER-60234).

Our advice

Due to Atlassian’s Journey to the Cloud announcement and deprecating Server products in the next 3 years. For all Server customers, we suggest to start making plans on where you want your Atlassian data to be in 3 years. TMC ALM can help you with this and analyse your current environment and discuss your possibilities.

In the meantime, we strongly advise all Server customers to start sticking to the LTS releases of Server products. These are the most reliable releases and will provide the best compatibility for Cloud and DC migrations. For Confluence, this currently means that Confluence 7.4.6 is the best bet. Which should be released anytime soon. If you upgraded already past Confluence 7.4, no worries and make sure you upgrade to the latest Confluence 7 LTS release when it becomes available. Do not forget to keep checking on new releases as these might fix important bugs and security vulnaribilities.

For apps, the same applies. Make sure you upgrade to the stable versions of apps that are compatible with your (LTS) release. Also, look out for apps that are currently Server only. If a migration to the Atlassian Cloud is an option for you, stop purchasing these apps until the vendor starts supporting the Cloud environment with the same functionality. Another important factor to take into consideration is the data residency of the Cloud counterpart of your current apps. Look it up or contact the app vendors in which location they host and process their customer’s data.

Bitbucket’s October Release Highlights

Bitbucket 7.7.0 and 7.7.1

At the time of publishing, Bitbucket 7.7.1 has become available. It includes 2 bug fixes and will be covered in next month’s blog.

A bunch of new features for Bitbucket with the release of feature release Bitbucket 7.7.0. These include:

• For both Server and DC it is now possible to draft multiple comments on files and code during a review process. Then when you are ready, send them all off at once, rather than just one at a time. This new code review workflow will save you time and unnecessary back and forth exchanges with the pull request author. Check out Commenting on a pull request for more details.
• Also regarding comments, it’s now possible to add reactions (like with social media) to them in Bitbucket.
• Bitbucket now supports Git 2.29 for server.
• Regarding accessibility,  a new setting for diffs that lets you switch to an accessible color option that uses blue and yellow for added and removed lines respectively. Once enabled, the colors will change immediately in the diff view.
• Bitbucket Server and Data Center now supports rendering of Jupyter notebooks. We recognize the need for developers and data scientists alike to be able to collaborate with their respective teams by sharing ideas that combine code, data, and visualizations. Want to jump right in and give it a try? Just commit a .ipynb file to a new or existing repository in Bitbucket to view the rendered notebook.
• DC only: A new Auto-decline pull requests option will increase productivity and optimize the performance of your Bitbucket Data Center instance by automatically declining inactive pull requests. This option is on by default and is set on individual repositories or all in a project.

A bunch of high priority bugs have been fixed as well, including:

• A long outstanding bug that, under certain conditions, updates to PR’s are falsely attributed to the wrong user (BSERV-9529) [LTS 7.6.1, 6.10.7].
• When trying to merge a pull request via a pull request, the user receives an error about merge conflicts even though there are no conflicts and automatic merging works in a local clone (BSERV-9709) [LTS 7.6.1, 6.10.7].
• When merging a pull request, the user received the message:1 New changes were pushed to <branch> in <project>/<repository> while the merge was being performed. Please retry the merge.While this is expected when a change occurs on the target branch during the merge, this can occur also when no changes are received (BSERV-11511) [LTS 7.6.1, 6.10.7].
• Pull requests get declined because of a gap in the pull request history (BSERV-11068) [LTS 7.6.1, 6.10.7].
• The pull request reviewer state for hidden reviewers does not show any state although the reviewers had either approve or decline(need work) the pull request (BSERV-12567) [LTS 7.6.1].
• The commits in the diff view of a pull request show a broken avatar for author committer (BSERV-12612) [LTS 7.6.1].
• Bitbucket Server 7.4 introduced changes which replace the use of blocking I/O for interacting with git http-backend, git receive-pack and git upload-pack with non-blocking I/O. The new approach appears to have performance issues unique to Windows which makes clones slower than they were with the previous blocking I/O code. This does not apply to Linux, where speed is unaffected. (BSERV-12599) [LTS 7.6.1].

Our advice

Due to Atlassian’s Journey to the Cloud announcement and deprecating Server products in the next 3 years. For all Server customers, we suggest to start making plans on where you want your Atlassian data to be in 3 years. TMC ALM can help you with this and analyse your current environment and discuss your possibilities.

In the meantime, we strongly advise all Server customers to start sticking to the LTS releases of Server products. These are the most reliable releases and will provide the best compatibility for Cloud and DC migrations. For Bitbucket, this means you should start planning an upgrade to Bitbucket 7.6.1 (covered in next month’s blog).

For apps, the same applies. Make sure you upgrade to the stable versions of apps that are compatible with your (LTS) release. Also, look out for apps that are currently Server only. If a migration to the Atlassian Cloud is an option for you, stop purchasing these apps until the vendor starts supporting the Cloud environment with the same functionality. Another important factor to take into consideration is the data residency of the Cloud counterpart of your current apps. Look it up or contact the app vendors in which location they host and process their customer’s data.

Bamboo’s October Release Highlights

Bamboo 7.1.3

Bamboo 7.1.4 was released on November 3rd, so before this article was published. It contains 2 major and 2 minor bugfixes and will be discussed in the next edition of this blog series.

Bamboo 7.1.3, released on October 15th, contains the following noteworthy features and bugfixes:

• The Github plugin now supports personal access token. Note that Github password authentication will fail from November 13th onwards!
• Users without admin permissions are now able to link Jira issues to test results.
• The list with linked repositories is finally sorted alphabetically instead of chronologically by creation time.
• Editing branch variable values in Bamboo ends up changing another variable value (BAM-21054).

Our advice

The same advice applies as in last month’s edition. If you are not on Bamboo 7.1.0 or higher, Bamboo 7.1.4 is a stable release to upgrade to. Else it is probably not worth the time and effort.

If you are upgrading from Bamboo 6, test it thoroughly first and involve your key users. Don’t forget to test your most important build and deployment plans.

Note that Bamboo does not have a Data Center offering yet, but Atlassian promised to provide one in the near future. This will probably also mean an LTS release for Bamboo.

Thanks for reading!

Read our blog Upgrade Best Practices for stress-free upgrades or contact us if you have support, migration or any other questions regarding Atlassian tooling or integrations.