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


JIRA as ClearQuest Replacement: Customization

Somewhat later than expected, here is a summary of JIRA’s advantages and disadvantages over CQ, customization-wise only. These are only issues I encountered myself, I’m sure there are more…

Before I list them, I’d like to mention a couple of must-have (free) JIRA plug-ins: Behaviours and JIRA Suite Utilities. Another popular one which I have not yet used, but seems promising, is Script Runner.

Continue reading

Workflow Considerations

While evaluating ClearQuest to JIRA migration, I noticed there are some major differences in their default defect tracking workflows. They have different approach to even the most basic issues such as assigning or reopening a defect. In this post I would like to focus on some of the key differences, and suggest my opinion about them.

Before I start, you may ask why do I care about the default workflows? Every modern issue tracking tool is very customizable, after all. But the way I see it, the default workflow say something about the tool developers and their vision of defect tracking, so it may be something interesting to look at.

Continue reading

Set field requiredness in JIRA based on another field

I am new to JIRA, currently evaluating if we could use it as a replacement for ClearQuest.

One of the early challenges I encountered was to perform the task mentioned in the title.¬†Specifically, when the other field is a checkbox. Let’s say we have a checkbox called ‘Related Document’ and a textbox called ‘Document name’. If the checkbox is ticked, then the user must supply the document name, and if the checkbox is cleared, then the text field should be read-only.

In ClearQuest it’s quite straightforward:

  1. Create a perl script as the ‘Value Changed’ event of the ‘Related Document’ field.
  2. Add the following code to the script:
 my $value = $entity->GetFieldValue($fieldname)->GetValue();
 if ($value)
   $entity->SetFieldRequirednessForCurrentAction("DocumentName", $CQPerlExt::CQ_MANDATORY);
   $entity->SetFieldRequirednessForCurrentAction("DocumentName", $CQPerlExt::CQ_READONLY);

In JIRA, it’s a bit more involved:

  • In ClearQuest, you define a field, and then attach it to a widget. In JIRA, the field type is also the widget, and usually it’s impossible to change it once set. So I need to use a checkbox-type field.
    There is no ‘single checkbox’ field type in JIRA, so I created a multi-checkbox field called “Documentation” with a single option, “Related Document”.
  • There isn’t an easy way to add ‘Value Changed’ events to fields in JIRA itself; I installed a plugin, called ‘JIRA Behaviours Plugin‘, which adds a lot of customization abilities.
So here’s what I did after creating the relevant fields and installing the plug-in (This took a bit of trial-and-error until I got it right…)
  1. Add a new Behavior (Administration > Plugins > Behaviors)
  2. Add the checkbox field to this behavior, and within it, add the following server-side validation script:
FormField relDoc = getFieldByName("Documentation")
String val = relDoc.getValue()
FormField docName = getFieldByName("Document Name")
if (val == "Related Document") {
} else {

It all seemed to work, except that when you initially open the form, the text field is enabled even though the checkbox is not marked. So, I edited the behavior, added the text field, and set it as ‘read only’.

Configuring JIRA is a very different experience than ClearQuest, both in concept and implementation;¬†I’ll post more general CQ vs. JIRA thoughts later this month.