Skip to content

JIRA integration - allow to configure Transition IDs per project

Description:

Problem to solve

Sometimes there are several JIRA projects used to work issues for one GitLab project. Each of those JIRA projects may have its own issue workflow (various number of issue states and transitions, of course they have different IDs). We need to allow more flexible configuration of Transition IDs in GitLab JIRA Integration, to be able specify Transition IDs for specific projects.

Intended users

Developer

Further details

Currently we have just single field for Transition IDs. JIRA_Integration_form

Proposal

Maybe implement "+" button under the form which adds one row with two fields: Project ID, Transition IDs. Like this: JIRA_Integration_form_PROPOSAL

or (less user-friendly, more geek-friendly 👓 interface):

Implement parsing of Project IDs in the same Transition IDs field, e.g. separating Proj ID from Transaction IDs with ":" and one proj from another with ";". Like this: JIRA_Integration_form_PROPOSAL4GEEKS

With this, when logic for "magic words" (Resolves, Fixes, Closes) is applied, it first checks the specific project settings (if any), otherwise works as usual.

Permissions and Security

No change.

Documentation

The documentation for JIRA integration is quite unclear at the moment, so it requires some clarifications first. For example, it is not even clear what happens when there are several IDs provided, e.g. "11,21" - there is no explanation in which cases "11" is used and in which "21" (the phrase "...the issue will be moved to each state after another using the given order" is not enough descriptive). In addition, it is not clear what will happen when the Jira issue is in the state that cannot be moved into any of the desired states. Also, there is an explicit statement here "Note that the transition ID may vary between workflows (e.g., bug vs. story)", but not a single word about what to do if this is indeed your case. What if I need different workflows for them? Finally, some Jira projects may have Required Fields when closing the issue. What happens if GitLab tries to close such issue? I suppose some of the questions above have the answer "this is not supported", so, probably, the page needs the section of what is not supported :)

Well, what will be required for describing the proposal: Update Transition IDs field description in the table here adding notes about ability to configure separate IDs for specific Jira projects. And update the config form screenshot here.

Testing

All TCs require JIRA instance running with some projects configured. Two of the projects (PROJ1 and PROJ2) must have their own workflow (transition IDs different from general workflow (other projects) and different from each other).

Test Case 1

Verify that JIRA integration works as before with one ID.

Setup:

  • Only one Transition ID is specified in JIRA Integration configuration.
  • The target Jira issue is in the state supporting the desired transition.

Actions: Run the scenario for Jira issue closing

Expected: Jira issue state is changed as desired, all the links and comments appeared as usual.

Test Case 2

Verify that JIRA integration works as before with several IDs (and picks up the very first when it is applicable).

Setup:

  • Several Transition IDs are specified in JIRA Integration configuration (separated by comma).
  • The target Jira issue is in the state supporting the desired transition.

Actions: Run the scenario for Jira issue closing

Expected: Jira issue state is changed as desired, all the links and comments appeared as usual.

Test Case 3

Verify that JIRA integration works as before with several IDs (and picks up the applicable ID which is not first).

Setup:

  • Several Transition IDs are specified in JIRA Integration configuration (separated by comma).
  • The target Jira issue is in the state supporting the desired transition, but not the first one in the list.

Actions: Run the scenario for Jira issue closing

Expected: Jira issue state is changed as desired, all the links and comments appeared as usual.

Test Case 4

Verify that new JIRA integration functionality works with one ID.

Setup:

  • No general Transition IDs are specified in JIRA Integration configuration.
  • Only one Transition ID is specified for one specific project (PROJ1).
  • The target Jira PROJ1 issue is in the state supporting the desired transition.

Actions: Run the scenario for Jira issue closing

Expected: Jira issue state is changed as desired, all the links and comments appeared as usual.

Test Case 5

Verify that new JIRA integration functionality works with several IDs.

Setup:

  • No general Transition IDs are specified in JIRA Integration configuration.
  • Several Transition IDs are specified for one specific project (PROJ1).
  • The target Jira PROJ1 issue is in the state supporting the desired transition.

Actions: Run the scenario for Jira issue closing

Expected: Jira issue state is changed as desired, all the links and comments appeared as usual.

Test Case 6

Verify that new JIRA integration functionality works with several IDs and several projects.

Setup:

  • No general Transition IDs are specified in JIRA Integration configuration.
  • Several Transition IDs are specified for two specific projects (PROJ1, PROJ2).
  • The target Jira PROJ1 and PROJ2 issues are in the states supporting the desired transitions.

Actions:

  1. Run the scenario for Jira issue closing for PROJ2
  2. Run the scenario for Jira issue closing for PROJ1

Expected:

  1. Jira PROJ2 issue state is changed as desired, all the links and comments appeared as usual.
  2. Jira PROJ1 issue state is changed as desired, all the links and comments appeared as usual.

Test Case 7

Verify previous JIRA integration functionality combined with new functionality.

Setup:

  • One or more Transition IDs are specified in JIRA Integration configuration.
  • Several Transition IDs are specified for two specific projects (PROJ1, PROJ2).
  • The target Jira PROJ1 and PROJ2 issues are in the states supporting the desired transitions.

Actions:

  1. Run the scenario for Jira issue closing for issue not in PROJ1 or PROJ2.
  2. Run the scenario for Jira issue closing for PROJ2
  3. Run the scenario for Jira issue closing for PROJ1

Expected:

  1. Jira issue state is changed as desired, all the links and comments appeared as usual.
  2. Jira PROJ2 issue state is changed as desired, all the links and comments appeared as usual.
  3. Jira PROJ1 issue state is changed as desired, all the links and comments appeared as usual.

More..?

Probably, also need to verify the scenarios when nothing must happen.

What does success look like, and how can we measure that?

All Test Cases are passing from the section above, and customers are able to use Jira issue closing for multiple Jira projects when working with their project on GitLab.com.

What is the type of buyer?

Core tier

Links / references

N/a

Edited by Pavel Pigalov