Jira 8.22 EAP 01 released

[TomaszPrus]

We’ve just released the first EAP for Jira 8.22 (Data Center & Server).

Highlights:

• 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.
• Configure Jira as an OAuth 2.0 provider
  To complete our OAuth 2.0 functionality, we’ve now added a way to configure Jira as an OAuth 2.0 provider, allowing you to exchange data with external applications in both directions – either by giving external applications access to Jira data or letting Jira request data from these applications.
• Web Resource Management 5.0
  Web Resource Management (WRM) is a tool that takes care of serving static assets for the whole Jira, including plugins. With the upgraded version we can provide better page loading performance.
• XStream 1.4.17 vulnerability mitigation
  We’ve upgraded com.thoughtworks.xstream to version 1.4.18. XStream is a library used for serialization/deserialization of Java objects to/from XML. This update limits the range of types that can be serialized/deserialized to increase security.
• Multiple email channels (Data Center)
  You can now configure as many dedicated email channels as you need for better communication with customers. Their emails will turn into requests or comments, personalizing and speeding up the process.
• SLA configuration interface (Data Center)
  We’re introducing a brand new SLA configuration interface so that all settings related to SLAs live in the same space for easier management and monitoring.
• Auto-populated request fields (Data Center)
  Many of our users aren’t linking a Confluence knowledge base to their service projects and find the default search bar not needed or even confusing. That’s why we’ve now added an option to disable the search bar.
• Downloads & docs
  For details, see Preparing for Jira 8.22. You can download the EAP from this page . If you’re using maven.atlassian.com, the version is 8.22.0-m0001.

If you have any comments, just post them below.

Happy testing,
The Jira team

[pch]

We’ve found a bug in the new tooltip implementation which breaks and BLOCKS the Issue Search component in Jira 8.22 and Jira 9 and blocks our app Agile Tools & Filters for Jira Software.

How to reproduce - fill a value on extended fields (2nd row) and switch filters on the left

Your code:

_getTooltipText: function() {
            var searcherModel = this.searcherCollection.get(this.model.getId());
            var tooltipText;

            if (!this._isValidSearcher()) {
                tooltipText = “This criteria is not valid for the project and/or issue type”;
            } else if (this._containsInvalidValue(searcherModel)) {
                tooltipText = “This criteria contains invalid value(s)“;
            } else {
                tooltipText = searcherModel.getTooltipText();
            }
            return searcherModel && tooltipText || “”;
            
        },

//FIXED version

_getTooltipText: function() {
            var searcherModel = this.searcherCollection.get(this.model.getId());
            var tooltipText;

            //FIX for the bug
            if (! searcherModel) return "";

            if (!this._isValidSearcher()) {
                tooltipText = “This criteria is not valid for the project and/or issue type”;
            } else if (this._containsInvalidValue(searcherModel)) {
                tooltipText = “This criteria contains invalid value(s)“;
            } else {
                tooltipText = searcherModel.getTooltipText();
            }
            return searcherModel && tooltipText || “”;
            
        },

Please include the fix before the release.

Regards
Prem

[Grzegorz.Tanczyk]

@TomaszPrus Looks like there is an undocumented change on the Application Links screen:

The “Atlassian product” label is misleading. It should not be called this way, because the Oauth1a mechanism is used to integrate also with external non-atlassian applications.

This is the 8.21.0 UI for reference:

Would you be able to fix the copy, or revert those changes? From our app user perspective it is critically important to mention two keywords: OAUTH1 and “Generic application”.

Thanks

CC @mmichalak @tbartyzel

[AdriannaMusialik]

Thank you for flagging this. We have been able to identify the problem and a fix will be included in the official release.

[tbartyzel]

Hey Grzegorz, nice to hear from you.

We’ve structured the UI around OAuth 2.0 after completing the “provider” flow and merging it with “client” into application links. We want this option to be seen as the primary one for integrating with external apps, especially as we’re moving into the Data Center-only world.

OAuth 2.0 is more secure and it’s been the standard for a long time – we introduced it on the request of our enterprise customers who found 1.0 to be unreliable.

As for the original OAuth 1.0 itself:

• The flow of applinks always prioritized Atlassian products, so using it for external apps has been a bit hacky. We chose a clean and straightforward UI, with the focus on 2.0.

• We know that not all apps can switch to 2.0 right away or at all. We’ve left the original mechanism under “Atlassian product” (also for external apps). We’ll explain that in the docs and upgrade notes, and you can also see it in the linked EAP docs.

• Already configured integrations won’t be affected. They’ll continue to work and will stay where they are, as generic applications.

I hope that helps. The gist of it is we simply see OAuth 2.0 as the main flow and believe the majority of new integrations will follow our approach.

[Grzegorz.Tanczyk]

Thanks for the answer @tbartyzel , I’m happy to finally see the support for Oauth 2.0 Incoming authentication coming to Jira Server, it is a great step forward. This feature was requested by customers for a long time(7 years at least: JRASERVER-43171 ), and this is a moment we all celebrate
We have support Oauth2 already on our end, this works great in the Cloud.

We need to support various versions of Jira and Confluence, and we would like to not confuse the user with versions of Jira and Confluence in our UI. Instead we would like to use simple message: “Oauth 1a” and “Oauth 2”.
I’m sure they will pick Oauth2 because they understand security implications, no need to help them with UX gray patterns.

Would it be a big deal to describe “what’s inside” instead of denylisting the “Oauth 1a” keyword? It will be visible later anyway. I’ve prepared a mockup of suggested change:

Thanks