Handling large numbers of JIRA projects

Once you have a large number of projects in JIRA creating an issue can become a bit tedious, scrolling through the long list of projects to choose just the right one. JIRA (Enterprise edition) already provides Project Categories that you can group projects into, so without further ado, here's a JSP hack to reduce the size of that list of projects by letting you select a project category first.

Installation

The modified file for JIRA 3.13 is createissue-start.jsp and replaces the file of the same name in your JIRA instance. There should be no need to restart JIRA. The usual disclaimers apply, drink responsibly, don't drive and derive etc.

Making it easier to maintain JIRA workflows

This is one for JIRA admins.

I've had to track down a few problems recently that were related to fields not appearing on screens, especially when issues were changing their status. The cause turned out to be customized Transition Screens. A Transition Screen is the screen that is shown while you are moving from one status to another, and it's easy to forget which screen goes with each transition.

Sure, you can click on each transition and look for which screen is being used, or you can look at the list of screens and see which transitions used each screen. However, as the number of transitions and screens begins to grow, workflows become harder to maintain. The precision hack shown here helps with this. Click on the image to enlarge and look at the "Transitions" column. Each line has had the text "with the screen "added.




When you view any JIRA workflow with the "View Workflow Steps" screen, the transitions between steps (statuses) now have their screen information shown as well. At a glance, you can now look at a single workflow and see which of your transitions have those troublesome custom transition screens.

The file to change is

atlassian-jira/secure/admin/views/workflow/viewworkflowsteps.jsp

and the modified version can be found here. This was tested with JIRA 3.13.2 and is also a good example of what you can do with JSP if you have to.

Making Bugzilla Read-only

I finally got this working after a few frustrating attempts. So, what not to do first.

Change database-level user permissions

I actually got this working once but it took three or four iterations since Bugzilla needs to be able to write to some tables to let you log in. Also, once you have messed with the permissions, I find restoring them to the prior state to be fiddly. This approach is really at the wrong level.


The editbugs group

There's a system level group in Bugzilla named "editbugs" that is apparently related to allowing a user to edit bugs. However removing a user from the group does nothing that I could see.

What Worked For Me

1. For each product, check the Closed checkbox so that the product does not appear in the list of products where bugs can be created. This effectively stops new bugs from being created, though perhaps using the right URL might still work.

2. Define a new group named something like "CanStillEdit" that can be used for bugs and add it to all products. Don't add anyone to the new group yet.

3. For each product, edit the group memberships at the end of the configuration page and set the "Can Edit" checkbox for just the CanStillEdit group. Leave all of the other groups unchanged. Now only members of the CanStillEdit group can edit bugs. It took a few passes through the documentation about this feature to see what they meant.

If all goes well then trying to save a change to a bug will produce a big red box with an error message in it. Usually the error message is helpful ("you do not have permission to do that"), but sometimes it says things like "you tried to update X from to 123" which is confusing but harmless. Search works just as before.

Other details:

1. The other settings for the groups I was working with were Shown/NA.
2. Administrators can also still edit issues.
3. All this is for Bugzilla 2.x - I would hope that there are better ways to do this in the latest versions.

Unexepected side effects in shell scripts

Shell scripts that fail to preserve the expected environment are a waste of everyone's time. For instance, you call a function which changes the current directory to somewhere else for its own purposes but fails to change back on all exit paths from the function. Trying to remember which directory you might be in later on becomes combinatorially difficult as more conditional statements are added over time. To make it more concrete:

BAD:

function MyFunction() {
   cd some_random_directory
   # Do something useful
}

GOOD:

function MyFunction() {
   # Change to the necessary directory
   pushd some_random_directory

   # Do something useful

   # Now pop the directory off the stack    
   cd -
}

If you have conditional statements, then make sure you catch them too:

BAD:

function MyFunction() {
   # Change to the necessary directory
   pushd some_random_directory

   # Do something useful and test something
   if [ "${test}" == "value" ]; then
       return # Oops, this function left us somewhere unexpected
   fi

   # Now pop the directory off the stack    
   cd -
}

GOOD:

function MyFunction() {
   # Change to the necessary directory
   pushd some_random_directory

   # Do something useful and test something
   if [ "${test}" == "value" ]; then
       # Don't forget to pop the directory off the stack    
       cd -
       return
   fi

   # Now pop the directory off the stack    
   cd -
}

Basically, preserve an expected and known state between function calls, just like any modern other programming language.

Thoughts on Making Things

It's time to get some thoughts out of my head about making things. Physical things, software things, relationship things. You know, things. That's what engineers do after all.


Nothing is Monolithic

Nothing created by people is a monolith. It's always made up of smaller things. Something may seem greater than the sum of its parts, but only by how we treat it. Really, it is just a number of things put together.
For instance, a beautiful painting may well move me greatly, but at one level it is still flecks of paint on canvas.

Everything is a Hack

"Hack" in the sense of changing a thing to work around a problem. Nothing created by humans springs fully formed into existence; everything is an extension of what came before. Whatever you see around you has taken multiple versions to become what it is now.

Everything looks different when you think about how it was made

This was an epiphany for me at eighteen, when I began to look around me and ask "how was that thing made?". Once you consider how a thing could have been produced, you understand that thing in a different way. And just as children are no less marvelous after you've read a book on reproductive science, software and hardware is still amazing even when you're the one creating it.

Python + bash + ssh = too many layers!

I was reminded by a recent project that many (most?) hardware failures occur at the connections between things. That's why percussive maintenance gets results. I was writing a tool to execute lots of commands remotely on multiple machines, with the different commands being synchronized from one machine. I chose to write the tool in python, and that made creating it nice and easy.

But the shell commands to be executed had to be communicated to each machine. Now I could have written all the commands and their arguments (some of which contained the dreaded spaces) into separate files, copied them over with scp and executed them remotely. Except that there was a fair amount of analyzing of results and deciding what to run next based on the results of the analysis. This is generally tedious to do with bash and can be hard to maintain.

So I decided to keep the control logic in the python tool and use ssh to send each command separately to the remote machines. Which works, but the extra headache of getting all the spaces escaped and quoted added a major amount of maintenance pain to the tool. I could have encapsulated it all more cleanly, I'm sure, but it all "just grew" in scope and size.

The final block in this tottering tower was that some of the commands had to be run using sudo, but not all of them. Getting all those sudo strings in the right place took a few hours of my life from me without feeling that I got much for it. So it goes.

I've tried using CORBA, WebServices etc over the years, but they feel pretty heavyweight for this sort of thing. So the question I'm asking myself is: how could I have done it better?

The largest, longest-lasting hack ever?

Hack, in the sense of "workaround", created by humans, elegant or not, and not restricted to computing.

My current contender is upper and lower case letters in English. It's like mixing two fonts in the same document. If scribes and early printers wanted ways to break up text, making different shapes for the same letters is an odd way to do it. Maybe space constraints were their real problem?

And what about double quotes? Someone came up with the idea of using a small mark before and after a word or phrase to set apart. Then someone else decided to just use the same marks twice. I'm surprised we haven't seen triple and quad quotes appear over the centuries.

What's your vote for the longest-living and largest hack in the history of humanity?