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.