6.1 Dashboard gadget extensions v3.7.0
To explain how to create an extension for dashboard gadgets, we will base this on an example using the Show Saved Filter with Columns for Jira plugin and its Show Saved Filter with Columns gadget.
 Step 1: Create the gadget feature and export it with PCJ
First create an example of a gadget in a dashboard in Jira, configuring it as required. The screenshot below shows an example configuration.
Next, export a configuration with PCJ that includes the dashboard. Bear in mind that Project Configurator does not export dashboards as a default, so you have to select the export option that exports the dashboard you created as a sample. Go to the Dashboards Options drop-down menu on the Export Projects page and select an option that is appropriate for your case. In the example below, we have chosen to export all dashboards, which guarantees all dashboards in this instance will be exported (even private ones):
Once this configuration is exported, open the created XML file with an editor of your preference and locate the gadget description. There is a dashboards element in the file that contains all exported dashboards, that contains several dashboard elements. Each of these will have several gadget items. It is easy to identify a dashboard by its name and owner or as the default dashboard (system dashboard). You will see something similar to the following:
Section of XML file exported by Project Configurator
<dashboards>
<dashboard>
<default>false</default>
<owner>admin</owner>
<name>Test dashboard</name>
<description>Dashboard with samplegadget</description>
<layout>AA</layout>
<gadget>
<type>rest/gadgets/1.0/g/com.ja.jira.plugin.searchrequest:sswc-gadget/gadget_wc.xml</type>
<column>0</column>
<row>0</row>
<color>color1</color>
<parameter>
<key>columnNames</key>
<value>issuetype@@issuekey@@summary@@priority</value>
</parameter>
<parameter>
<key>filterId</key>
<value>10000</value>
</parameter>
<parameter>
<key>isConfigured</key>
<value>true</value>
</parameter>
<parameter>
<key>num</key>
<value>10</value>
</parameter>
<parameter>
<key>refresh</key>
<value>120</value>
</parameter>
<parameter>
<key>showActions</key>
<value>true</value>
</parameter>
<parameter>
<key>sortBy</key>
<value></value>
</parameter>
<parameter>
<key>sortByGlobal</key>
<value>true</value>
</parameter>
<parameter>
<key>title</key>
<value>Project PDLF filter</value>
</parameter>
</gadget>
</dashboard>Notice how each gadget has several parameters that represent how you configured the gadget at the Jira user interface, setting preferences like the filter, the number of results to display, and the refresh period.
Step 2: Implement interface HookPointCollection
This step is the same as the example in Workflow extensions. It is even possible to have workflow and gadget extensions within the same instance of HookPointCollection.
Step 3: Implement the gadget extension
Analyze
First, check which of the parameter elements in your gadget contain references to other entities in Jira. As with workflows, you have to specify how these references can be found in the configuration for dashboards and what their content is. In this example, you can find two references:
A parameter with key "columNames" that is a list of field identifiers
A parameter with key "filterId"
The parameter "columNames" can be ignored. This appears in many gadgets, and it is already handled by Project Configurator as standard.
Focus on the parameter "filterId". If you check the filter setup during dashboard configuration, you will notice this parameter contains a string with the internal Jira ID for the selected filter. This means that this parameter will have to be translated to a different ID for a successful migration. This implies you will implement this extension as a GadgetTranslationPoint. If this parameter contained a reference to another entity that never requires a translation, then you would use a GadgetReferencePoint.
Define location
To identify a gadget extension point, you must specify two things:
The type of gadget and where it appears;
In which of the user preferences/parameters it appears for that gadget type.
If you look at the GadgetHookPoint interface, which is the common ancestor of interfaces GadgetTranslationPoint and GadgetReferencePoint, you will notice it has these methods:
|
|
|
One of the first two methods will be used to identify the gadget type, most often getTypeURIString(). In this example, looking at the XML file with the dashboard description, you can see the gadget element has a child element <type>:
Gadget type
...
<gadget>
<type>rest/gadgets/1.0/g/com.ja.jira.plugin.searchrequest:sswc-gadget/gadget_wc.xml</type>
<column>0</column>
...
This means the gadget type is identified by its URI (otherwise, it would contain a child <completeModuleKey> element). Use the text of the <type> element as a return value for the getTypeURIString() method of the associated GadgetTranslationPoint.
Define the content of the reference
This is described the same way as with workflow extensions. Navigate to the available predefined TranslateOption values that describe built-in translators and identify one that handles a filter ID:
Combining the location and reference content, you define the GadgetTranslationPoint. It could be similar to the following:
Implementation of GadgetTranslationPoint
public GadgetTranslationPoint getSSSCGadgetFilterHookPoint() {
return new GadgetTranslationPointImpl.Builder().
withTranslator(translatorFactory.fromOption(TranslatorFactory.TranslateOption.FILTER_ID)).
withUri("rest/gadgets/1.0/g/com.ja.jira.plugin.searchrequest:sswc-gadget/gadget_wc.xml").
withParamKey("filterId").build();
}Remember to add this as a method of the class you created in step 2, so you will have the following:
Complete implementation HookPointCollection
And that's it!
You have now completed an integration of this gadget type with Project Configurator.