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.
- 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.