Jonas Möhringer, co-founder
My name is Jonas. I'm a co-founder of Easy Apps. I don’t consider myself a developer, but rather an experienced Jira and Confluence administrator. I know administration, configuration and customization of Atlassian tools in on-premise and Cloud environments quite well. Also, I am familiar with scripting and implementation of various automations in Jira server.
This is Part 2 of 3. Part 1. Part 3.
We developed our first Jira cloud app using Forge UI Kit and published it on the Atlassian Marketplace. Even if some features were missing compared to the server version, we received positive feedback and several of our customers who migrated from server to cloud continued to use Epic Clone. A cloud version build with Forge.
From UI Kit to Custom UI
Although the app migration to cloud went well and the customers were happy, there were still limitations with UI kit and not all features from server could be migrated to cloud with UI Kit to build a Jira cloud app. The obvious solution seemed to be to change the app to use Custom UI instead as it promised to be more flexible and to provide various additional possibilities while building the Jira cloud app.
Everything new with Custom UI to build Jira cloud app
In 2022 I started to learn Custom UI. I went through the one Atlassian Custom UI tutorial that exists. The goal was to migrate the existing cloud version of Epic Clone to Custom UI in order to be able to add missing features and improve the user experience.
The tutorial app only displays “Hello World” in an issue, which isn’t that helpful when you want to build something more complex. Luckily, at least one sample app exists that uses Custom UI, and I used it as starting point to learn about Custom UI, how things can be implemented in a more complex app and how front-end code and back-end functions are related.
I didn’t start from scratch to build the jira cloud app, this made a big difference. I knew that I would need an issue action module, a modal dialog to display and I knew about the fields that should be placed on the cloning form. Also, the concept with an initial screen for project selection and parent issue information, and that a second screen with child issues should remain.
Forge Custom UI Bridge and tunneling
In Custom UI apps static resources need to be defined where the fronend code is located. This front-end code communicates with the back-end functions via the Forge bridge, it is calling back-end functions and receives information to display. The first challenge was the tunneling which works differently than for UI Kit apps. It is required for development to see changes immediately on the screen after saving a file. It is necessary to run a react app with your front-end code before starting the Forge tunnel to also see front-end changes in your browser.
Logging with Custom UI
After I got that to work, it was sometimes confusing as I expected the logging in the terminal window where the tunnel was running. However, for the front-end part, logs are displayed in the browsers developer console. That was something I needed to get familiar with especially as I only developed with UI Kit so far.
New file type
A new type of file, type script, came into play during development of Jira cloud apps. As I took files from the example app as a starting point and those were written in type script, I kept especially the forms and form fields in type script files. Again it was something I had to learn and get familiar with, e.g. that each variable has to be declared with a type and functions need types and explicitly defined variables as input. However, in the end I enjoyed writing code in type script and it was something new I learned.
UI implementation: Jira cloud app
The development approach was similar to when I did the initial development with UI Kit, I did it step-by-step and field-by-field to populate the modal with all necessary information. The styling of the fields was more difficult though as it wasn’t enough to just add them like with UI Kit. Styling like margins, padding or overflow had to be applied to make the entire form look good. But on the other hand, Custom UI provided opportunities for a better user experience.
Examples:
Component and fix version fields could be added which change their selection values immediately after new target project has been selected
Component and fix version fields are hidden instantly when a team-managed project is selected as target project, as those fields are not available in team-managed projects
When a new target project is selected, it is validated if the issue type of the source issue is available in that project and an error is displayed if not
Issue checkboxes show the icon of the issue type instead of issue type name as text (not possible in UI Kit, see above)
Issue checkboxes are automatically disabled if the issue type is not available in the target project
Child issue checkboxes are automatically disabled if their parent issue is deselected for cloning
This list is far from being complete, but it shows how much is possible when using Custom UI.
First cloning screen with Custom UI
Second cloning screen with child issues to be cloned
Switching of screens was again achieved by using a useState hook with a form state variable.
Back-end implementation
When it came to implementation of the actual cloning functions, it started to pay off again to decide to switch to Custom UI. In the previous version, the user hit the run button once and started the cloning function, which ran in the background with no feedback on the progress. With Custom UI it became possible to display cloning progress information live on the screen.
What issues have already been cloned? Which ones are still to do? Which issue is currently cloned? All that can now be displayed on the screen when the function is running. We implemented that by sending the cloning requests sequentially from the front-end to the back-end functions, starting with the parent issue, followed by child issues, sub-tasks and optionally linked issues. Whenever one issue is cloned successfully, the front-end variables are updated and the user sees this updated information immediately.
For the user, it is displayed on the result screen which issues are in progress, which issues are done, and which issues are pending. This is an improvement compared to the situation before where there was only something displayed when cloning was completed.
By changing the app to Custom UI, several features could be implemented that weren’t possible before which was a huge step forward for the cloud version. The feature gap compared to the server version became smaller. We expect to decrease this even more as Forge improves. For example, cloning of attachments is not yet possible in a Forge app.