Release Candidate 02 for Jira 9.0 is good to go! Make sure to test it straight away because the official release is just round the corner.
We’ve decided to collect your feedback on the Jira 9.0 EAP releases in one place, under this post. Below you can see all changes we’ve introduced in EAP 01, 02, 03, and 04.
Highlights:
Jira EAP 03 is available on the Marketplace
You can use this version to check compatibility of your apps with Jira 9.
Automation for Jira (Data Center)
With the release of Jira 9, Automation for Jira will become a native feature, bringing additional value to Data Center customers. This feature will be available both in Jira Software and Jira Service Management for automated, effective work.
Limit excessive activity with the Guardrails Tool
To help you eliminate performance drops or crashes resulting from exceeding a certain number of entities in your Jira instance (for example, comments, active projects, or epics), we’ve created the Guardrails Tool.
The “View on board” feature gets a redesign for better performance
We’re replacing the old “View on board” feature with an entirely new experience aimed at improving the responsiveness of searching for boards that contain a particular issue.
Lazy-loading workflow transitions
We’ve moved all the transition buttons to the dropdown menu. We’re now rendering all of the Jira transitions in the dropdown asynchronously on-demand after a user opens the dropdown.
Lazy-loading attachments’ thumbnails on issue view
We’ve sped up the loading time of issues with a significant number of attachments. With the new functionality, thumbnails generation is deferred and asynchronous for the issue view by default. It speeds up page loading and reduces the amount of data processed at once.
Lazy-loading inline gadgets
To ensure faster loading of Jira dashboards, we’re introducing a lazy loading mechanism for inline gadgets that are displayed on the dashboard view. With this improvement implemented, only inline gadgets present in the viewport will be loaded on the page load.
Front-end API contract
Jira 9.0 comes with the API front-end contract that brings more clarity and efficiency to your app development process. Check the front-end contract for all the details. We’re open for collaboration, so if you have any questions or need assistance—just let us know.
Activity Tabs improvements
As part of broader Issue View improvements, we’re optimizing the way activity items such as Comments, History, Work Logs, and the “All” tab are displayed and organized.
App header updates
We’re making changes to the App header, which will allow us to load it faster. Additionally, we’ve adjusted the Flush Head Early mechanism for these pages—it sends a partially rendered markup with resource (.css, .js) definitions and an animated app header placeholder before doing heavy work on the back-end.
BigPipe is no longer supported BigPipe is a server-side lazy-loading technique that was used to defer the rendering of Jira web panels.
Popper replaces Tipsy in AUI 9.3.5
We’ve upgraded AUI to version 9.3.5, which replaces the Tipsy tooltip generation library with Popper.
Restricting anonymous access to REST endpoints
We’ve restricted anonymous access to several REST API endpoints.
Improved XSRF protection
We’ve changed the XSRF protection default policy for web actions.
Verification of Jira web action request methods
We’ve added an additional security check for Jira web actions that verify the HTTP method that action is invoked with to prevent the new opt-out XSRF check from being bypassed.
API breaking changes
We’ve made a number of changes to API classes and methods.
XStream allowlist for improved safety
Jira 9.0 uses XStream 1.4.18 with the allowlist by default.
thread processing configuration
We’ve added a new configuration setting that allows you to select the off-thread processing mode.
Share your feedback
We’d like to use this post to gather your feedback about the milestones we’re releasing. If there’s anything we can provide that will make it easier for you to understand and plan the changes, let us know. Share any feedback or questions you have, we’ll get our best people to help.
Hi @TomaszPrus, for the deprecated classes/methods, is there a list of which classes/methods should be used instead of the deprecated ones. Without that, there is a lot of guesswork on how to do things
Hi @paul, the Preparing for Jira 9.0 page contains dedicated links to Javadoc API for every deprecated class/method. In the Javadoc, there is information on what alternative class/method should be used instead.
Hi,
Can you please tell us what is your timeline for releasing Jira 9.0?
Since there are so many impacts, I hope that we can count on some reasonable delay to prepare our apps.
In Jira 8.21.0, the org.apache.commons.lang package was OSGi exported from the system bundle with version 2.6.0
In the first Jira 9 EAP, the exported version of that package now appears to be 2.4.0, is there a reason for that change? We currently have a dependency on version 2.6.0
We can work around this, just curious about the change?
Thank you for the clarification, that is really helpful for our planning
Migrating to commons-lang3 was one of the workarounds we were looking at for our app, as Jira 9 is removing commons-lang entirely, we will probably switch to commons-lang3.
Are there additional changes similar to this planned for Jira 9 that are not yet mentioned on the Preparing for Jira 9 page?
So far we haven’t had any major issues getting compatible with the first EAP, but dependency changes/upgrades like this may present issues in later EAPs.
Hi all!
I have a question about 3rd party app compatibility with Jira9 and Jira8 at the same time.
There is a new annotation @DoesNotRequireXsrfCheck in Jira9. Are you planning to have additional dependency package to be able to compile and run with Jira8?
Hi @stepanov! Thanks for your question. I do admit @DoesNotRequireXsrfCheck is not (and will not be) available in Jira 8, so plugins which want to use it in order to be compatible with Jira 9 will become incompatible with Jira 8 - they won’t compile and won’t run with Jira 8 - at least in a straight forward way. It’s up to plugin vendors to cope with that. We’re not planning additional compatibility package. Note that in the particular case of @DoesNotRequireXsrfCheck we advise not to use it i.e. do not skip XSRF checks for mutable-kinded HTTP requests. It this was not an option, the last resort would be releasing separate plugin versions for Jira 8 and 9.
Hello @Grzegorz.Tanczyk
Yes, as mentioned in Preparing for Jira 9.0 article there are changes regarding request methods support by WebActions. They are described in ‘Verification of Jira web action request methods’ section.
Our Developer documentation states that classes extending JiraWebActionSupport must be used instead of direct usage of this class. Please create new subclass and annotate its methods accordingly to resolve the problem.
Classes and methods without an annotation will only accept POST requests. For example:
This is a bit counter-intuitive to me, why are not GET requests allowed by default? This breaks every web-work action we have for no obvious reason. I can see why you would require an annotation for stuff like DELETE (I might even understand blocking POST, or even blocking everything), but I don’t get the reasoning behind requiring an annotation for GET but not for POST.
Could we get the rationale behind this move? Is there some specific threat from ninja GET requests that I need to guard against even in our app code for Jira 8? (Which, I’d like to point out, we as app developers need to support until 2024!)
Actions worked identically for each request method, so leaving GET as the default supported method would be create a bypass for the improved XSRF protection also released with Jira 9.
But GET actions don’t need the XSRF protection, if I understand correctly. Is the idea that attackers might create a GET request to an endpoint that was meant for POST, and thus execute the action without XSRF protection, while still managing to control the effects of the action using URL parameters instead of the request body?
GET doesn’t have the new opt-out XSRF protection (and shouldn’t need it - correct), and that’s indeed the reason why it’s not the default supported method for non-annotated actions, like you explained.
