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.