Showing Unavailable Actions

 BTW – sign-up to the blog is currently not working, so you cannot comment.

This is an attempt to deal with something I’ve mentioned previously, and is JRA-5705:

The problem I have with conditions, is that when a condition is failed, the transition is not displayed. This can lead to confusion for users – “I’m sure I saw that action the last issue I looked at, and I think I’m supposed to resolve this, but the link isn’t there”… followed by a support call.

Ideally if a condition is failed the link should be present but disabled… when you mouse over it it could you give you some explanatory text, eg “Cannot resolve because this issue depends on issues that are not resolved”. You could provide that message as a parameter in the condition.

I had a bit of a monkey around with the code and came up with this:


I compare the results of getAvailableActions with WorkFlowDescriptor.getStep(…).getActions(). The unavailable actions are displayed in a separate area, when you mouse over each action you get a reason why you can’t do this.

The error message is supplied by the workflow designer in the form of a property, error.message:


You don’t need to be as ungrammatical as me though. At first I attempted to do this programatically, by looking at the conditions on the action, then creating a semi-meaningful error message, which would probably just be the class name – a “computer says no” type of thing. Then I remembered that conditions can be ANDed and ORed and nested and so on, and working out which one failed would involve firing them all which I didn’t want to do.

Also as Anton mentioned in the bug report, you don’t necessarily want to show ones that are forbidden because of permissions. This method won’t show unavailable actions unless you have provided this property on the transition.

Like I say I was just playing around here, unfortunately implementing this was rather intrusive. What I mean by that is I didn’t see how to easily use the plugin system, so I just modified the code and velocity template directly.

I wouldn’t consider this unless you’re comfortable building jira from source, and you have it all squared away in your source code control system. While I’m on that subject, I check all the source code as it’s delivered from Atlassian in to a vendor branch, unadulterated. This is then branched to a main branch where we put our site-specific changes, and experimental stuff. So when we put in a new version from Atlassian, we check it in to vendor, then merge to main. That way it’s easy to keep track of our own edits and changes to the property files, without missing new stuff. Because we can easily see the changes with each version it’s easy to see in which files new features are implemented, if we want to have a nosey.


  1. Download showavailableactions.jar. The interesting stuff is a new method in IssueUtilsBean, and an addition to the velocity template.
    NB this is a jar file with the source. Rename to .jar if your browsers insists on downloading it as a zip file.

9 comments to Showing Unavailable Actions

  • I missed a file in the jar file previously, please download again if it didn’t work for you first time round.

  • Bill Greene

    This is fantastic – do you think you can work with Atlassian to get this incorporated into the official JIRA code base?

  • Bill Greene

    I tried to build this with JIRA 3.12.3 sources, but the default JIRA specifies java 1.4 compiler and target. This causes an error in your code which uses for-each only supported in java 1.5. I tried changing the and maven.compile.source settings to 1.5 but then the compile failed due to errors in the JIRA source. Can you please tell me how you configured your build to work?

  • I build everything under 1.5. I think there were a couple of issues with the jira source but I just fixed whatever the problem was. You can either compile just these classes under 1.5, or fix the issues in the jira source, or rewrite without the “for (object : list)” stuff.

    The equivalent of the first loop would be:

    Iterator i = lAllActions.iterator();
    while (i.hasNext()) {
    ActionDescriptor actionDescriptor = (ActionDescriptor);
    log.debug(“Addng an action to all actions: ” + actionDescriptor);

    (not tested).

    cheers, jamie

  • Bill Greene

    I got it compiling under 1.5. I notice that it seems to throw an exception whenever there are no unavailable actions, or there are unavailable actions but error.message is not set. Is there a way to prevent this – it is creating an error in the logs whenever anyone views an issue. (note: I’m not a Java programmer so forgive me if this is obvious!) Here is the message I see:

    2008-06-26 05:39:38,588 http-8090-Processor25 ERROR [atlassian.jira.issue.IssueUtilsBean] Exception: java.lang.NullPointerException
    at com.atlassian.jira.issue.IssueUtilsBean.loadUnavailableActions(
    at com.atlassian.jira.web.component.issuesummary.IssueSummaryWebComponent.getUnavailableActions(
    at com.atlassian.jira.web.component.issuesummary.IssueSummaryWebComponent.getHtml(
    at org.apache.jsp.decorators.issuesummary_jsp._jspService(

    It seems be from this code in on line 84:
    Map attribs = action.getMetaAttributes();

    I noticed that the loadAvailableActions function doesn’t throw an exception when there are no _available_ actions to show – I’d like the loadUnavailableActions function to behave the same.

    Thanks, Bill

  • Yeah I noticed a problem with that as well – will try to fix shortly. I have not tested it fully, not in production yet. So you are using 1.5 now? Therefore “for (object : collection)” is OK?

  • Bill Greene

    Yes, I’m using 1.5 now so the “for (object:collection)” is OK. Thanks in advance for fixing this! I’ll let you know if I see any other issues – so far it seems to work beautifully.

  • i left this a bit late in the day… I’m off for a week now, sorry, will sort it out soon as i ge back.

Leave a Reply