Welcome to the March 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, the major highlights are Bamboo and Bitbucket. It’s been almost 4 months since the last Bamboo update and this month Atlassian released a new platform release, Bamboo 7! And guess what, Atlassian also released a new platform release for Bitbucket.
Also note that as of March 31st 2020, Atlassian no longer supports Internet Explorer for all of their products. This includes Cloud, Server and Data Center products. What this means exactly, can be found here.
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.
Jira’s March Release Highlights
With Jira 8.8, Atlassian introduces some cool new features and updates for Jira Server. Please find an overview of some of these features and updates below:
The whole audit log has been completely overhauled and some great new features are available now, especially when you are on Data Center (DC):
- Coverage you can select which events should be logged or not (Base/Off) and if you are on DC, you can select on which levels (Off, Base, Advanced, Full) these events are logged. Available events are:
- Global configuration and administration
- User management
- Local configuration and administration
- End-user activity
- The log retention period can be set to several years, but there’s a limit of 10 million records.
- Events can be filtered by user, project and date and be searched through on keyword. The overview is pretty slick and results can be expanded for more details.
- Exporting has been enhanced. You can export the last 100.000 records and if you are on DC, you can export a filtered list of 100.000 records.
- Delegate access to project admins. Unfortunately for DC only. Jira admins can give project admins limited access to the audit log, which could save themselves some valuable time.
- Integration with SumoLogic, ELK, Amazon CloudWatch and Splunk is now made available for Jira DC instances. Read more about audit log integrations…
Advance sprint planning has been improved! The improvements include setting dates for planned sprints and updates on the sprint reporting side:
- actual sprint start and completion dates have been added.
- burnup and burndown charts are from now based on the actual start date and planned completion date of the sprint. This used to be the planned start date, which made the reports sometimes useless.
Improved accessibility for the colour blind. Users can now select to pattern status categories, i.e. To Do, In Progress and Done. Additionally, there is an option to underline links.
Also, a bunch of bugs have been fixed, these are the most interesting ones:
- Velocity reports are now able to show sprints from other boards if the issues were moved between active sprints and not in the planning phase. This can be configured per board. Also, issues moved between projects will no longer contain closed sprints from the previous projects. (JSWSERVER-13783).
- Since Jira 8.5 when a default resolution was set in Jira, creating issues through Portfolio plans resulted in new issues having a resolution date but no actual resolution set. This has been fixed in Jira 8.8.0 (JRASERVER-70656).
- With the introduction of Jira 8, importing workflows from the marketplace fails. This has been fixed in Jira 8.8.0. It was still possible to download and install the workflow manually (JRASERVER-69051).
Jira Service Desk 4.8.0
As always, when Jira Software gets a new release, Jira Service Desk (JSD) gets one too. Next to the features and bugs fixes listed above, this JSD release includes some JSD specific new features as well. Including:
Bulk actions are now available from queues! Which means you can select multiple issues and perform one of the following actions on them at once:
- Assign issues to a different user
- Watch / Stop watching selected issues. This requires that watching is enabled in your Jira instance.
- Delete selected issues
- Add an internal or external comment to your issues. Adding a comment to 50 issues at once might take some time, so watch out for this.
- Link selected issues to other issues
Duplicate e-mail attachments in requests are a thing of the past. With JSD 4.8.0, duplicate e-amail 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 most interesting bugfixes for JSD specifically in this release are:
- When adding an attachment via the backend, no comment is entered and the comment is shared with the customer, the attachment is not visible for the customer. This is fixed in JSD 4.8.0 (JSDSERVER-6706).
- Service Request with approvals through the customer portal on JSD Server 4 up to 4.8, the approval button will fail if the workflow status has the “jira.issue.editable = false” property set. Fixed in JSD 4.8.0 (JSDSERVER-6650).
Both Jira Software and Jira Service Desk received some nice improvements and bug fixes. If you haven’t updated Jira to 8.8.0 yet, as advised in last month’s edition of this blog, please do so now.
For Enterprise release customers, Jira 8.5.4 was released on March 19th and we strongly encourage you to upgrade to Jira 8.5.4 due to the various security vulnerabilities that have been fixed in this release.
Data Center is getting more and more great features and advantages over Server. If you are interested in what value switching to Data Center can add to your business, please get in touch! We are more than willing to inform you!
Confluence’s March Release Highlights
Confluence 7.3.3 and 7.3.4
Confluence 7.3.3 and 7.3.4 are both bugfix releases, counting a total of 8 bug fixes and most of those are minor. The interesting ones:
- Since Confluence 7.2.1, the import Word document functionality is sensitive for malformed documents, which could make the Confluence application unavailable (denial of service). This issue is fixed with Confluence 7.3.3. This fix also hints to the first Confluence 7 Enterprise release, which we guess is probably Confluence 7.5 (CONFSERVER-59372).
- An unlikely bug concerning user groups and page restrictions has been fixed and was also backported the latest Enterprise release (6.13.11). Using the name “mygroup, more” or “mygroup\, more” for an external group as a ‘page restriction’ (view or edit), does not allow the group to use those permissions (CONFSERVER-13800).
- The Application links plugin used in Atlassian Confluence Server and Data Center before version 6.13.11, and from version 6.14.0 before version 7.3.3 allows remote attackers with administrator privileges to edit existing application links without passing WebSudo via an improper authorization check. See https://ecosystem.atlassian.net/browse/APL-1391 for more details (CONFSERVER-59612).
- The new Inspect permissions feature, introduced with Confluence 7.3, does not respect nested groups. This also applies to the “people who can view” feature. This has been fixed in Confluence 7.3.4 (CONFSERVER-59513).
- Since Confluence 7, the preview macros for PDF and PowerPoint sometimes stop working after a while. Fixed in Confluence 7.3.4 (CONFSERVER-58957).
The advice from last month’s edition still counts; if you are already on Confluence 7 then Confluence 7.3.4 is a highly advisable release to upgrade to, as some long-running and known Confluence 7 bugs have been fixed. This also applies to customers still on Confluence 6 and not tied to Enterprise releases.
For the ones who are tied to Enterprise releases, Confluence 6.13.11 has been released on March 18th but does not contain critical fixes IF you are already on Confluence 6.13.10. If you aren’t, you should upgrade to Confluence 6.13.11 immediately.
Bitbucket’s March Release Highlights
Some of the upcoming changes for the new Bitbucket 7 platform release we already discussed in the December 2019 edition of this blog series. Now that Atlassian released Bitbucket 7 into the wild, let’s discuss the full list of features, improvements and bug fixes.
Bitbucket 7.0.0 and 7.0.1
First of all, pull requests. A lot (read A LOT!) has been changed and improved in the pull request workflow:
Unified diff view
- Syntax highlighting has been added
- Content loading while switching between diffs has been made almost twice as fast.
- You can now comment anywhere in the diff, including on expanded lines of code that weren’t changed as a part of the pull request.
- And you can comment on files stored via Git LFS.
- Word wrap has been added, so no more horizontal scrolling to read lines of code in the diff. Sometimes this even caused the end of the sentence to be cut off.
- Show all lines of code with the show more option and not just 10 at a time.
- Browser search (Ctrl+F) is now supported in the diff view.
- Images in comments will from now on be at a thumbnail size instead of the original resolution.
- Pasting code in a comment will from now on automatically be formatted as a code block.
- When you type into a comment or description editor in a PR, you’ll see Markdown hints as you type, no need to preview until you’re ready to see the final view.
Side-by-side diff view
- Smooth scrolling has been added to the side-by-side diff. Here you can see a before and after comparison:
- Before, when copying code, from one side of the diff, the code on the other side was also copied. This has been changed, now only the selected code will be copied.
File navigation improvements
- The performance of file navigation has been greatly improved.
- The icons in the file tree received an update
- A filter has been added to the file tree to easily find changed files:
Example of new filter functionality in the file tree
- As of Bitbucket 7, a new task can be created without creating a new comment first.
- Comments can be converted to tasks.
- Tasks now also support text formatting and rich content.
Secondly, code coverage has been added to Code insights. This allows you to check which lines of code might not be or only partially be covered by tests.
Just like with Jira, auditing has been greatly improved! Some very welcome improvements have been added:
- There is now a global audit log is available that covers everything in Bitbucket and not just one project or repo. An audit log on a project- and repo-level is also still available.
- You can control what is and isn’t logged and on what level events are being logged. Just like with Jira, there is a limitation for Bitbucket Server compared to Bitbucket Data Center. For Server, the available levels are Off and Base. For Data Center the levels Advanced and Full are also available.
- The audit log is searchable, filters are available and events can be expanded for more details.
- Up to 100.000 records can be exported and for Data Center, again just like with Jira, you can export the latest 100.000 filtered records.
A new webhook has been added that gets triggered when the source branch of a pull request is updated.
The 3-way diff for pull requests is replaced by a 2-way diff in Bitbucket 7.0. This means that from 7.0 onward when viewing a pull request, the diff shown is a diff between the tip of the source branch and its common ancestor with the target branch. As a result of this switch, you’ll see the following primary changes:
- Pull requests will no longer visualize conflicts. The UI will still indicate when a pull request has conflicts, but they will no longer be marked up in the diff.
- Equivalent changes will not be “hidden”. If two different commits make the same change, a 3-way diff shows nothing (since it’s done the merge and knows nothing has changed), but a 2-way diff will still show the change.
- Lower CPU load. The processing required for a 2-way diff is substantially less than the requirements for a 3-way diff.
A lot of changes have been made to the Bitbucket APIs. We will not cover these in detail, but if you make use of audit, attachment or pull request functionality in the Bitbucket API, please check the API changelog here.
Last, but not least, Atlassian chose to enforce supported operating systems. This means that Bitbucket will fail to start if you are not running it on a supported operating system. Please upgrade a sandbox environment to Bitbucket 7 before you perform the upgrade on your production environment. Check out Bitbucket’s supported platforms for more details.
Concerning the bug fixes, again a lot are included as is expected with a platform release. Here’s a quick overview of the most important ones:
- When retrieving pull-requests diff using the REST API, the JSON response is truncated, resulting in incomplete data (BSERV-12035). This fix has also been backported to Bitbucket 6.7.5, 6.8.4, 6.9.3 and 6.10.2 (NOT the latest Enterprise release).
- Bitbucket 6.10.x (the Enterprise release) uses a Spring Framework plugin version that contains a security vulnerability. More info can be found in CVE-2020-5398. For Bitbucket 7, the Spring Framework plugin has been updated to a version that doesn’t contain this vulnerability. Unfortunately, Atlassian is unable to update the Spring Framework plugin in the current Enterprise release due to the unavailability of Service Mix Spring OSGi bundles for Spring Framework 5.1.13. The following issue in the Apache issue tracker requests this an update: https://issues.apache.org/jira/browse/SM-4320.
- Bitbucket 7.0.1 contains two fixes.
The first fix is to be able to start Bitbucket in an environment where outbound connections are not allowed. This seems to be an often recurring bug.
The second fix concerns Data Center and fixes a problem with mirror sites where the synchronisation fails due to a too aggressively set timeout. This has been fixed in Bitbucket 7.0.1 but has also been backported to Bitbucket 6.7.5, 6.8.4, 6.9.3 and 6.10.3 (the latest Enterprise release).
On March 24th, Atlassian released the first feature release for the new Bitbucket 7 platform, Bitbucket 7.1. Basically, one new feature got added, the push log. A repository admin can quickly see how the branches in a repository have changed over time. It includes details like who, when, and how the change took place, for example; pushing new commits, merging a pull request, and editing a file in a browser.
A nice addition is the ability to filter on branches and even deleted branches:
Also, two bugs have been fixed in this release:
- If a branch permission is created at the project level, a user will be unable to edit the branch permission if the branch name that was entered can be interpreted as a number (BSERV-12201).
- Creating a pull request with a Jira issue key at the end of the pull request title, the last characters following the Jira key disappear (BSERV-12246).
We always advise our customers to wait for the first bugfix release from the first feature release when upgrading to a new platform release, which in this case would be Bitbucket 7.1.1 (not available yet). We do suggest you give Bitbucket 7.1.0 a try on your staging environment. Practice the upgrade, check out the new features and changes. Especially the replacement of the 3-way diff with the 2-way diff might be something you need to inform your users about.
When 7.1.0 has been running stable for a week or so and you have tried out everything that has been changed/improved, first check if the bugfix release is available yet. Else, you could consider updating your production environment.
For Enterprise release customers the latest Enterprise release at the moment of writing is 6.10.2, but 6.10.3 is just around the corner and contains an important fix for Data Center customers. We suggest you wait for Bitbucket 6.10.3 if you are on Data Center. If not, please read the Bitbucket 6.10.2 release notes if upgrading is necessary for your use case as no critical fixes are included in this release.
Bamboo’s March Release Highlights
Bamboo 7.0.0 and 7.0.2
We were already hoping for a Bamboo platform release back in the December 2019 edition of this blog series and it’s already here! Out of nowhere, after almost 4 months of Bamboo release inactivity, Atlassian drops a new platform release, Bamboo 7. A week after the 7.0.0 release, the second bugfix release has also been released, Bamboo 7.0.2. Let’s see what’s in store:
Atlassian focusses on the “Specs branches”. Sounds interesting right? What this means is that from Bamboo 7 onwards, you’ll able to create your custom Bamboo Specs configuration for every branch regardless of the configuration for the master branch. All your feature branches, release branches, and unstable branches with your quirky code will be able to coexist in a happy mixture. There are some prerequisites though:
- You must be using Bamboo Specs to configure plan branches.
- Your code and Bamboo Specs must be stored in the same Bitbucket Server repository, at the same level as the bamboo-specs folder.
- In Bamboo, your repository must be configured as a linked repository of the Bitbucket type.
- Bamboo must have plan branch detection enabled (it’s turned on by default in Bamboo).
And some limitations as well:
- Plan branch configuration is not available for deployment projects. Bamboo ignores any Bamboo Specs on deployment projects in plan branches.
- The Other tab, along with all its options, is not available in the plan configuration screen for divergent branches.
- When Specs branches, you can’t link any repositories additional to those on the master branch. You can change the configuration of that repository but you can’t add or remove it.
- To create a new plan on your Specs branch, you must first create it on the master.
- Default settings from Automatic branch detection configuration, like triggers and notification settings, are ignored by Bamboo Specs branches.
- The default repository of a Specs branch is inherited from the master branch and it’s not possible to select a different repository on your Specs branch.
- In regular feature branches, you can only define one trigger and inherit other triggers or inherit triggers from the master. When using Specs branches, you can define multiple triggers.
Other features and improvements include:
- The agent UUID is now visible in the agent’s details tab, finally!
- The Bamboo look and feel is customizable, like Jira and Confluence.
- MSSQL 2017 and Oracle 19c are now officially supported.
- The catalina.out log wasn’t configured for rotation, which could lead to excessive file sizes and problems creating support zips for example.
- It’s now possible to add a checkout task which accepts linked repository and allows to specify the destination folder and property if clean checkout is forced with YAML Bamboo Specs.
- For YAML Bamboo Specs it’s now possible to define notifications for build plans. This used to be only possible for deployment plans.
- Also for Bamboo Specs, it’s now possible to set labels with specs code.
- The Docker task now finally supports passing build arguments.
- Credentials for Docker Pull/Push tasks will now be stored encrypted. These used to be stored in plain text in the database.
- The Bamboo agent wrapper (Tanuki Java service wrapper) has received another update to version 3.5.41.
Next to these, a whole bunch of bugs have been fixed as well, including:
- As of Bamboo 7.0, passwords defined as global and plan variables are no longer stored as part of the build result, which means, that upon restart, the current value of those variables is used (BAM-12930).
- It used to be possible to create duplicate project keys with concurrent Bamboo Specs pushes. This is fixed with Bamboo 7 and onwards (BAM-20610).
- If Bamboo Specs contains the AllOtherPluginConfiguration configuration, it will successfully publish the initial push. However, any subsequent changes to the code and resulting pushes will not successfully run the specs (BAM-20441).
- From Bamboo 7 onwards, it is possible to secure the remote agents to connect to the Bamboo Server (using SSL) using the automatic keystore management feature (BAM-20521).
- Passwords in the VARIABLE_CONTEXT and VARIABLE_BASELINE_ITEM database tables will from now on be stored encrypted (BAM-18346).
This platform release contains really nice feature improvements and additions. Also, a lot of bugs have been fixed.
As the upgrades for the Bamboo platform are very scarce, we suggest you give Bamboo 7.0.2 a try on your staging environment. Practice the upgrade, check out the new features and changes. Test it thoroughly, involve your key users and test your most important build and deployment plans. After a week or two, evaluate if you and your key users feel confident about upgrading the Bamboo production environment to this release.
Thanks for reading and above all, we wish all of you good health!
Remember to contact us if you have any (support) questions.