Creating a queryable radio button custom field

Porting an internal Plugin to JIRA Cloud instance

We are currently in the process of transitioning from a self hosted JIRA Server instance to a JIRA Cloud Premium instance. In our current self-hosted instance we developed a plugin that needs to be ported to the Cloud instance. This plug-in creates a custom field with radio button functionality in a matrix.

However, due to restructuring of the plugin-development interface it seems that the plugin will need to be rewritten from the ground up. This would be done using one of the 2 currently supported Frameworks to interface with the Cloud suite:

Atlassian Connect (Express)- which lacks some functionality required to interface with the backend, namely, the lack of APIcalls for Custom Field values (see ‘Complications using Atlassian Connect’ section to see why this is important)

Forge - Some functionality - including the Custom Fields and Custom Field Types- are in beta (see ‘Complications using Forge’ section to see why this is important).

About the Original Plugin:
The original plugin was developed by us for our self-hosted server, which added a field that allowed us to declare whether an issue is either ‘Seen’, ‘Not Seen’ or ‘Untested’ for a particular Platform/SKU/Hardware setup. This UI behaves in the same way radio-buttons function in that each row can only have one selection with a default selection on creation (being ‘Untested’). See example below, depicting the choices available for ‘Platform’:


This, in essence, is a cosmetic layer atop the Multiselect Custom Field (see MultiSelectCFType) which comes as standard in JIRA Server. All data for this field stored in the database is identical to that of a Multiselect Custom Field (see Documentation). Each option in the Custom Field itself includes 3 options, for ‘Seen’, ‘Not Seen’ and ‘Untested’ (hence the name ‘Matrix’). This is implemented using the Atlassian SDK, with Velocity (.vm) files. Listening for the button onclick JavaScript event, all buttons except the selected one will be unchecked. This allows the multiselect list to act as a series of single select lists. This type of field is stored under the Custom Field Type ‘Internal Matrix Field’ in the backend, which is possible making use of the customfield-type and customfield-searcher plugin modules, which allow the custom field type to be created, and searched (in JQL) respectively. We are hoping to create a feature-complete Cloud version of this plugin in a similar manner to described.

Difficulties Porting the Plugin to JIRA Cloud:
As mentioned in ‘The Problem’, we have a choice between 2 officially supported Frameworks to build our app, being Atlassian Connect and Forge. The former has lacks some core features we require for our app, and whilst the latter may include these, it is still very new, with some of the required features still in beta, and thus subject to change (as of 02/11/21).

About the REST API:
Both Connect and Forge apps interface with the Atlassian backend using REST API calls, and this is how we intend to pass the data (options chosen) from our app and to the backend where it will be stored, and allows for crucial features such as JQL querying (allowing us to filter by platform/hardware type/SKU). Though the form of REST calls are identical in their implementation for both Connect and Forge, there are some discrepancies in which API calls are supported between frameworks. Forge lacks some features which are already available in Connect. This is also true vice versa.

Complications using Atlassian Connect:
As mentioned above, there are some REST API calls which are exclusive to Forge, notably including the calls for Issue Custom Field Values, which allow for updating Custom Fields, as well as their values, which would allow us to connect our buttons within the Module iframe to the JIRA backend (See below on our proposed Web Panel solution). Custom Field Types are also unable to be created using Connect (being an Forge exclusive feature), being instead limited to the standard custom fields provided, which prevents us from implementing the app in a similar fashion to how it was originally done for JIRA Server (See ‘About the Original Plugin’).

Using Connect App Modules is unfeasible to ‘theme’ the JIRA UI elements like was done with the MultiSelectCFType in the server implementation, as customisation of the JIRA page is limited to these modules with fixed locations.
The closest suitable solution for implementing the Internal Matrix with Connect is using a Web Panel module in the location: atl.jira.view.issue.right.context. The UI for this was mocked-up and installed onto a development JIRA Cloud instance, where it appears similar to the original plugin. However, due to the aforementioned lack of the Issue Custom Field Values API call to alter Custom Field values using Connect, there is no way for the choices selected to be passed into the backend to overwrite previous data.

Complications using Forge:
Unlike Connect, Forge does include the necessary REST API calls for altering Custom Field values (see Issue Custom Field Values), which allow us to pass data into the backend. It also has modules for creating new Custom Fields and Custom Field Types, though these features are (as of 02/11/21) still in beta. This unfortunately means that these features are not subject to the 6 month Deprecation Policy provided by Atlassian for stable features, meaning in using them, we are at risk of changes to the features breaking our code, or the deprecation of the features entirely before deployment. As stated in ‘Complications using Atlassian Connect’, both of these features are required to implement the Internal Matrix feature-complete to match the original. Though Forge lacks the Web Panels module from Connect (which we used for the prototype), it (along with the other UI related Connect modules) has been replaced by the Custom UI, and UI kit (beta), meaning the majority of the work done should be easily portable to this new format.

Given the complications of using Connect vs Forge, what would you recommend as the approach? Are there alternate solutions that haven’t been outlined above?

With the Forge functionalities outlined above (Custom Fields + Custom Field Types) are these features close to finalisation? Can we use these with some confidence that they won’t change significantly?