Did you know you can embed Javascript in JIRA via custom fields? You may wonder, what’s the point? To you good sir, or madame, I say that the point is 75% because you can, and 75% because it enables customization of the JIRA interface without having to resort to writing JIRA plug-ins. And because JIRA ships with jQuery 1.8.3 in JIRA 6, it makes writing complex Javascript a breeze.

Just recently I needed to customize the appearance of the built-in Environment field in the Details section when viewing an issue. To reduce configuration complexity Atlassian actually embeds the look and feel of some of the default fields inside velocity templates which are themselves includes as resources in JIRA JAR files.

In other words, you cannot modify these settings through normal means.

So I created a custom field and added it to my default view and field configuration. I called the custom field "JS Custom Field". It is the one field into which I’ll embed all of my Javascript. I decided to use a single-field approach to centralize my changes as well as preserving the descriptions of the fields I may want to modify with the Javascript. Because that’s where you actually embed your Javascript — in the descriptions of the fields. Crazy, right?

Right out of the gate I wanted to accomplish two things:

  • Customize the look and feel of the Environment field in the Details section when viewing an issue.
  • Transform a multi-select custom field I created into an autocomplete text box.

Oh, and while the custom field that will contain my Javascript has to be added to the DOM in order for its Javascript to be loaded, I do not actually ever want any users seeing it. So the Javascript must also ensure that the custom field is never seen, and can never be made to be seen.

And thus this little bit of Javascript was born. It:

  • Customize the look and feel of the Environment field in the Details section when viewing an issue.
  • Transforms a multi-select custom field into an autocomplete box.
  • Prevents users from ever seeing or making visible the custom field that contains the Javascript.

Please note that my custom field IDs will be different than yours. You should use Chrome’s Developer Tools (or some other browser’s) to determine the IDs of your custom fields.

<script type="text/javascript">
    
    /**
     * The ID of the custom field that contains this javascript and that will
     * be hidden from the user.
     */
    JAVASCRIPT_FIELD_ID = '10313';

    /**
     * The common usage pattern for the javascript field ID.
     */ 
    JAVASCRIPT_CUSTOM_FIELD_STR = 'customfield_' + JAVASCRIPT_FIELD_ID;

    /**
     * The Environment val selector.
     */
    ENV_VAL_SEL = '#environment-val';

    /**
     * The Environment field selector.
     */
    ENV_FIELD_SEL = '#field-environment';

    /**
     * The selector to use to get the Environment field if it's been detwixed.
     */
    ENV_FIELD_DETWIXED_SEL = '#field-environment.user-content-block';

    /**
     * The vC Ops Version custom field ID.
     */
    VC_OPS_VER_FIELD_ID = '10305';

    /**
     * The vC Ops Version field selector.
     */
    VC_OPS_VER_FIELD_SEL = '#customfield_' + VC_OPS_VER_FIELD_ID;

    /**
     * The selector to get the "Edit Issue" button.
     */
    EDIT_ISSUE_BUTTON_SEL = '#edit-issue';

    /**
     * The selector to get the 'All' or 'Custom' links that change the view of 
     * the field picker popup.
     */
    FIELD_PICKER_VIEW_SEL = '#inline-dialog-field_picker_popup a[class*="configurable"]';

    /**
     * The selector to get the control in the field picker popup that toggles
     * the visibility of the custom field in the editor dialog.
     */
    FIELD_PICKER_TOGGLE_SEL = '[data-field-id="' + JAVASCRIPT_CUSTOM_FIELD_STR + '"]';

    /**
     * The selector to get the custom field on the editor dialog when the 
     * 'Custom' view is enabled.
     */
    EDIT_FIELD_CUSTOM_VIEW_SEL = '#qf-field-' + JAVASCRIPT_CUSTOM_FIELD_STR;

    /**
     * The selector to get the custom field on the editor dialog when the 
     * 'All' view is enabled.
     */
    EDIT_FIELD_ALL_VIEW_SEL = 'div.field-group:has(textarea#' + JAVASCRIPT_CUSTOM_FIELD_STR + ')';

    /**
     * The selector to get the editor popup.
     */
    EDIT_ISSUE_DIALOG_SEL = '#edit-issue-dialog';

    /**
     * The selector to get the "Configure Fields" button on the edit dialog.
     */
    CONFIG_FIELDS_BUTTON_SEL = '#qf-field-picker-trigger';

    /**
     * The selector to get the field picker popup.
     */
    FIELD_PICKER_POPUP_SEL = '#inline-dialog-field_picker_popup';

    /**
     * The field that stores the interval ID set when listening for the field
     * picker popup.
     */ 
    var fieldPickerPopupIntervalId = -1;

    /**
     * Converts a multiselect control into a multi-select text field with 
     * autocomplete capabilities.
     *
     * multiSelector The multiselect control's selector.
     */
    function convertMultiIntoAutoCompleteTextArea(multiSelector)
    {
        if ($(multiSelector+ "-textarea").length) return;
        new AJS.MultiSelect({
            element: $(multiSelector),
            itemAttrDisplayed: "label",
            errorMessage: AJS.params.multiselectComponentsError
        });
    }

    function removeMultiSelectNoneOption(multiSelector)
    {
        $(multiSelector + " option[value='-1']").remove();
    }

    /**
     * Removes the twixification of the Environment field on the issue's view
     * page inside the Details section. This makes the Environment field a 
     * normal text area, such as the Description field.
     */
    function deTwixifyEnvField()
    {
        // Modify the environment field in the issue's details view.
        div_env_val = $(ENV_FIELD_SEL);
        if (!div_env_val.length) return;

        div_env_val.attr('class', 
            'field-ignore-highlight editable-field inactive');

        div_env_field = $(ENV_FIELD_SEL);
        div_env_field.attr('class', 'user-content-block');
        div_env_field.find('div:first-child').removeClass();

        div_env_val.find('a:first-child').remove();
    }

    /**
     * Removes the custom field from the editor dialog.
     */
    function removeEditField()
    {
        target = $(EDIT_FIELD_CUSTOM_VIEW_SEL);
        if (!target.length) target = $(EDIT_FIELD_ALL_VIEW_SEL);
        target.remove();
    }

    /**
     * Removes the anchor that allows a user to enable the custom field on the
     * editor dialog.
     */
    function removeFieldPicker()
    {
        $(FIELD_PICKER_TOGGLE_SEL).remove();
    }

    function listenForEditIssueDialog()
    {
        // We only care about when the edit issue dialog is available.
        if (!$(EDIT_ISSUE_DIALOG_SEL).length) return true;
        
        // Get rid of this listener as quickly as possible, it's expensive.
        JIRA.unbind(JIRA.Events.NEW_CONTENT_ADDED, listenForEditIssueDialog);

        // Hide the javascript fields from the editor.
        removeEditField();

        // If the user decides to look at the field picker, don't show
        // the option to enable the javascript fields.
        $(CONFIG_FIELDS_BUTTON_SEL).one('click', registerFieldPickerPopupListener);
    }

    function registerFieldPickerPopupListener()
    {
        // Don't register it if it's currently registered.
        if (fieldPickerPopupIntervalId > -1) return;

        fieldPickerPopupIntervalId = 
            window.setInterval('listenForFieldPickerPopup()', 50);
    }

    function listenForFieldPickerPopup()
    {
        // We only care about when the field picker popup is available.
        if (!$(FIELD_PICKER_POPUP_SEL).length) return true;

        fieldPickerPopupIntervalId = -1;
        window.clearInterval(fieldPickerPopupIntervalId);
        
        // Get rid of this listener as quickly as possible, it's expensive.
        JIRA.unbind(JIRA.Events.NEW_CONTENT_ADDED, listenForFieldPickerPopup);

        // Hide the field picker links from the user.
        removeFieldPicker();

        // Hide the editor fields again as well in case the field picker
        // view changed. This can result in the editor fields being added
        // back to the editor popup.
        removeEditField();

        // If the user decides to change the field picker's view then we need
        // to prepare to remove them once again.
        $(FIELD_PICKER_VIEW_SEL).one('click', registerFieldPickerPopupListener);
    }

    function registerEditIssueDialogListener()
    {
        // This is kind of expensive, but necessary. That's why we're limiting
        // it to when the user clicks the Edit button instead of leaving it
        // enabled at all times.
        JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, listenForEditIssueDialog);
    }

    function listenForEnvironmentField()
    {
        if ($(ENV_FIELD_DETWIXED_SEL).length) return true;
        deTwixifyEnvField();
    }

    function listenForVcOpsVersionField()
    {
        if (!$(VC_OPS_VER_FIELD_SEL).length) return true;
        removeMultiSelectNoneOption(VC_OPS_VER_FIELD_SEL);
        convertMultiIntoAutoCompleteTextArea(VC_OPS_VER_FIELD_SEL);
    }

    function processVcOpsVersionField()
    {
        // Convert the vC Ops Version select box into an autocomplete text area.
        AJS.toInit(listenForVcOpsVersionField);
        JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, listenForVcOpsVersionField);
    }

    function processEnvironmentField()
    {
        // Silly Atlassian, twix are for kids!
        AJS.toInit(listenForEnvironmentField);
        JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, listenForEnvironmentField);
    }

    // When the 'Edit Issue' button is clicked we want to listen for the
    // appearance of the edit dialog.
    $(EDIT_ISSUE_BUTTON_SEL).click(registerEditIssueDialogListener);

    // Process the fields.
    processVcOpsVersionField();
    processEnvironmentField();

</script>

I’ve been doing heavy refactoring over the last 48 hours to cope with epic VMware fail. One part of that has been the necessity to do something pretty tricky, and as it turns out, Apache Commons has a massive shortcut I thought I’d share with the rest of you. Imagine there are multiple tree branch paths and let KX equal the terminating value:

A.B.C.D.K1
A.B.K2
D.K3

I needed to merge these paths so that I ended up with one hierarchy:

A
|
|--B
    |-- K2
    |
    |--C
        |
        |--D
            |--K1
            |--K3

I knew how to do this merge with linear performance, but I was trying to come up with a solution that was more optimal. It turns out Apache already has one, and it’s called Hierarchical Configuration. Basically you just do the following:

import org.apache.commons.configuration.HierarchicalConfiguration;

HierarchicalConfiguration hc = new HierarchicalConfiguration();
hc.addProperty(“A.B.C.D”, “K1”);
hc.addProperty(“A.B”, “K2”);
hc.addProperty(“D”, “K3”);

The object will create new branches if the paths do not yet exist, but if they do, the values will simply be inserted into the appropriate location. This has been a massive timesaver and hopefully you all will find it useful as well.


I did not find any good documentation on how to update a git submodule reference to the HEAD of a branch so I created some projects on github.com to illustrate how to do this in a straightforward manner. See https://github.com/akutz/SubHead to learn more.


So I farked up when I was building several MSI packages using the Microsoft Windows XML (WiX) Toolset. I broke a sacred covenant of MSI development and violated the component rules.

This would not normally be a huge concern since the members of the components, the files, are not going to change. However, I did run into an interesting issue. Because my company’s versioning scheme is MAJOR.MINOR.REVISION.BUILD where BUILD is a value auto-incremented by the build server, as far as MSI is concerned 4.0.0.123 is the same version as 4.0.0.187. And because our patch strategy is to simply release a hot-fixed MSI, we have to allow same-version upgrades.

Anyone familiar with MSI upgrades knows the dirty secret that allowing same version upgrades allows same version downgrades. Except these downgrades would result in files disappearing from the filesystem. After much research I determined the issue was because of my stupid decision to group multiple files into single Components. MSI was not applying the standard file versioning rules correctly, and thus during a downgrade the following steps were occurring:

  1. Version X is installed on a system and user attempts to install version X-1.
  2. The installer appears to calculate which Components need to be installed by version and date. It does not include the X-1’s Components because they are already on the system.
  3. The installer removes X’s Components from the file system.
  4. Finally, the installer chooses not to install X-1’s Components because the installer has already calculated that the Components on the filesystem, at version X, were newer.

I found myself in quite a pickle. How do I prevent same version downgrades when the only varying component of the version is the 4th component (which again, MSI ignores)?

Continue reading ‘Preventing Same Version Downgrades with WiX’


Grove-unmade

08Mar11

Last fall I waited in eager anticipation for my Grove Bamboo case. Simply put, Grove makes these wonderful, beautiful, bamboo laser-cut iPhone cases. In fact, they are now making one for the iPad as well. However, I must warn possible purchasers of the Grove cases that even through everyday use, your work-of-art case will likely fail within six months. Here is a picture of the bottom half of mine now:

Broken Grove Bamboo iPhone4 Case

Broken Grove Bamboo iPhone4 Case

One cannot argue that the Grove made iPhone4 case is nothing less than perfect. I have received more comments on how amazing the case is then I can count. However, for $89, a case should not fall apart after taking the bottom half of it off an on on a regular basis just so you can dock it or plug it into a car charger. That said, I may buy another one eventually, if Grove has strengthened their manufacturing process (and glue that holds the black trim to the bamboo). For now I’ll probably invest in a Vapor case that is all aluminum. Should help block the attenuation issues with my phone anyway.


Let me just say right off the bat, that I hate, hate working on Functional Specifications, and the reason for my loads of loathing is the user interface (UI). Managers want specifications to include screenshots of the UI, but as I’ve tried to explain, it is a chicken-and-the-egg situation. Do you want a specification, or do you want me to work on the UI?

The answer to this problem is usually creating wireframe mockups of the eventual UI. However, I’ve yet to find a mockup tool that I like. I’ve tried tools like Visio and OmniGraffle which are good tools, but they focus more on diagraming and process flow than wireframe design. Not to mention the aforementioned applications share a particular trait with an almost standard for creating mockups — Axure — complexity. The barrier to entry for these applications for doing something as simple as creating mockups is relatively high. I have longed for something simple, powerful, and straight-forward.

And then I found Balsamiq Mockups.

Continue reading ‘I Love Balsamiq Mockups’


At least one EMC customer has reported issues with running VSI 4.0 on a system with a non-English locale. Unfortunately that is to be expected. I mentioned in a tweet a few days ago that VSI 4.0 does not currently support non-English locales at this time, and I’d like to take the opportunity to explain why.

Continue reading ‘VSI 4.0, i18n, and Localization’




Follow

Get every new post delivered to your Inbox.