Last updated Mar 22, 2024

Preparing for JIRA 6.4

Overview

This page is to inform JIRA plugin developers of changes in the upcoming JIRA 6.4 release that could affect their plugins. JIRA users should consult the documentation here.

It is our intention to notify you, our plugin developers, as far in advance as possible of everything we know that could possibly affect your plugins. Where possible, we will attach release targets. EAP releases are available on the JIRA Early Access Program Downloads page.

We will update this page as the release progresses, so please watch this page or check back regularly to keep on top of the changes.

Summary of changes

The risk level indicates the level of certainty we have that things will break if you are in the "What is affected?" column and you don't make the necessary changes. The changes listed in this section affect only Plugins 2 (not Atlassian Connect).

What is the change?When will this happen?What is affected?
JIRA Report Plugin Module changes6.4

Plugins that expose Reports

Risk level: low

Details: See JIRA Report Plugin Module below

NewLicenseEvent deprecated in favor of LicenseChangedEventDeprecated in 6.4 and to be removed in 7.0Plugins that listen to NewLicenseEvent

Risk level: low

Details: See License event renamed below

The way JIRA and AUI messages are rendered is changing

6.4-OD-09 (Cloud)

6.4-m09 (JIRA EAP)

Plugins that:

  • use JIRA.Messages to display messages; and
  • use hardcoded AUI messages markup (rather than the provided templates).

Risk level: low

Details: See Message rendering changes below

JIRA File based APIs for attachments deprecated6.4

Plugins that:

  • store attachments in JIRA; and
  • plugins that use TemporaryAttachmentsMonitor to upload temporary attachments and want to convert them to normal attachments.

Risk level: moderate

Details: See JIRA File based APIs for attachments deprecated below

JIRA project-centric view6.4Plugins that use project navigation.

Risk level: moderate

Details: See Design guide - JIRA project-centric view

Dropped support for Jelly scripts6.4Instances using this feature.

Risk level: moderate

Details: See the end of support announcement

Send Head Early for Dashboard and IssueNav6.4

Plugins that manipulate the HTTP response (changing the HTTP status code, setting headers, etc) - either directly or indirectly - while the Dashboard, Issue Navigator or View Issue page is loading.

Risk level: moderate

Details: See Send Head Early for Dashboard and IssueNav below

Detailed Explanations of Changes

In this section:

JIRA Report Plugin Module

Elements

NameDescription
category

In JIRA 6.4 reports are grouped in 4 categories:

  • Agile - agile
  • Issue analysis - issue.analysis
  • Forecast & management - forecast.management
  • Other - other

Each report can be placed in a category. When no category is provided, the report will be placed in "Other".

1
2
<category key="forecast.management" />

Required: -

thumbnail

In JIRA 6.4 reports will have the ability to provide a thumbnail, which will be displayed on the reports page. Thumbnails are controlled by css class, which can be defined in the Plugin Report Module and must have the dimensions of: 268px x 138px

Corresponding web resources should be placed in context com.atlassian.jira.project.reports.page.

1
2
<thumbnail cssClass="report-css-class" />

Required: -

url

url element can contain the provider attribute which points to the class which will provide URLs for the given report depending on the context in which the report is presented. The class has to implement the com.atlassian.jira.plugin.report.ReportUrlProvider interface.

1
2
<url
  provider="com.atlassian.sample.plugin.MyUrlProvider" />

Required: -

License event renamed

com.atlassian.jira.license.NewLicenseEvent is scheduled to be replaced by com.atlassian.jira.license.LicenseChangedEvent in 7.0. This is to not only support new licenses but also updated and removed licenses. The new class LicenseChangedEvent has been introduced in 6.4 to allow for easier migration. NewLicenseEvent extends LicenseChangedEvent, so listeners should listen for LicenseChangedEvent where possible. In JIRA 6.4, all raised LicenseChangedEvents are also NewLicenseEvents, so there is no functional difference between listening to either one.

Message rendering changes

Message icons

AUI message containers now have an associated icon added via a CSS pseudo element, implemented as an icon font character. Including a hard coded icon ( e.g. <span class="aui-icon icon-info"></span> ) in your AUI message markup will result in a double icon effect:

Please use the AUI-provided message templates for building message markup, e.g. (as part of a soy template):

1
2
{call aui.message.info}
    {param closeable : false /}
    {param content}
        <p>Message content</p>
    {/param}
{/call}

For more information, please see AUI Messages.

JIRA messages & flags

Using the JIRA.Messages (or 'jira/message' via AMD) methods to show a global message will now result in an AUI flag being displayed. Methods for displaying a message inside a target element will work the same as before. JIRA.Messages is deprecated and slated for removal in 8.0, though, so please prefer either 'jira/flag' or 'aui/flag' modules (obtained via the global require() method).

'jira/flag' adds the option to prevent flags from being re-shown once dismissed, by providing a dismissalKey like this:

1
2
flag.showMsg('Title', 'Body', { dismissalKey: 'dismiss.me' })

The following REST endpoint can be used to reset dismissals for a given flag:

1
2
JIRA.SmartAjax.makeRequest({type: 'PUT', url: '/rest/flags/1.0/flags/dismiss.me/reset'});

JIRA File based APIs for attachments deprecated

Since JIRA 6.4 only stream based API should be used for manipulating attachments. Plugins should also not depend on structure of directories on the file system and should not assume that attachments are files stored on local files system. 

To read attachments you should use  com``.atlassian.jira.issue.AttachmentManager#streamAttachmentContent which accepts InputStreamConsumer that should be used to process stream of attachment content. You should never attempt to buffer/store content of attachments in memory.

Deprecated classes/method

AttachmentManager

All methods that accepted java.io.File are now deprecated, new methods that accept CreateAttachmentParamsBean with InputStream where added. New added methods does not throw exceptions in case of error but rather return Either<AttachmentError, ChangeItemBean> which defines result of the operation. 

TemporaryAttachmentsMonitor and WebAttachmentManager

You should be using TemporaryWebAttachmentManager instead to store temporary attachments in user session. Please note that attachments previously where identified by integer id, now they are identified by TemporaryAttachmentId which contains string id.

In regard to clearing temporary attachments, only a part of previous behavior was preserved. Temporary attachments are still automatically cleared when the user session expires.

Previously, a common practice was to identify a set of temporary attachments by issue id when attaching to an existing issue or by project id when attaching to a new issue. The server then could clear all attachments associated with such issue, e.g. when displaying a new "edit issue" or create issue" form. Such behavior interfered with multiple simultaneous forms. In order to isolate forms, it is recommended to generate a unique token for each form via XsrfTokenGenerator and pass it to TemporaryWebAttachmentManager methods: createTemporaryWebAttachment or clearTemporaryAttachmentsByFormToken.

Send Head Early for Dashboard and IssueNav

JIRA's Dashboard, Issue Navigator and View Issue pages now employ the "Send Head Early" performance optimization strategy. Instead of constructing the HTML response in a buffer and only sending it when complete, they optimistically send HTTP 200 OK, all HTTP headers, and the start of the HTML page (most of the <head> section) as early as possible. This has the benefit of allowing the client to start loading and parsing resources referenced in the <head> section early, in parallel with server-side page construction. It also means that the HTTP response is committed much sooner - code that modifies the HTTP response during page construction is likely to cause a  "java.lang.IllegalStateException: Response already committed" exception in JIRA 6.4. This may happen indirectly. For example: an attempt to redirect (implies modification of the HTTP status code); an attempt to set a cookie (implies modification of the HTTP headers.)

Rate this page: