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.
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 changes | 6.4 | Plugins that expose Reports Risk level: low Details: See JIRA Report Plugin Module below |
NewLicenseEvent deprecated in favor of LicenseChangedEvent | Deprecated in 6.4 and to be removed in 7.0 | Plugins 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:
Risk level: low Details: See Message rendering changes below |
JIRA File based APIs for attachments deprecated | 6.4 | Plugins that:
Risk level: moderate Details: See JIRA File based APIs for attachments deprecated below |
JIRA project-centric view | 6.4 | Plugins that use project navigation.
Risk level: moderate Details: See Design guide - JIRA project-centric view |
Dropped support for Jelly scripts | 6.4 | Instances using this feature.
Risk level: moderate Details: See the end of support announcement |
Send Head Early for Dashboard and IssueNav | 6.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 |
In this section:
Name | Description |
---|---|
category | 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".
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: Corresponding web resources should be placed in context
Required: - |
url |
Required: - |
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.
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.
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 2flag.showMsg('Title', 'Body', { dismissalKey: 'dismiss.me' })
The following REST endpoint can be used to reset dismissals for a given flag:
1 2JIRA.SmartAjax.makeRequest({type: 'PUT', url: '/rest/flags/1.0/flags/dismiss.me/reset'});
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.
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 WebAttachmentManagerYou 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
.
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: