[JIRA] project can use different workflows, and transition ID do not scale

[madchap]

Is your feature request related to a problem? Please describe
Projects can use different workflows, or they can change unexpectedly.

Whenever this happens, you would notice things such as

JiraError HTTP 400 url: https://xxxx.atlassian.net/rest/api/2/issue/xxx-7013/transitions
    text: Transition id '11' is not valid for this issue.
    
    response headers = {'Server': 'AtlassianProxy/1.15.8.1', [blablabla]}
    response text = {"errorMessages":["Transition id '11' is not valid for this issue."],"errors":{}}

In this case, it related to a transition moving to "Open".

Describe the solution you'd like
A way that's not dependent on transition ID, or a more agnostic way. Not sure what.

[valentijnscholten]

This is why I am hesitant of the trying to implement a two-way sync between JIRA and Dojo. Lots of things only work if you have a simple and close to default workflow.

Thoughts:

• You can have multiple jira instances in dojo for the same real life jira instance. You can vary transition ids in this way
• We could try to see what's in the jira meta data we get to see if we can map transition names to ids. i.e. configure the name of the transtion in Dojo. Or even the target state and it tries to transition the issue into that state.

Syncing with JIRA could be a open source project of its own ;-)

[madchap]

Yes - that's what I did, I created a new JIRA instance with different workflow transition IDs.

[madchap]

Syncing with JIRA could be a open source project of its own ;-)

The mother of all time sinks.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[devsecopsale]

this could be solved in a simple way: since transitions IDs could be different and many (transition IDs) could conduct to closed status depending on its source status, using transition name instead of its id will solve the problem. It will even work when using different workflows. Only the transition name has to be consistent in each workflow that is synced with Defectdojo.

example:
we get the transitions fields and search for a name, then get the id. So, transition name can be added to Jira settings and used alternatively between transition id (only one should be chosen). Then on the jira code, a function is called that gets the transition id for every time a ticket has to be updated.
curl https://jira_server/jira/rest/api/latest/issue/TICKET-1234/transitions?expand=transition.fields | jq '.transitions[] | "(.id),(.name)"'

[devsecopsale]

@valentijnscholten , is it possible to re-open this one? I could add the code for this one if it gets approved. Thanks

[valentijnscholten]

We need an admin to reopen @mtesauro

[mtesauro]

@devsecopsale If you want to put in a PR to make the change you are proposing, I don't have issue with that.

[devsecopsale]

Thank you. I'm currently testing it. I'll touch base once I have the PR.

[devsecopsale]

@mtesauro , PR #9543 was submitted. This will fix this issue.

[devsecopsale]

I see 2 fails: 1 (security) I believe is because I'm changing settings.dist.py: I only added an env variable. For the other error (unit test), I can't see what exactly is failing. Couldn't find any error message

[valentijnscholten]

I believe the close transition name should be a property of the jira_instance, not an environment variable. Different instances can have different closing transition names.

[mtesauro]

@devsecopsale

I see 2 fails: 1 (security) I believe is because I'm changing settings.dist.py: I only added an env variable. For the other error (unit test), I can't see what exactly is failing. Couldn't find any error message

We're currently testing out Dryrun Security's tool in a GHA so don't worry about the failure of "Configured Sensitive Files Analyzer" as we're still working with Dryrun Security on those tests

I believe the close transition name should be a property of the jira_instance, not an environment variable. Different instances can have different closing transition names.

I agree with @valentijnscholten here - since DefectDojo supports multiple Jira instances which don't necessarily have to be configured similarly (e.g. company acquires another company and inherits a Jira instance) so configuring that globally is likely to cause issues.

[devsecopsale]

I see your point. It will take me some time to do that. I'll try to have it done during March.