JIRA Software 7.6.x upgrade notes

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Here are some important notes on upgrading to JIRA Software 7.6. For details of the new features and improvements in this release, see the JIRA Software 7.6 release notes

JIRA Software 7.6 is an Enterprise release
This means we'll provide bug fix releases until 7.6 reaches end of life, to address critical security, stability, data integrity, and performance issues. 
Ready to upgrade? Check out the JIRA Software 7.6 Enterprise Release change log for a roll-up of changes since 7.2. 

Upgrade notes


Upgrade to the DVCS plugin

If your Jira Software Server or Data Center instance is connected to Bitbucket Cloud, it’s through the Jira DVCS connector plugin.

Due to GDPR regulations and the personal data protection they require, we've needed to make some changes to the API's that Bitbucket Cloud has available. These changes happen in two phases. Phase one will be live on Bitbucket Cloud by the 10th of May, 2019, and Phase two will go live on the 1st of September, 2019.

What you need to do as a result is to upgrade your Jira Software instance or upgrade your Jira DVCS connector plugin to the relevant version. For more information, see Jira KB

Apache Tomcat upgrade

In JIRA 7.6.9, we've upgraded Apache Tomcat from 8.5.6 to 8.5.29. 

Fix: Duplicated job IDs

In JIRA 7.6.2, we’ve delivered a fix to solve the problem with duplicated job IDs. You can read more about the related bug here:  JRASERVER-64325 - Getting issue details... STATUS

How does the fix work?

When finalizing the upgrade, an upgrade task removes the duplicates from the database (clusteredjob table), and then recreates the whole clusteredjob_jobid_idx index, also adding a UNIQUE keyword to it. This removes the duplicates and prevents them from being created again.

Known issue

The fix will work for most environments, but we did encounter an issue on one of our test machines. The problem appears when a new duplicate is created after we remove the duplicates, but before we recreate the index. In other wordsbefore we block the duplicates from being created. Such a duplicate would stop the index from being recreated.

Solution

If the index is not recreated, it won’t stop the upgrade or affect your work in a significant way (might degrade performance). We recommend, however, that you apply the following solution to recreate the index.

  • Check that the clusteredjob_jobid_idx index exists in your database.
    (tick) If it's there, you're good to go. The index was properly recreated.
    (error) If it's not there, restart your JIRA instance (Server), or one of the nodes (Data Center). After the restart, the index will be recreated.

Known issue: DVCS might fail after the upgrade (Microsoft SQL Server)

We've found a bug that makes DVCS fail when you upgrade from JIRA 7.4 to JIRA 7.6 - 7.6.2, only on environments using Microsoft SQL Server. For more info, see  JSWSERVER-16243 - Getting issue details... STATUS

We have fixed this issue in JIRA 7.6.3.

Priority schemes (UI changes)

Although we've made significant changes to how priorities are managed in JIRA, these changes won't affect your current configuration. Currently, your JIRA instance is using a global list of priorities. After the upgrade, all these priorities will be moved to the default priority scheme, which works in the same way. Until you create new schemes and make use of them (by associating with some projects), everything stays the same.

Priority schemes (API changes)

We encourage everybody to get familiar with these changes, but they're more important for plugin developers rather than JIRA admins. The APIs that would allow JIRA admins to manage priority schemes outside of the user interface will not be available in JIRA 7.6.

If you're a plugin developer and want your plugin to manage priority schemes, take a look at this list of API changes. We've not only added new APIs that allow plugins to manage priority schemes, but we also changed the existing ones, which will most likely make your plugins incompatible. This is for priority schemes, the APIs for managing priorities don't change, but bear in mind that the current global list of priorities now becomes the default priority scheme, so your plugins might retrieve inaccurate data regarding priorities themselves. 

What's new?

We're adding these APIs to allow plugins to manage priority schemes. 

Show me the changes...
Classname Method signature Javadoc
com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

FieldConfigScheme createWithDefaultMapping(String name, String description, List<String> optionIds);

Doc

FieldConfigScheme updateWithDefaultMapping(FieldConfigScheme fieldConfigScheme, List<String> optionIds);

Doc

FieldConfig getFieldConfigForDefaultMapping(FieldConfigScheme fieldConfigScheme);

Doc

void delete(FieldConfigScheme fieldConfigScheme); Doc

FieldConfigScheme getScheme(Project project);

Doc

FieldConfigScheme getScheme(Long id);

Doc

List<FieldConfigScheme> getAllSchemes(); Doc

boolean isDefaultScheme(FieldConfigScheme fieldConfigScheme); Doc

FieldConfigScheme getDefaultScheme(); Doc

String getDefaultOption(IssueContext issueContext); Doc

String getDefaultOption(FieldConfig fieldConfig); Doc

void setDefaultOption(FieldConfig fieldConfig, String optionId); Doc

List<String> getOptions(IssueContext issueContext); Doc

List<String> getOptions(FieldConfig fieldConfig); Doc

void setOptions(FieldConfig fieldConfig, List<String> optionIds); Doc

void addOptionToDefault(String optionId); Doc

void removeOptionFromAllSchemes(String optionId); Doc

Collection<FieldConfigScheme> getAllRelatedSchemes(String optionId); Doc

void assignProject(@Nonnull FieldConfigScheme priorityFieldConfig, @Nonnull Project project); Doc

Set<Project> getProjectsWithScheme(@Nonnull FieldConfigScheme fieldConfigScheme); Doc

void unassignProject(@Nonnull FieldConfigScheme scheme, @Nonnull Project project); Doc


We're also adding new events for whenever a priority scheme is created, updated, or deleted.

Classname Event Javadoc
com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager com.atlassian.jira.event.issue.fields.config.manager.PrioritySchemeCreatedEvent Doc

com.atlassian.jira.event.issue.fields.config.manager.PrioritySchemeDeletedEvent

Doc

com.atlassian.jira.event.issue.fields.config.manager.PrioritySchemeUpdatedEvent Doc
What's changing?

Some APIs also receive additional options, so that priorities are added or removed from priority schemes.

Show me the changes...
Classname Method signature Change Javadoc
com.atlassian.jira.config.PriorityManager createPriority In addition to creating a priority, also adds this priority to the default priority scheme. Doc

removePriority In addition to removing a priority, also removes this priority from all priority schemes. Doc
What's deprecated?

These APIs are deprecated, and replaced by the new PrioritySchemeManager class.

Show me the changes...
Classname Method signature Replacement Javadoc
com.atlassian.jira.config.PriorityManager setDefaultPriority

com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

#setDefaultOption(FieldConfig, String)

Doc

getDefaultPriority

com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

#getDefaultOption(IssueContext)

Doc
com.atlassian.jira.config.ConstantsManager getDefaultPriority

com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

#getDefaultOption(com.atlassian.jira.issue.context.IssueContext), or

com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

#getDefaultOption(com.atlassian.jira.issue.fields.config.FieldConfig)

Doc

Content-Security-Policy and X-Frame-Options headers

To prevent clickjacking, JIRA will add the X-Frame-Options and Content-Security-Policy security headers to each HTTP response. The headers will block the content from being embedded in iframes, which might also affect pages that you actually wanted to be displayed this way. If you embed any resources from JIRA on other sites (e.g. dashboards), they might not work after the upgrade. To fix this, you can either disable this feature, or choose resources to be excluded from receiving the security headers. Learn more

Upgrade procedure

Note: Upgrade to a test environment first. Test your upgrades in your test environment before rolling them into production.

If you're already running a version of JIRA, please follow these instructions to upgrade to the latest version:

  1. Before you upgrade, we strongly recommend that you back up your installation directory, home directory, and database.
  2. Read the release notes and upgrade guides for all releases between your version and the latest version.
  3. Download the latest version of JIRA.
  4. Follow the instructions in the Upgrade Guide.

Upgrading from earlier versions?

  • 7.0, or later
    Take a look at the upgrade matrix. It lists known issues you should be aware of when upgrading between multiple versions.

  • Earlier than 7.0
    Consult the Migration hub. The JIRA 7.0 release introduced significant changes. You must first upgrade to JIRA 7.0 (we always recommend the latest bugfix release, in this case 7.0.11) before upgrading to later versions.
Last modified on Aug 5, 2019

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.