Wednesday, December 28, 2011

Prepopulating JIRA system fields

Sometimes people ask me how to prepopulate JIRA system fields. For example, they want to have some template text appear in the system Description field. The simple JavaScript below does this. Just add it to the Description field's description in the relevant Field Configuration.

<script type="text/javascript">
        var projectName = AJS.$("#issue-create-project-name")
        if (projectName != null && projectName.length == 1) {
            var projectName2 = projectName[0].innerText;
            if (projectName2 != null && projectName2 == "MyProject") {
                var templateText = "Sample text goes here\n\nAnd here";
                AJS.$("#issue-create #description")[0].value = templateText

This example only affects issues that are created in the JIRA project named MyProject. Your template text has to be escaped HTML and I don't think it will like Wiki markup if you're using the Wiki Renderer for your field. Tested with JIRA 4.4.1

Wednesday, December 14, 2011

Book Review: JIRA Development Cookbook

JIRA Development Cookbook,  Jobin Kuruvilla, Packt 2011

Summary: lots of interesting JIRA recipes, lots of source code, and not too many bugs.
                   If you're working with JIRA, buy a copy.

The Good Bits

The chapters on gadgets and JQL are especially useful. The UI recipes are all things I've been asked to do for clients in the past. My favorite one is adding JavaScript to a field's description to make the help text expand (p.85).

The Custom Fields chapter is also well written and the comparison of version 1 and version 2 plugins is excellent.

The screenshots are all done well.

Not As Good Bits

  • Applicable JIRA versions are noted in many, but not all, locations where it matters.
  • Testing of plugins is glossed over. Which is fair enough, since that's exactly what I did in my own Practical JIRA Plugins book.
  • There are few if any references to other plugins that show examples of each recipe in use.
  • Many of the changes involve modifying the JIRA database schema or the application files rather than providing a plugin to do this. This makes upgrades harder than necessary.

Oh Well ..
  • The publisher could have done a better job proof editing this book. 
  • There are numerous rough sentences and improperly capitalized parameter names.
  • I don't have a VAT number so I had to buy my copy through Amazon instead of the Packt website.
Disclaimer: I'm the author a similar but much shorter (and cheaper) book Practical JIRA Plugins (O'Reilly August 2011). After I bought a copy of JIRA Development Cookbook I was given an online copy by Packt to help with this review.

Friday, December 9, 2011

When is Wiki not a Wiki?

If a wiki uses an opaque format for storing its information, is it still a wiki? This question was prompted by discussions on an Atlassian blog post "Why We Removed the Wiki Markup Editor from Confluence 4.0". The summary is that a new version of Confluence changed so that you can't directly edit the text in its pages.

Wikipedia  has this to say about the subject of tools that do this, e.g. Google Docs

"the markup of a newly edited, marked-up version of the page is generated and submitted to the server transparently, shielding the user from this technical detail. However, WYSIWYG controls do not always provide all of the features available in wikitext, and some users prefer not to use a WYSIWYG editor. "

but I think there's a deeper issue here. Some people don't care about what's under the covers since they always access it at a higher-level such as a WYSIWYG editor or a browser. Other people expect to be able to manipulate the underlying content with other text-based tools. Using an opaque format will always alienate the latter group.

The tension between the two viewpoints is at least as old as Word and WordPerfect in editors, and surely has parallels in other human endeavours, though I can't think of them right now. I find myself in the open format camp since I want to be able to tinker with things.

Wednesday, October 19, 2011

JIRA Queues

Some of my clients refer to JIRA projects as "queues". I usually think of a JIRA project as a bucket of issues with no predefined order. Queues are what are more useful for everyone though. The ordering of issues that turns a bucket into a queue is a handy definition of project management too.

Thursday, September 22, 2011

How to count multiple values in a histogram?

If I have a JIRA issue with a field that can have more than one value, how should a report count the values in all the issues? For example, issue TEST-1 has the values "Alice" and "Bob" in the field, and issue TEST-2 has the values "Bob" and "Charlie". Do the counts look like this:

Alice - 1
Bob - 2
Charlie - 1

or this:

"Alice, Bob" 1
"Bob, Charlie" 1

JIRA 4.3 and earlier chose the first way for custom multiselect fields. JIRA 4.4 and later have changed it to the second way (accidentally?) and some people are not impressed. I think that the first way seems more like a natural combination of the histograms of the different values.

Note that since JIRA enforces an order for all the options for a custom multiselect field we don't have to deal with the theoretical question of whether ["Alice", "Bob"] is the same as ["Bob", "Alice"].

Friday, September 16, 2011

Theoretical Administration Simplification

Any tool such as JIRA has many ways to control who can do what with it. For example, JIRA has permission, issue type, field configuration and all its other schemes. The number of dimensions of control has at least two consequences - performance and maintenance.

Performance - every piece of information that is shown to a user has to check that it is in fact supposed to be seen

Maintenance - how to define the permissions in a coherent manner, and then how to make them easy to maintain over time and by different people.

I can imagine solutions for the first consequence, since however the constraints are defined they can be converted to data structures that are reasonably efficient for each kind of checking. Not easy, but doable. But I think handling with the second problem is even harder.

For example, JIRA groups these permissions in one way but someone will always want to group them in another totally-unexpected way. How can that be made easier for everyone is not at all clear to me.

I've seen a massive permission matrix (ExtraView) but that was hard to comprehend. Whatever approach is used, a record of changes and differences between two points in time is also necessary for future maintainers.

Tuesday, August 30, 2011

Moving Custom Fields in JIRA Plugins

How can you change where a custom field type comes from in JIRA?

JIRA custom field types are defined in JIRA plugins, and are uniquely identified by their plugin key and field key. For instance if a plugin has a groupId "com.mycompany.jira.plugins" and an artifactId "myplugin", then (by default) the plugin key is "com.mycompany.jira.plugins.myplugin". A field key is something like "mycustomfield".

If I install such a plugin and create a custom field using the new custom field type, then what happens if I want to deploy the custom field type in a different plugin? I can see three choices:

1. Keep the same plugin key and field key - rather limiting

2. Create the custom field type in the new plugin, create a new custom field and migrate all the data from the old field to the new field. Then remove the old plugin.

3. Change the key of the custom field in the database.

The last option is probably the neatest in the long term, but it's an ugly way to have to administer a tool such as JIRA.

Does anyone have any better ideas? I suppose I could write a plugin that updates the database directly. What I'd really like is a way to have aliases for a custom field's type so that it could change over time.

Wednesday, August 17, 2011

Sort order of select lists in JIRA

I had an "surely I already knew that?" moment the other day. My select list custom field had values A, B and C. I changed the order in the configuration screen to be A, C and B. Yet when I displayed the field in the Issue Navigator list of issues and sorted by it, the issues were sorted alphabetically, not at all how I had configured.

It turns out there's a long-standing bug about this that needs some of your voting love: JRA-14161
Until it's resolved, you have to add a prefix to make the values sort the way you them to, e.g.

01 My First Value
02 Another Value

I can see what the underlying problem is - field contexts. A custom field in JIRA can have contexts associated with it, where a context is project and issuetype. Then you can have different sets of options per context for the same field., e.g.

My Custom Field

Project A, Issue Type T1, options A, B, C
Project A, Issue Type T2, options Z, Y, C

The problem is that there is no sort order defined between these two sets of options. And just because option C occurs in both sets doesn't mean that they would be sorted together since the order is defined per context too. Tricky.


Thursday, August 4, 2011

Adding components to JIRA automatically with a script

Both the SOAP or REST APIs for JIRA are missing a method to add a component to a JIRA project. The shell script below calls the appropriate URL to do this. File under "ugly but effective", and thanks to Justin for his handy post.


# Add components to a JIRA project.
# The parameters to the URL are encoded by passing them with -d

# Set this to the project you want to add components to


# Get the authentication cookie
curl -u $USERNAME:$PASSWORD --cookie-jar $COOKIE_FILE_LOCATION -sS --output /dev/null $DASHBOARD_PAGE_URL

for component in "Able Baker Charlie" "Lowly Work" "Huckle Cat"; do
  echo "Adding component: $component"
  curl --cookie $COOKIE_FILE_LOCATION --header "X-Atlassian-Token: no-check" -sS --output /dev/null -d "name=$component" -d "pid=$projectid" "$SERVER_URL/secure/project/AddComponent.jspa"


Monday, July 25, 2011

Oldest Active JIRA?

I've just seen an instance of JIRA 3.12 running happily on a public site. Does anyone know of even older versions?  I'd suggest obfuscating the URL a bit because there are a number of vulnerabilities in those old releases.


Wednesday, July 20, 2011

Second JIRA book available

The O'Reilly page for Practical JIRA Plugins is live! The second book follows the poultry theme of the first and has a duck on its cover. This book is a bit more technical than Practical JIRA Administration but should help anyone wanting to write their own plugins for JIRA.


p.s. Guess what I'm going to eat to celebrate this book!

Friday, June 10, 2011

No Need To Restart JIRA

Atlassian Summit has come and gone, and was a lot of fun. My book was well received, so I'm happy. Something else makes me very happy is the release of JIRA 4.4. Beta1 because now all JIRA plugins can be reloaded without restarting JIRA.

It's a simple thing but it used to suck so much time during plugin development. This time I was creating a new Active Objects plugin, so installed it as usual for a JIRA plugin. Then I rebuilt it and uploaded it from the JIRA plugin manager. Three clicks later the updated plugin was installed and working.



Monday, May 23, 2011

First JIRA book available

The O'Reilly page for Practical JIRA Administration is live! What everyone wants to know is which animal I got. The answer is chickens, big friendly chickens.


Saturday, May 7, 2011

Editing finished!

I've just finished editing my book "Practical JIRA Administration". Look for it from O'Reilly soon! If all goes well, there should be some printed copies available at Atlassian Summit in June.


Wednesday, March 9, 2011

Filing a bug doesn't fix the bug

I'm a bit puzzled by people who think that filing a bug automatically means that it will be worked on, never mind fixed. Complaints in the Atlassian JIRA about 7-year old bugs and feature requests are a misguided. A bug's priority doesn't naturally increase over time.


Thursday, March 3, 2011

More JIRA book news

The breaking news is that I just signed an agreement with O'Reilly to produce another book. The working title is "Practical JIRA Development" and the scope is JIRA administration and plugin development, just like this blog.

It's part of O'Reilly's push towards realtime publishing so it will be sweet and short. As Mike Loukides noted:

"We're looking for manuscripts that are roughly 30-70 print pages long"

The book will be written in DocBook and committed to a repository with automated builds of the book. Nice and agile!

JIRA Workflow Common Transitions

This post was written by Pat Callahan who describes his current position at Hara Software as "a little of this... a little of that", and some of that involves digging into JIRA.

Do you have something JIRA-related that you would like to write about? Or a topic you want see an article about? If so please contact me at

Common Transitions

JIRA workflows can have common transitions, which are transitions that are defined once but used from multiple statuses. The default JIRA workflow contains one common transition: Close. If you change it in one place then all the other places it is used are also changed. JIRA displays the names of such transitions in italics.

JIRA does not provide a way to define new common transitions. You can vote for that feature, but until then the only way is to edit the workflow XML directly.

What's so great about common transitions?

If you have a transition you need to create which is accessible from multiple points in your workflow, you could end up creating multiple duplicate instances of that transition, all of which are different.

This quickly becomes a nightmare if you are setting up post functions or other sorts of validations in that transition because you'll need to edit the transition in multiple spots.

How to Create Common Transitions

It's not hard but you will need a decent text editor and a rudimentary understanding of XML, or even HTML.

Step 1: download the workflow you want to fix from the workflows page (Admin, Workflows) and open it in your editor.

Take a moment and look at the file. You'll see the XML has several sections up at the top. One key section to call out is the "common actions" section. The tag is <common-actions>. In there, you'll see some sections like this: <action id="2" name="Close Issue" view="fieldscreen">. This one represents the "Close Issue" transition and will show up in the UI in Italics because it is in the "common actions" section. Naturally that XML tag is only the opening tag, so you'll need to have the closing tag too, which looks like this </action>. You should also note that this has an "id" value in the action tag. For "Close Issue" the ID is "2" in this example.

So now that we know "Close Issue" is a common action, you can scroll down through the XML to find an instance where it is used. Look for the section <steps> and you'll see something like this:

<step id="4" name="Resolved">
      <meta name="">5</meta>
        <common-action id="2" />

What this shows you with the last line is that in the "Resolved" step, there is going to be a close button. To do it, it's just referencing the common action for "Close Issue" by using the ID for it, e.g. <common-action id="2" />

Tip: JIRA's built-in IDs tend to be lower digits than ones created after JIRA installation, which tend to be in the 700's or 800's. Here's an example from one of my workflows:

<action id="751" name="To Review" view="fieldscreen">

Common transitions are created in the "Common Actions" area of the XML file and they are later referenced in each workflow step. That's how you can simplify your workflows so that when you edit one transition that is shared across the workflow, it changes everywhere. You just need to edit the XML and move at least one instance of your transition into the common actions section, and then put in a new reference to it in each workflow step.

Let's walk through that last paragraph.

Step 2: Find the action you want to move within the workflow step and move it to the common actions section.

For my example, I am looking for an action called "Send To Test" so I can move it into a Common Action.

<step id="4" name="Resolved">
      <meta name="">5</meta>
        <common-action id="2" />
        <common-action id="3" />
      <action id="781" name="Send To Test" view="fieldscreen">

Aha! The last line indicates which chunk of XML I need to move into common actions. Above it, you can already see other common actions referenced (ids 2 and 3 are for "close" and "reopen" in my workflow).

Cut the entire "action" tag, making sure to catch the closing tag as well. Move it into the Common Actions section at the top of the file. I wouldn't bother updating the ID because you won't be sure if any of those IDs are used in other JIRA workflows, so don't change it. Put it at the end of the Common Actions section just before the </common-actions> tag.

Step 3. Add the reference to your new common actions in the workflow step where you removed the transition. For me, it looks like this::

<common-action id="2" />
  <common-action id="3" />
  <common-action id="781" />  

You'll need to put this reference into any workflow step that needs it.

Save the file and upload the XML back to JIRA and you are done!


Neal Applebaum was an early contributor to how to do this on the JIRA Forums.

Tuesday, February 22, 2011

Starting JIRA automatically with FreeBSD

JIRA runs not only on Windows, OSX and Linux but also on FreeBSD. There are some unofficial installation steps which don't differ that much from the official Linux installation documentation.

This post describes how to make JIRA start automatically after a restart. But after starting it I realized that I can not only edit but also add pages to the Atlassian documentation (and so can you). So I did and the result is Starting JIRA Standalone automatically on FreeBSD.

Wednesday, January 19, 2011

What's a "metatracker"?

There's an updated Python document about how the Python development team should triage issues. While every team does this differently, it's interesting to compare concepts in another system to the same ideas in JIRA. There's also a reference to a "meta tracker", defined as "the tracker about the issue tracker". I suppose the canonical example of a meta tracker is the Atlassian JIRA instance at

It's a useful word for me because I often end up having to create a JIRA project or component for clients for tracking the changes they want to make to JIRA. Now I can refer to it as the metatracker and say things like "the tracker is the meta tracker". Just not with a straight face.


p.s. The technical review work on the upcoming JIRA book is proceeding nicely, but I've heard no news on a release date yet.