This blog is on hold

There's not been much posted in this blog for the last year because most of my JIRA-related blogs have been published on the official ServiceRocket blog at http://www.servicerocket.com/blog. I recommend following that blog instead for JIRA and other Atlassian posts.

I'm still heading up the Atlassian consulting work at ServiceRocket and I'll be attending Atlassian Summit 2014 in San Jose, CA in a few weeks. I'm part of the "Governing JIRA at Scale" presentation from Jordan Dea-Mattson of Yahoo.

Finally, I'm considering an update for Practical JIRA Administration sometime later this year.

Book Update

The third update of Practical JIRA Administration for JIRA 6 has just gone into production at O'Reilly.

Apart from the updates for the new features in JIRA 6 I've also added a chapter about JIRA Migrations,  with lots of advice about moving data into JIRA from other systems.

~Matt

All the good bugs are old bugs?

JIRA lets you vote on issues, and Atlassian's own JIRA instance has a few issues with thousands of votes. I wondered if there were any popular issues that had been created recently so I plotted the number of votes against when each issue was created.

The result is shown below. I think it means that Atlassian are already aware of what people really want from their product, or perhaps that they're doing a good job closing new issues as duplicates of older ones. What other meanings can you take from this chart?

Book Update

Now that JIRA 6.0 has been released I've started the update for Practical JIRA Administration. If you have any changes you'd like to suggest for the book then now is a good time to contact me.

Where's Matt?

This blog's been quiet for a while now due to my consulting work at CustomWare ramping up. We're always looking for more consultants to help with the load. It's never the same day twice!

Both of the O'Reilly JIRA books were updated, and Practical JIRA Administration is scheduled to be updated for JIRA 6.0 in the next few months.

And my personal choice for the most useful JIRA add-on for JIRA administrators is Script Runner by Jamie Echlin. His hours of work have saved me hours of work. Thanks!

Really making a JIRA project read-only

Sometimes you want to make a JIRA project read-only, perhaps for archive purposes. It's easy enough to create a permission scheme that gives Browse Projects permission to the same users and removes everyone from the Edit Issues permission. However issues can still change status. That's right, the Edit Issues permission does not stop you from reopening an issue.

The workaround is simple if tedious. Add a condition to every transition in the workflows used by that project. The condition should check that the current user has the Edit Issues permission.

After pondering this for a few minutes, I think that the default JIRA workflow should have this condition on all of its transitions but that's probably not likely to happen. Anyway, I updated http://confluence.atlassian.com/display/JIRA/Archiving+a+Project to make this clearer. 

My Atlassian Batting Average

There's a baseball statistic named Batting Average that measures the number of successes compared with the number of attempts. I've created many bugs for Atlassian over the last seven years, so I thought I'd see what's happened to them.

Depending on how you measure success my batting average is up somewhere near 0.6, which is higher than I expected. 

Allowing anyone to submit a bug was, and still is, a huge stance for a company to take. Kudos to the Atlassian teams that manages to process all those issues!

JIRA Plugins and Permissions

I had an interesting problem today. I had uploaded a new version of the MDSF plugin to http://plugins.atlassian.com (PAC) but when I tried to install it from within JIRA using the plugin manager, I got the errors "Check that the file is a valid plugin" and "not a valid plugin: Could not open the file as a jar". The odd thing was the plugin jar file could be downloaded just fine from PAC and installed with no errors.

In this case the actual plugin jar file is stored as an attachment in the MDSF space of https://studio.plugins.atlassian.com and that was the root of the problem. I eventually tracked the bug down to a permission problem where anonymous users such as JIRA's plugin manager couldn't access the attachment. Once I set the View permission for Anonymous users in Space Admin everything worked nicely.

I think the reason it worked fine from within PAC is that I had saved the userid and password for SPAC, so I never saw a login screen and mistakenly assumed that no-one else did. There was also the question of whether it mattered that the attachment used an 'http' or 'https' connection - I think it made no difference.

Quora and JIRA

Quora seems to have become somewhat odd. I followed the JIRA category and replied to a few questions over the past few months but some things have began to bother me about Quora.

- you can't see who asked a question, and that's apparently deliberate
- many questions seem to be from non-JIRA users (perhaps they were paid to stimulate the JIRA category)
- most questions are so vague ("how does JIRA compare to A,B,C, .. Z")

I've deactivated my Quora account for now. I still follow StackOverflow, LinkedIn and of course Atlassian Answers.

A rose by any other name

Ah, the perils of choosing a product name. JIRA has long confused many people so Atlassian added a FAQ about how to pronounce it - "JEEra". That's still not totally clear though, since 'j' is so different in many languages. I've heard 'ji-ra' with a long 'i', 'here-a' with a Spanish soft 'j', and just recently 'sheer-a', probably a Chinese variant.

Anyone heard any others?

Network Diagrams in ASCII Art

The RFCs that define the internet often use ASCII art to describe protocols. It always struck me as being like assembly code for diagrams. This week I came across a client using ASCII art in a JIRA custom field to document a network configuration for a bug. They even had a neat symbol for a wireless network:

AP))) (((User

I like the artist-mode in emacs for producing this kind of thing, though I suppose you could even write raw dot files for GraphViz since that's rather like Wiki markup. All feels a bit last millenium though?

~Matt

JIRA Administration Scaling

The table above is from a slide in Atlassian CEO Scott Farquhar's presentation about the upcoming JIRA 5 Release. It shows some details about how organizations use JIRA, and agrees with what I see at CustomWare's clients.

1087 projects, 1231 custom fields, 361 workflows - so how do their JIRA administrators manage all that?
There's the Hundred Tab Problem to deal with, where changing a scheme has to be done through the UI for each project in turn. And then there's the bigger problem of not being able to see how schemes differ.

I think the answer is that they must have their JIRA configuration thoroughly documented and always make the changes in a staging server first.

JIRA View Screen and Tabs

JIRA continues to surprise me after all these years. I was in the middle of a customer demo and added a new field to  a screen. Then I went one step further and moved it to a new tab. The field stubbornly remained where it had been and no new tab appeared. "What's that all about?" I thought. It turns out that it's documented behavior:

• Fields of type 'Date' can only be displayed in the 'Dates' area of the screen, even if they are custom fields.
• System fields on the default 'View Issue' screen (e.g. Summary, Security Level, Issue Type, etc.) are fixed and cannot be moved onto a separate tab. However, any other custom fields (excet 'Date' fields) that have been added to the 'View Issue' screen can be moved onto a separate tab. This restriction only applies to the screen associated with the 'View Issue' operation, i.e. system fields can be moved onto other tabs for screens associated with operations such as 'Create Issue', 'Edit Issue', etc.

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">
(function($){
    $(document).ready(function(){
        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
            }
        }
    });
})(AJS.$);
</script>

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

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.

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.

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.

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.