Why Wait for a New Release of JIRA?

Why Wait for a New Release of JIRA?

At my company, we rely pretty heavily on our feature/bug tracking system, JIRA. All of our customer requests are logged and tracked there, as well as any internal problems or handy little improvements we come up with. Each week, we gather around the old conference call phone and hash over a list of issues that have been added/updated since our last chat. The system works great; its a really nice way to keep everyone in the loop on whats going on across 2+ offices and 2+states/countries. And it can usually be done in 1-2 hours.

JIRA is web-based, and typically the call host will open the week’s issues in browser tabs. Sometimes the presenter has set up a browser in advance, and sometimes even done something as fancy as set up an RSS (one click -> all the tabs open up at once!) But more often than not the first 2-3 minutes are eaten up by the presenter right clicking and opening each of about 40-50 issues into a new tab. It doesn’t make for engaging conversation. It also looks like you’re chronically underprepared if you decide to use the same great idea for discussing issues with customers….

Enter Greasemonkey. Greasemonkey is a framework for running your own browser Javascript on any web page you can get to through Firefox. The semantics are the same as if you were writing javascript on the server side; it’s code that gets run by the browser after an HTML page has been downloaded and rendered. Perhaps Greasemonkey can help us out here…

JIRA issues are tagged with a project code (example here is JIRA), followed by a sequence number. Each issue can be fetched via the URL /jira/browse/JIRA-999. If I were a JIRA developer and was asked to implement this feature, I could write a simple javascript loop to open all these links in new windows (not all browsers support tabs, and believe it or not, not all users use tabs; best to let their preferences decide how to open all these links).

So here’s such a loop in javascript:

function openIssuesInTabs() {
    var anchors = document.getElementsByTagName( 'a' );      
    for( var i = 0; i < anchors.length; i++ ) {      
        if( anchors[i].href.match( \'/jira/browse/\' ) != null ) {         
            if( anchors[i].href.match( anchors[i].innerHTML ) ) {            
                window.open( anchors[i].href );         
            }
        }
    }
}

I’m not terribly concerned with performance at the moment; we’re just getting started. All this loop does is find all links matching the pattern identified above: that the URL is correctly formatted, and the inner HTML text matches the anchor URL. There are a few duplicate image links; this check makes sure we only open one tab per issue.

But of course, we need a way to trigger this loop somehow. It makes little sense to pop open tabs every time; the result page would become useless. We can use a little more Javascript to render a link on the search result page:

var permLinkDiv = document.getElementById( 'permlink' ).parentNode;
permLinkDiv.innerHTML = ' \ [ <a id="openTabs" rel="nofollow" onclick="javascript: \
    var anchors = document.getElementsByTagName( \'a\' );  \
    for( var i = 0; i < anchors.length; i++ ) { \
        if( anchors[i].href.match( \'/jira/browse/\' ) != null ) { \
            if( anchors[i].href.match( anchors[i].innerHTML ) ) { \
                window.open( anchors[i].href ); \
            } \
        } \
    }" href=" ' + window.location.href + ' ">Tabs</a> ] ' + permLinkDiv.innerHTML;

This little snippet will render a text hyperlink next to the “Permalink” navigation control on the search result page. The location is actually arbitrary; there’s nothing to stop me from rendering it elsewhere on the screen. I just picked a link that the JIRA developers were kind enough to add an “id” attribute to. Note that I’ve set the script as the onClick attribute, and the current page as the href. This will make sure the source window remains on the same page after I spawn my tabs.

Installing the greasemonkey script involves adding it via the Greasemonkey Firefox plugin. The plugin requires that you specify a match string so it can tell what pages to run your script against. I can add the domain of our issue tracker, and the name of the search results page as the match string. Now when I open the search results page in JIRA, I see a “Tabs” link rendered within the page (CSS consistent, too!) Click on the link and viola! A neat collection of tabs for all issues listed on each search result page.

But how can I share this goodness with my teammates? Easy. A free compiler exists to compile your Greasemonkey script into a Firefox extension. It’s limited to a single browser (Firefox), but a Greasemonkey script could only be run within Firefox anyway. The compiler emits a *.xpi file formatted for Firefox. My teammates need only open this file in Firefox to install it. They don’t even need to install Greasemonkey!

Ahhhh… now if only I could make these calls more interesting….