JIRA Pre-Upgrade check – call for votes

Let’s start with a bottom line: if you’re a JIRA user, please take a few seconds to vote for the ‘JIRA Pre-Upgrade check’ suggestion

Now for the whole story:

Recently we upgraded one of our JIRA instances. It all seems well at first and then small problems started to pile up.

After contacting Atlassian support, it turns out we should have upgraded our database server (Oracle in this case) before the upgrade (“it’s in the documentation!”). We didn’t, so some data upgrade tasks silently failed, without any notification during or after the upgrade process.

I was surprised. As a long-time installation developer I learned one thing: users don’t read the documentation until they have problems. They certainly don’t read installation guides; at most they skim through the release notes. That’s why every installation I create includes some basic validations regarding the environment (e.g. OS, database, Java…).

So, I suggested Atlassian to add this kind of checks to their own installer and they immediately agreed. All that’s left is to gather enough votes so it would go into their suggestion review process. Appreciate your help!


JIRA Tip: issues showing on Kanban board but missing on Scrum board

Let’s say you have two JIRA projects, project K using a Kanban board and project S using a Scrum board. Each project with its own set of statuses and workflows.

Now, users of project S want to see issues from project K on their Scrum board. They update the board filter accordingly, but to their surprise, many project K issues are not  visible in the Backlog.

Why? because a JIRA board (either Scrum or Kanban) only shows issues whose statuses are mapped to the board’s columns (e.g. To Do, In Progress, Done).
Issues with unmapped status are not displayed on the board at all. This is useful in some scenarios but confusing in others, such as in the example above.

To remedy the situation, go to the Scrum board’s configuration, and under the ‘Columns’ sections you can map or unmap statuses as you see fit.

Atlassian DevOps Event Impressions

Today I attended an event, organized by ManageWare, titled “Bridging the Gap Between Dev & Ops”, focusing on Atlassian’s tools suite. JIRA is a very popular tool here in Israel, so the main theme of the event was to showcase how productivity and collaboration can be increased when integrating JIRA with other tools.

There were quite a few presentation (detailed at the end of the post) on various DevOps-oriented subjects, such as CI/CD pipelines, monitoring and reporting. Nothing revolutionary, but it was nice to see how a good integration between various tools (not just Atlassian ones…) can really make things flow faster and help focus on generating value for the business.

I only wish some of the sessions were longer, there was a lot more to see; unfortunately, due to time constraints, most presenters had to rush through their materials.

And finally we had some fresh Pizza and ice-cold beer 🙂

The presentations:

Continue reading

JIRA SOAP API is being deprecated

In the past I mentioned that I use the JIRA::Client Perl module quite frequently. This module is based on JIRA’s SOAP API.

Recently it came to my attention that Atlassian deprecated their SOAP API in JIRA 6.0 and will be removing it altogether in JIRA 7.0 (see here). Anyone who is still using the SOAP API is encouraged to migrate to the REST API.

Specifically for the JIRA::Client module, an alternate module, JIRA::REST, is now available, providing similar functionality.

So if you’re using any SOAP-based access to JIRA, it’s time to move on…

JIRA Behaviour plugin: handling sub-tasks

I was asked to show a warning message when editing an issue custom field, in case there are subtasks to the issue. Since I already had a validator script which was used for a similar purpose, I figured I’ll just copy the code into the relevant behavior entry and it would work. Clean and simple.

Boy, was I wrong.

As you may know, you need the issue object in order to work with its subtasks. In all Script Runner environments (validators/post functions/etc.) you have the readily available ‘issue’ variable. However it does not exist in the Behavior plugin environment. Since both were written by the same developer, I assumed it must be there somewhere, so tried all sorts of stuff to try and find it, but to no avail (why doesn’t it exist in the FieldBehaviours class?).

“Fine”, I said, “let’s get the issue key and obtain the object from it”. Not very elegant, but simple enough.

Wrong again. getFieldById(“issuekey”) returns null. I honestly have no idea why. Again I had to spend a lot of time searching for a reason, then gave up and started looking for a way to work around it. Eventually I figured out the correct way to get the issue object.


import com.atlassian.jira.ComponentManager
FormField field = getFieldByName("MyCustomField")
def issueid = getFieldById("id").value
def issue = ComponentManager.getInstance().getIssueManager().getIssueObject(Long.parseLong(issueid));
Collection subTasks = issue.getSubTaskObjects()
if (!subTasks.empty) {
 field.setHelpText("<div class=\"warningBox\">Attention: the issue has subtasks.</div>")
else {


Getting a JIRA issue’s priority using Perl

JIRA::Client is a great and useful module. Too bad some of its usage is so cryptic!

For example – suppose you want to print an issue’s priority field. if you simply use $issue->{priority} you will get the priority id, not the display name which everyone is used too.
So, how to get the display name? documentation is very vague on this subject. Google doesn’t help much here.

After a lot of trial & error I figured out a way.

Continue reading