Silly JIRA!

Adding Custom Fields to JIRA’s “View Issue” screen. Seems like a straightforward task, right?

  1. Create a copy the default screen
  2. Add the fields you wish
  3. Associate the new screen with the ‘View issue’ action (in the appropriate Screen Scheme).

Then why I don’t see the custom field there?

The answer is: if the field does not have a value, it will not be displayed.

Probably the worst behavior they could choose for this case!

Advertisements

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

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);
 }
 else
 {
   $entity->SetFieldRequirednessForCurrentAction("DocumentName", $CQPerlExt::CQ_READONLY);
   $entity->SetFieldValue("DocumentName","");
 }

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") {
 docName.setReadOnly(false)
 docName.setRequired(true)
} else {
 docName.setReadOnly(true)
 docName.setRequired(false)
 docName.setFormValue("")
}

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.