Changing Closed resolution scheme and life-cycle flow without breaking Jira standard behvior

[Yoram Shahak]

Hi,

I would like to differentiate between closed issues which are actually solved inside my product, and such that are done without any solution for the issue instance (Won't Do, Incomplete, Cannot Reproduce, Duplicate etc.).

I would like the diffrence to be the life-cycle state itself, trather than having to rely on Resolution field values within the RESOLVED/CLOSED life cycle state.

I have defined a REJECTED life-cycle state with reject transitions. I have edited the Resolution value list to only contain Fixed/Done/Rejected. I have set post functions on resolve/reject/reopen  transitions to implicitly set Fixed/Rejected/empty values respectively.

I have also noted the warning about resolution values published here: https://confluence.atlassian.com/display/JIRA/Defining+Resolution+Field+Values, and took it that this is a special field and just another data column.

My questions are:

1) Will my design leave standard JIRA behavior intact, with regards to resoltion semantics, including resolution displays, reports etc.?

2) Do I need the "Done" value for using JIRA Agile module?

[Penny Wyatt (On Leave to July 2021) · Accepted solution]

Yep, that should be fine. 

I have a workflow that I use for recruitment with 5 different closed states (Hired, Rejected, Withdrawn, Timed Out, Talent Pool). As long as the resolution is set when going into a closed state, and cleared when a ticket is reopened, the reports will show it correctly. There's nothing in JIRA's code that assumes that there's only one Closed state, that there's a state named "Done", or that any particular resolution names exist.