Atlassian Jira. Admin evolution. Part 10

[#1]

Part 9

Javascript: changes by the source code

If you look through the source code you will find the NEW_CONTENT_ADDED event. This event has the following reasons:

pageLoad: "pageLoad",
    inlineEditStarted: "inlineEditStarted",
    panelRefreshed: "panelRefreshed",
    criteriaPanelRefreshed: "criteriaPanelRefreshed",
    issueTableRefreshed: "issueTableRefreshed",

    //Fired when on List View, when we update the issue row with new information
    issueTableRowRefreshed: "issueTableRowRefreshed",

    //Fired when the Filters panel is opened
    filterPanelOpened: "filterPanelOpened",

    //Fired when the LayoutSwitcher has been rendered
    layoutSwitcherReady: "layoutSwitcherReady",

    //Fired when the user goes back to the search (JRADEV-18619)
    returnToSearch: "returnToSearch",

    //Fired when the Share dialog is opened
    shareDialogOpened: "shareDialogOpened",

    //Fired when the Search Filters results table has been refreshed
    filtersSearchRefreshed: "filtersSearchRefreshed",

    //Fired when the Search Dashboards results table has been refreshed
    dashboardsSearchRefreshed: "dashboardsSearchRefreshed",

    //Fired when a Tab is updated (eg: Project tabs, Manage Dashboard tabs...)
    tabUpdated: "tabUpdated",

    //Fired when a Dialog is ready to be displayed
    dialogReady: "dialogReady",

    //Fired when the Components table is ready
    componentsTableReady: "componentsTableReady",

    //Fired when a Workflow has been loaded on Project configuration
    workflowReady: "workflowReady",

    //Fired when a Workflow Header has been loaded on Project configuration
    workflowHeaderReady: "workflowHeaderReady",

    //Fired when content on the page was changed that does not fall into an alternative reason. This should be used
    //instead of creating new reasons. The NEW_CONTENT_ADDED API paradigm should be moved away from for new
    //development where possible.
    contentRefreshed: "contentRefreshed"

When the create dialog screen has been loaded the dialogReady reason is passed to the NEW_CONTENT_ADDED event and at this moment we should set the Approver field. That is why we need to subscribe to the NEW_CONTENT_ADDED event and look for the dialogReady reason. Let's do it.

$(function () {
         JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, function (e, $context, reason) {
            if (reason == JIRA.CONTENT_ADDED_REASON.dialogReady) {
              $("#customfield_10301").val("manager1");
              $("#customfield_10301").focus(function() {
                 this.blur();
            });
            } 
        });
});

And it works correctly. We can add lines for hiding the summary filed to the same block:

      $(function () {
         JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, function (e, $context, reason) {
            if (reason == JIRA.CONTENT_ADDED_REASON.dialogReady) {
              $("#customfield_10301").val("manager1");
              $("#customfield_10301").focus(function() {
                 this.blur();
              });
              $("input#summary").val("mapping");
              $("input#summary").parent().css("display", "None");
            } 
         });
      });

And everything works as expected without delays and browser freeze:

Well, now we need to implement another feature.

If the Reporter is admin then the Approver must be manager1 in all other cases the Approver must be manager2.

Let's make changes:

$(function () {
         JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, function (e, $context, reason) {
            if (reason == JIRA.CONTENT_ADDED_REASON.dialogReady) {
              if ($("optgroup#reporter-group-suggested > option:selected").val() == "admin") {
                $("#customfield_10301").val("manager1");
              } else {
                $("#customfield_10301").val("manager2");
              } 
              $("#customfield_10301").focus(function() {
                 this.blur();
              });
            } 
         });
      });

And if we open the create dialog it will define the Approver correctly:

But if we change the Reporter field to user2, the Approver will not change:

Why? The problem is that the dialogReady reason works only once after the dialog was loaded and when we change the value of the Reporter field, nothing happens. What should we do?

We can go back to setInterval. But again we will have browser freezes and delays. Let's have a look at the source code.

And I did not find anything good in the source code. That is why we will just bind the onchange event to the reporter field and set the Approver field according to the new value of the Reporter field (this line $("#reporter").change( function(e) {):

$(function () {         
         JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, function (e, $context, reason) {
            if (reason == JIRA.CONTENT_ADDED_REASON.dialogReady) {
               $("#reporter").change( function(e) {
                  if ($("optgroup#reporter-group-suggested > option:selected").val() == "admin") {
                    $("#customfield_10301").val("manager1");
                  } else {
                    $("#customfield_10301").val("manager2");
                  } 
               });
              if ($("optgroup#reporter-group-suggested > option:selected").val() == "admin") {
                $("#customfield_10301").val("manager1");
              } else {
                $("#customfield_10301").val("manager2");
              } 
              $("#customfield_10301").focus(function() {
                this.blur();
              }); 
            } 
         });
     });

And it works as expected. If we change the value for the Reporter field, the value for the Approver field changes accordingly.

Well, is it a good solution or bad solution? We do not know. I did not examine the complete code of Atlassian Jira. Maybe we will have an odd behaviour in some place, maybe not.

And you will have this problem with all JavaScript code. You will never know what bug and where you will get later. Moreover this bug will be difficult to solve because your JavaScript code in the banner will be very difficult to debug.

Part 11

[M Amine]

Really interesting. Thank you.