Jira 9.0 has a release candidate!

Hi @TomaszPrus

  1. I wanted to release an application dedicated specifically to Jira >= 9 DC, can you give me some tips on how to process such an application in Atlassian Marketplace?. Does Atlassian already have any official (or unofficial) release process for Jira 9?

  2. In Jira 9 is probably something wrong with the context of web resources, atl.general loads on administration pages, in Jira 8 only atl.admin loads on these pages (doc https://developer.atlassian.com/server/jira/platform/web-resource/)

Example page: secure/admin/ViewIssueTypes.jspa
Example WB:

<web-resource key="KEY-resources" name="KEY-resources-wr">
        <resource type="download" name="file.js" location="/js/file.js"/>
        <resource type="download" name="file.css" location="/css/file.css"/>
        <context>atl.general</context>
    </web-resource>

Cheers
Adam

Hi @TomaszPrus,

I found a problem on the resolution page. When I try to delete some of the resolutions I get 405 and nothing happens. When can I expect to fix this?

2 Likes

Hi @TomaszPrus

The EAP02 contains a major regression related to Jira dashboards. It’s basically not possible to configure a dashboard anymore. As soon as you try to drag & drop any gadget, it remains “hanged” in a weird position.
Is this problem known? If not, can we report this anywhere?

Thanks,
Dan

Hi,
this change Jira 9.0 has a release candidate! - #16 by FilipNowak?
will cause to be necessary to publish a separate artifacts for Jira 8 and 9 → by our side it is a huge problem.
Any ideas how to implements adapters that will adopt jira web actions for Jira 7 i Jira 8 ?

Regards,

Thanks Dan! Our teams are already on working to resolve the issue

Hi,
createmeta REST API breaks on EAP02. It returns 404 error now.

As far as I know, EAP01 worked correctly. Is there any change on EAP02? I could not find any information about createmeta in Preparing for Jira 9.0 | Atlassian Support | Atlassian Documentation.

Thank you.

Hi,
Reply to Jira 9.0 has a release candidate! - #26 by hirota.takayuki.
You can replace it with this one - "issue/createmeta/projectKeyOrId/issuetypes/issuetypeId. jira-rest-java-client-core has a method for it but it is not parsing the id correctly and it is null. It is expecting id but in reality it is fieldId. The method is IssueClient.getCreateIssueMetaFields.
You can do something like that:

private List<CimFieldInfo> getFields(String projectKey, IssueType type) {
		List<Map<String, ?>> values = given().basePath(JIRA_REST_API_BASEPATH).contentType(ContentType.JSON).when()
				.get("issue/createmeta/" + projectKey + "/issuetypes/" + type.getId()).then().statusCode(200).extract().jsonPath()
				.get("values");

		return values.stream().map(value -> {
			try {
				return cimFieldsParser.parse(new JSONObject(value), (String) value.get("fieldId"));
			} catch (JSONException e) {
				e.printStackTrace();
				return null;
			}
		}).collect(Collectors.toList());
	}
1 Like

Hey,

We published a KB related to BigPipe removal. In an essence we change how Activity Tabs (comments etc) and Sidebar are rendered:

https://confluence.atlassian.com/jirakb/sidebar-and-activity-tabs-in-jira-9-1114816314.html

@nstanishev Thank you for your reply.

@TomaszPrus I found the article about createmeta. I think it would be helpful that Preparing for Jira 9.0 involves this topic.

Thank you.

@TomaszPrus , @FilipNowak , @GregRowinski

Jira 9 EAP 02 requires annotations like “@SupportedMethods({RequestMethod.GET})” for all actions that use non-POST methods. You mentioned that there is no additional compatibility package is planned for Jira 8. This makes it impossible to create plugins compatible with both Jira 8 and Jira 9.

So we have only 2 options:

  1. Do not use GET actions or
  2. Create separate plugin versions for Jira 8 and Jira 9.

Could you please confirm that if we unable to exclude GET actions we have only the second choice – separate plugin versions for Jira 8 and Jira 9?

Thank you.

6 Likes

Separate plugins for Jira 8 and Jira 9 are simply unacceptable. We have been able so far to have a single version supporting Jira from 7.0.0 to the latest Jira 8, we need to be able to continue down that path with Jira 9.
Please escalate internally.

3 Likes

Hello @denis @piotr.patrzek1 @david2 ,
May I ask: are you compiling the plugin against Jira 9.0 or the older version?
In case the plugin is compiled with Jira 9.0, it can be run on Jira 8.x too if we are talking only about the annotations. They just won’t have any behavioural effect. Could you please explain what kind of solution would satisfy your needs?
We’ll return to this topic, and analyze the problem after we get the feedback.

It would be typical for people to compile with the lowest version of Jira their app supports, otherwise you run the risk of accidentally using classes/methods not present in older versions.

5 Likes

@FilipNowak we compile against the oldest version we support (currently 7.3.0). When Atlassian introduced breaking changes like this, a compatibility library was usually provided. There are cases where we have to use workarounds, like introspection, to support newer APIs that were not backward-compatible, but here the approach would not work.

@FilipNowak
The same as above – we use the lowest supported version (currently 8.0) to build the plugin. This guarantees that our code does not contain anything incompatible with old Jira versions we support.

I tested your solution (build for Jira 9 and run in Jira 8) – and it seems working. Thank you.
This is not an ideal solution as it requires more attention about the code (because it is easy to use something from newer Jira version and break the plugin on old supported versions), but it is definitely better than having different plugin versions, and so it looks acceptable for us.

Unfortunately, we can’t build for Jira 9 (nor even Jira 8) without some major refactoring, as our code is written for Jira 7 (with aforementioned tricks to support Jira 8)

Hi @david2, I’ll reach out to the team and get back to you soon.

3 Likes

Hi team,

We are currently facing an error related to the way we are loading Javascript files.
So, basically, our velocity file is rendered before the Javascript we need.
We have a velocity file where we load the web resource with the javascript we need and also we have a form.
At the end of the velocity file, we invoke a function from Javascript, and on the console browser, e got an error saying the function we invoked is not defined.
Furthermore, we also have another error related with AJS and the error is:
AJS.$ is not defined.
Does anyone face the same problem with the JIRA EAP 9(version 02 and version 03)?

Kind regards,
André Fernandes Rodrigues

1 Like

Hi

I am trying to update some browser tests against 9.0.0-m0009.
I noticed the gg or , quick access menu appears to be broken for a freshly loaded browser session.

For example, starting from the login screen, fully clear your browser cache, then log in and try to use the gg key. No menu will show, but if I refresh the browser, it will start working.

It seems the EAP has some issues loading the standard Jira JS resources at the required time.

Kind Regards
Matthew

Hey @denis @FilipNowak,
we have exactly the same problem with the required @SupportedMethods annotation.

We saw that it will not break the app itself, if you compile it against Jira 9.0 and install the app on Jira 8 or older.

But we always run our integration tests to the lowest supported version of our app, to make sure that nothing is broken there. In addition to that, we develop against the lowest supported version as well. The reason is, that we want to avoid the direct access to functions, that are available in newer versions. If we want to use these new functions, we have to access them via Java Reflections, to make our app backward compatible. If we develop against Jira 9.0 it’s much more unsafe and the probability is much higher, that somebody uses new functions that breaks the compatibility to lower Jira versions.

1 Like