Preparing for JIRA 6.4
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.
On this page:
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?||Risk level||What is affected?||Details|
|JIRA Report Plugin Module changes||6.4||LOW||Plugins that expose Reports||See JIRA Report Plugin Module below|
|NewLicenseEvent deprecated in favor of LicenseChangedEvent||Deprecated in 6.4 and to be removed in 7.0||LOW||Plugins that listen to NewLicenseEvent||See License event renamed below|
|The way JIRA and AUI messages are rendered is changing||
6.4-m09 (JIRA EAP)
|See Message rendering changes below|
|JIRA File based APIs for attachments deprecated||6.4||MODERATE||
|See JIRA File based APIs for attachments deprecated below|
|JIRA project-centric view||6.4||MODERATE||Plugins that use project navigation.||See Design guide - JIRA project-centric view|
|Dropped support for Jelly scripts||6.4||MODERATE||Instances using this feature.||See the end of support announcement|
|Send Head Early for Dashboard and IssueNav||6.4||MODERATE||
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.
|See Send Head Early for Dashboard and IssueNav below|
Detailed Explanations of Changes
In this section:
JIRA Report Plugin Module
In JIRA 6.4 reports are grouped in 4 categories:
Each report can be placed in a category. When no category is provided, the report will be placed in "Other".
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:
Corresponding web resources should be placed in context
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
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):
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:
The following REST endpoint can be used to reset dismissals for a given flag:
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
.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.
All methods that accepted
java.io.File are now deprecated, new methods that accept
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
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.)