[Pre-Approval Request] Migrate Jira issue state detection from resolution to statusCategory

[derda17]

Is your feature request related to a problem? Please describe
We noticed that defectdojo is not able to re-open Jira issues in our setup, which led to some findings being noticed very late. This is caused by our Jira not returning a resolution field when the state of the issue is requested by defectdojo. Defectdojo only re-opens an issue if the issue is currently closed and it derives this information from the existence of a resolution field.

Describe the solution you'd like
While a proper maintenance of the resolution field is a good practice, it is not guaranteed and might be difficult to achieve, depending on the design of the Jira workflow. Even if this is implemented, it is possible to configure Jira in a way that the resolution field is maintained nicely in the UI but won't show up in API responses requested by defectdojo.

There is actually a better indicator: the statusCategory is a fixed set that indicates if a status is an end state (COMPLETE) or something else (TO_DO, IN_PROGRESS, UNDEFINED). This set is not extensible, every status, also custom ones, must map to one of these categories and it is returned in the API per default.

I'd like to contribute a change to issue_from_jira_is_active in helper.py, that relies on the statusCategory instead of the existence of a resolution field. I'm asking for a pre-approval according to the contribution guidelines.

Describe alternatives you've considered
We changed our jira workflow, the jira config and adapted our processes to get the jira integration working, but I still think checking the category is the cleaner approach for the active check.

[valentijnscholten]

Not sure how you can ever use JIRA in a helpful way if you are not using the resolution field. That's also what the "good practice" article states. Can you elaborate how this works for you?

[derda17]

We are actually using resolutions. Our original problem was that the issues closed by defectdojo did not receive a resolution. Hence when trying to reactivate them later, defectdojo assumed they are still active.
The good practice offer two possibilities (post function and screen), but they cannot be combined, the post function will override the screen choice. Due to the setup of our workflow, we could not add a transition and a post function specific for defectdojo otherwise our screens would be pointless.
We probably found a workaround that we are currently testing and observing by using a dedicated issue type and workflow for defectdojo.

Despite our workaround, I still think it is a worthwhile improvement. The function checks if an issue is active. The statusCategory answers exactly that. Unless the status is explicitly filtered out in the API call, the statusCategory is always returned (since Jira 6.1, released in 2013) and is more robust against project setup, workflow setup, field configurations etc.