Making Jira Transition IDs easier to configure
Problem to solve
Configuring the Jira project integration with GitLab requires the user to go to their Jira instance, grab those transition IDs by Viewing Source on a configuration page in that UI, and then copy/paste those IDs (which are raw integers) in to a list inside of GitLab's UI. This is, needless to say, not a great experience.
Every conversation I've had with customers and even GitLab internal users have noted that this configuration process is esoteric and easy to get wrong. The right solution should be to configure this setting through a fully-fledged UI that doesn't require them to visit their Jira instance at all.
Intended users
Anyone currently having to configure the Jira project integration or Jira service template. (And in the near future, anyone configuring Jira group-level integrations).
This could be:
- A GitLab project, group, or instance owner
- A Jira administrator
Further details
Making this configuration simpler will...
- Make the configuration simpler, less painful, and faster to get running
- Reduce the likelihood of errors in configuration, introduced by the complexity of it's use
- Lay the groundwork for increasing the complexity with Transition IDs, such as these issues:
Proposal
-
Determine the relevant transition automatically (by default)
- This would be done every time we're actually closing an issue, so no configuration would be required, and we'd automatically support workflows across different projects / issue types.
- We could use the Issue Transitions API to get the available transitions, and e.g. look for a transition where
to.statusCategory.keyhas a value ofdone. - This update will make this part of the integration on by default
-
Allow users to specify status names and or transition IDs
- This would just be a text field that supports custom status names e.g.,
Ready for QAand will continue to support transition IDs - It's much easier for users to get the correct status names from the Jira UI, and more likely for the names to match across different projects / issue types.
- This will also make this update backwards compatible for users that have already setup this feature using IDs
- This would just be a text field that supports custom status names e.g.,
| Proposed UI update |
|---|
 |
See for #16119 (comment 495417507) for more context.
Permissions and Security
This concept should be reviewed by the Application Security team before work begins to ensure this does not open up any new attack surfaces.
Documentation
- Will require updates to our current Jira integration documentation
Testing
- Ensure that all transitions are being successfully pulled from target Jira instance
What does success look like, and how can we measure that?
- User interaction metrics should show a lower time on the Jira configuration page after this is implemented
Links / references
Original Submission
To configure Jira we have to set a transition id which is a state that Jira referenced issue will belong after a merge request gets merged.
Transition id is not self explanatory and it is hard to find that number in Jira. I propose we show a select box with Jira available transitions on that project after the user gives url, username and password.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.