Jira 9.0 has a release candidate!

Hi,

We are checking compatibility with Jira-9.0.0-m0009. We can no longer call methods on our components (defined in atlassian-plugin.xml) within the velocity files. These classes are available in the velocity context (I have verified this) but I can’t invoke any method on them. Methods are public and also defined on the corresponding interface. I can invoke methods on data classes.

/secure/AjaxIssueAction!default.jspa [org.apache.velocity] Cannot retrieve method dateTimeToString from object of class com.deniz.jira.reminders.service.ReminderServiceImp due to security restrictions.

Hi @FilipNowak ,

Regarding the @SupportedMethods annotation, would it be possible to tag it as @Inherited too. It would provide more flexibility in the way Actions are designed in a plugin (and help dealing with Jira8 vs Jira9 API particularities). Currently, you’re forced to annotate the action class declared in the atlassian-plugin.xml manifest, no way to annotate a generic action class (that could come from an external jar for example).

If the classes extends some “restricted” classes, they are blocked. Try to see in the packages a file called velocity.properties. It includes a list of what is allowed or not.
For me: I had a class extending a com.atlassian class, it was rejected due to this security

1 Like

Thanks @LaurentNonnenmacher,
The class doesn’t extend from any other class but implements a few interfaces “LifecycleAware, DisposableBean, JobRunner”. Jobrunner is in package “com.atlassian.scheduler” and is included in “introspector.restrict.packages” setting in velocity.properties file of Jira. This behavior should be new to Jira 9, the same class was accessible with .VM files for years.

Once more regarding the @SupportedMethods annotations. There seems to have been a couple of different approaches here and via other channels.
@TomaszPrus Did you ever get some input from the team on how to approach this from a build targeting both Jira 8 & 9?
@aragot @denis did you manage to get this working?

2 Likes

For everyone looking for an implementation of @SupportedMethods compatible from Jira 8.13 and Jira 9.0, we’ve detailed our implementation there:

@rw-dennis
We implemented the solution by FilipNowak – compiling our plugin for Jira 9.
The compiled plugin has been tested against Jira 8.0 and Jira 8.22 – all our tests passed.

We also plan to test the solution by marcin.kosmala because it seems to be safer from the Jira 8 compatibility point of view.

https://community.developer.atlassian.com/t/jira-9-0-eap-04-is-here/55207/22
The problem is still reproduced in eap4: clicking on buttons Delete and Default in Resolutions results in “HTTP Status 405 – Method Not Allowed” error page opening.

Hi,

Regarding XSRF protection, I have a doubt if it is possible to obtain the xsrfToken for a form in a gadget.

I have a html gadget…


<Content type=“html” view=“profile, canvas, default”

and a form in the view template…


view: {
template: function (args) {

str+=" <form action=‘ATLASSIAN_BASE_URL/secure/CalculateCost!previous.jspa’ method=‘POST’ class=‘aui’…
str+=" <input type=‘hidden’ id=‘cost-old’ name=‘cost-old’…
str+=" </form…";

I have tried what is described on the page Form token handling

str+="<form action='ATLASSIAN_BASE_URL/secure/CalculateCost!previous.jspa?atl_token=<webwork:property value="/xsrfToken"/>’ method=‘POST’ class=‘aui’…
str+=" <input type=‘hidden’ id=‘cost-old’ name=‘cost-old’…
str+="</form…

and

str+="<form action=‘ATLASSIAN_BASE_URL/secure/CalculateCost!previous.jspa’ method=‘POST’ class=‘aui’…
str+= " <webwork:component name=‘atl_token’ value=’/xsrfToken’ template=‘hidden.jsp’/>"
str+=" <input type=‘hidden’ id=‘cost-old’ name=‘cost-old’…
str+="</form…

but none work.

How can I get xsrfToken in a gadget?

Thanks.

I came across a bug with the JQL query blank not updating after using the browser’s back button in some circumstances.

See JQL Search Blank fails to clear on browser.back with some history in Jira 9 for detailed steps to reproduce.

Hi,

I would like to know if there is documentation available on the use of the points “New checkpoints for resource phases” and “App header updates”.

Thanks.

Quick question, how do you actually go about installing Jira Service Management 5 into your EAP 9 installation?

Hi @dortiz !
We described the changes and the steps you need to take in the Preparing for Jira 9.0 document mentioned in the post.
Please let me know if you find the instructions unclear or they don’t work for you.
Kind regards,
Michał

Hi @MichalCiesielski,

thank you very much for your answer.

My question is not about the use, we have tested the new checkpoints in our velocity files and they work.
We have tested our apps on Jira 9 EAP04 without using the new checkpoints and they work fine. All of our scripts are launched with JQuery and AJS.

But as it says in the point “New checkpoints for resource phases”

New checkpoint promises are provided by Jira pages by default. However, if you create a new page, you’ll need to add them.

and in the point “App header updates”

All global variables (e.g. jQuery or AJS) and AMD modules (e.g. jira/flag) won’t be accessible on pages with deferred scripts.

So my question is that if we don’t include the new checkpoints in our pages, will the application scripts stop working in the final release of Jira 9?

Thanks,
David.

Hello again @dortiz,
TL;DR: No, the scripts should not stop working. We don’t plan to do any further changes in this area for the Jira 9 release (unless some serious bugs caused by these changes are reported; if that will be the case - we’ll communicate it broadly).

Some details:

All global variables (e.g. jQuery or AJS) and AMD modules (e.g. jira/flag) won’t be accessible on pages with deferred scripts.

For now we deferred scripts only on the pages mentioned in the Preparing for … document. If you don’t embed the scripts there - you won’t be affected. For now we don’t have plans to defer scripts on other Jira pages, so unless you do this on the pages defined by your App - you should be safe :slight_smile:
On the other hand - we encourage you to move the scripts that are not critical for rendering the content on your page to DEFER or INTERACTION phase as it should speed up the page rendering times for the users and make the perceived performance of your App and Jira faster.

New checkpoint promises are provided by Jira pages by default. However, if you create a new page, you’ll need to add them .

You only need to add them if you plan to use them. If not - no need to bother.

Thank you for raising your concerns - I’ll update the docs so they’re more precise.
I’ll be happy to answer more question if further clarification is needed.
Kind regards,
Michał

Hi @dortiz !

JS-generated HTML code does not undergo JSP nor Velocity Templates processing and therefore methods for accessing XSRF token described at Form token handling won’t work in this case.

What worked for me in a gadget was adding the following JS function to the gadget’s content:

function atl_token() {
    const tokenEl = parent.document.getElementById('atlassian-token');
    return (tokenEl && tokenEl.getAttribute) ? tokenEl.getAttribute('content') : undefined;
};

You’d use it like that:

str+="<form action=‘__ATLASSIAN_BASE_URL__/secure/CalculateCost!previous.jspa’ method=‘POST’ class=‘aui’…
str+=" <input type=‘hidden’ name='atl_token' value='"+atl_token()+"'/>"
...

kind regards,
Greg

I have the same issue, if this won’t be supported then how should we add a configuration page for custom fiels?

Hi,
we have some strange behavior regarding our velocity files in Jira 9:

(1) Parsing Active Objects is not working anymore
For some AOs we have a structure like

import net.java.ao.Entity;
import net.java.ao.schema.NotNull;

public interface NamedEntity extends Entity
{
	//...

    @NotNull
	public Timestamp getCreated();
	public void setCreated(Timestamp timestamp);

	@NotNull
	public String getName();
	public void setName(String name);

	//...
}

public interface Template extends NamedEntity
{
	// Some other data we store
}

In our vm file we are then calling a method to get the Template object and then trying to parse $template.name. This is working just fine <Jira 9. But since Jira 9 it seems that we only can access variables/ getters from the Templates interface itself but not from the extended one because there will just nothing be parsed. This place remains empty in the final web page as if $template.name would return null. However, from debugging I could see that it is not null.
On the other hand, parsing plain Java classes (e.g. grabbing the ao from the db, transforming it into another Java object and using this one in the template) is still working fine.

(2) Not all statements are being processed
In addition, we have some methods in our Java file we call in the vm file (like $action.formatDate($template.created)). But this is not processed at all. Instead just this expression is printed as plain string to the web page. In the same vm file - some lines below - we are again calling this method again. But there it is processed and is throwing a NullPointer, since $template.created is null (even though from debugging I could see that it is not null, so same issue here as stated in (1)). Why is the expression one time ignored and one time processed?

Is somebody else experiencing strange behavior regarding vm files?
Thanks a lot!
Cheers

3 Likes

I do have a problem related to web-panels on jira9, on jira8 are working correctly on jira9 when accessing directly the jira issue it is not filled, but during search or when I am already in the issue and when I access again to the same issue by clicking
image
then also It is loaded

Hi @TomaszPrus !

May we know the approximate release date?

Thank you!
Leo

11 Likes