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

Adding Clickable UNC paths to JIRA

I was tasked with the mission to find a way to add a UNC link to a certain shared document, in a way that every user will be able to access it.

The easiest way I found, so far, is to add a default, read-only field to each issue, so whenever creating or working on an issue, the link is available.

Yes, it’s an overkill, but other options such as adding it to the menu bar seem to require too much research and development (and perhaps being affected by the next JIRA update).

Turns out adding a clickable UNC field is a bit tricky… since there is no such field type (UNC link), and writing UNC paths in text fields doesn’t make them clickable, i figured out the following eay:

  • Add a URL field
  • Set the default value to the document path, for example: file://servername/folder/subfolder/filename.doc
  • Make it read-only using the behaviors plug-in.
  • Use a bulk action to update the field for the relevant issues (since setting a default only affects newly created issues).

Simple, effective, and future proof (and yes, database space wasting… but it’s a price I’m happy to pay).


UPDATE: It works fine in IE 11, but doesn’t work in recent Chrome and FireFox versions due to their default security settings. See this KB article for more information.

Migrating to JIRA – Technical

When migrating from ClearQuest to JIRA, there are some several technical pitfalls which one may encounter. In this post I will detail the main issues which I tackled during the migration process.

The general strategy is to use as much of the built-in JIRA fields as possible, since many abilities and plug-ins uses them by default (such as JIRA Agile). It required effort, but it certainly paid off.

Let’s discuss the details, then:

Continue reading

Assigning bugs to testers

In our JIRA environment, only testers may create or re-open bugs.
In order to improve our workflow, we’d like that the bug will be assigned to the relevant tester as soon as it is resolved.
The easy solution is to use the ‘assign to reporter’ post-function, but it does not work well for bugs which were re-opened and re-fixed, because we want to assign it to the tester who re-opened the bug.

So, I added a ‘Reopened By’ user-picker custom field which is set automatically to the current user when re-opening a bug. Then I came up with three approaches to implement this automatic assignment mechanism:

1. Add a ‘re-fix’ transition
2. Add a hidden ‘last tester’ field
3. Implement a Groovy script

Here are the details of each solution:

Continue reading

Unable to find JQL function ‘inSprint’

In our JIRA deployment we use several JQL functions from the excellent Script Runner plugin. But suddenly the ‘inSprint’ function stopped working, and when trying to use it you get the aforementioned error.

Turns out that the plugin has a certain bug which causes some of their functions to become unregistered in JIRA.

The solution: Disable and re-enable the plugin. Works like a charm!