Transition 2

Transition to accepted status
Issue created and transitioned to accepted status

Transition2 is an app built for Jira using Forge

Inspiration

Our daily work is based in Jira. In the workflow of our projects we use Triage and Open statues. When an issue is created, it goes into Triage status, then after accepted by product owner, it is transitioned to Open. Our boards are configured in a way that Triage is not visible in columns, so developers are not overwhelmed with the number of tasks laying in the backlog.

But there is one problem. When a new issue needs to go to the Kanban board right away (e.g. a major bug), you need to follow the frustrating ceremony: 1. Create an issue, 2. Open the issue, 3. Transition to Open. It takes a lot of time if you have to create several issues in a row. In order to address this issue and increase productivity, Transition2 app has been created!

What it does

Transition2 app lets you set the target status of an issue right after it’s created. All you need to do is to add “Transition to“ custom field provided by the app to Create Screen and type in the name of the target status directly into the field.

How we built it

Transition2 is built with Forge . It uses customField and trigger module (avi:activity:created:issue) event.

Challenges we ran into

It turned out that Select component can’t be a child of CustomFieldView. Therefore we decided to use simple StatusLozenge to represent status in Issue View. StatusLozenge was hard to find at first, because it was renamed lately from Lozenge component.

CustomField component is not rendered on Issue Create, however the custom field is displayed based on its type. It allowed us to use the custom field module, however, the UI experience wasn’t the best. Nevertheless, instead of matching statuses by id or exact name, we decided to match them smartly, therefore there’s no need to worry about cases or spaces. In the near future we will try to match them also by status shortcuts.

During the implementation it turned out that you can’t set a default value on Forge custom fields. It is a pity as it would be great to be able to configure different issue types contexts and have various default values. We also run into a problem with renaming the app or its custom field description. It turned out that once the app is installed or a custom field is created, you can change its name in manifest but the old values stays forever in some places, i.e. for custom field description - old description on Create Screen, or a name of the app when prompted to grant access. We decided to create a new app, this time with the updated name, and then swapped app.id in manifest to overcome such problems.

At the moment it is possible to transition issues only to the nearest status in the workflow. The reason is/issue/$issueKeyOrId/transitions endpoint which works like that. We haven't found an easy way to get all possible transitions for an issue type. Lately, new workflow endpoints have been added and we’re hoping to find a solution in the future.

Accomplishments that we are proud of

The app works well despite many framework limitations, the goal was achieved and we will for sure use it in our daily work in Jira projects.

What we learned

We have learned a lot even though it was our second app built in Forge. It won’t make sense to list all new modules and components we learnt, although a single noteworthy thing is that you can’t use impersonalisation in triggers. On one hand it surprised us, because the same is possible in connect. On the other hand, we can easily see the problem with showing the consent prompt to the user while a trigger is being executed. This makes writing automation much more harder if you don’t want your app to bypass user permissions.

What's next for Transition2

First of all we want to enable transitions to any status in the workflow if possible. Sometimes there is no straight transition between statuses and you are forced to change them one by one. Transition2 app will for sure help you with that. The next step would be handling the change of the status directly on the issue view (on edit). We also want to have a glance module, where all transition are logged, similar to the history tab but with additional messages from our app.

We’re sure that with time, Transition2 app will evolve parallelly with the constant growth of possibilities in Forge.