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"].

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.

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.

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.

~Matt

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.

~Matt


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


USERNAME=admin
PASSWORD=admin
SERVER_URL="http://jira.example.com:8080"
# Set this to the project you want to add components to
projectid=10001


DASHBOARD_PAGE_URL=$SERVER_URL/secure/Dashboard.jspa
COOKIE_FILE_LOCATION=jiracoookie


# 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"
done


rm $COOKIE_FILE_LOCATION

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.

~Matt

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.

~Matt

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