Jira 9.0 has a release candidate!

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.

For details on the available changes, see Preparing for Jira 9.0. You can download the EAP from this page. If you’re using maven.atlassian.com, make sure to download 9.0.0-m0012.

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.

Best,

The Jira team

19 Likes

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

Regards
Paul

1 Like

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.

4 Likes

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.

Thanks

3 Likes

Hi,
as per Preparing for Jira 9.0 - multiple EAPs coming your way

When will Jira 9.0 arrive?
As mentioned above, we cannot provide an exact date, but our current target to release Jira 9.0 is mid Q2 2022.

3 Likes

Hey @TomaszPrus

Any chance we could get the Jira 9.0 EAP pushed to Docker Hub Normally EAPs are published there as well.

Cheers!

1 Like

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?

3 Likes

Hi Jared!
You should find it here now:
https://hub.docker.com/r/atlassian/jira-software/tags?page=1&name=9.0.0

3 Likes

Hi Reece,

It is a bug and we will look into this. We plan to get rid of commons-lang 2.x dependency altogether in Jira 9.0 and migrate to commons-lang3 instead.

4 Likes

Thank you for the clarification, that is really helpful for our planning :slight_smile:

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.

Again, thank you for clarifying.

2 Likes

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?

Cheers :slight_smile:

2 Likes

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.

There is a blocker bug in 8.22 and 9.0 on the issue screen Jira 8.22 EAP 01 released - #2 by pch

@TomaszPrus are there any changes around com.atlassian.jira.web.action.JiraWebActionSupport?

I’m getting an error for a webwork1 action, which works fine on Jira 8.21:

This is my setup:

    <webwork1 key="configuration-action" class="java.lang.Object" roles-required="admin">
        <actions>
            <action name="com.atlassian.jira.web.action.JiraWebActionSupport"
                    alias="MyConfigurationPage">
                <view name="input">/templates/configuration-page.vm</view>
                <view name="success">/templates/configuration-page.vm</view>
            </action>
        </actions>
    </webwork1>

Thanks

1 Like

Hello @Grzegorz.Tanczyk :slight_smile:
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.

2 Likes

Hi @TomaszPrus, @FilipNowak: The Verification of Jira web action request methods section of Preparing for Jira 9.0 says that:

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.

1 Like