The fields "Resolution" for almost issues except in Defect type is totally a nonsense

[Lamine MESSAOUDEN]

We are migrating to Jira/Confluence. For unknown reason the customed issues  (by one external consultant who left now)  based on tasks, Stories, Epics have a state RESOLVED and contain also a field RESOLUTION, which does not make sense for me execpt in DEFECT issue type. I am asking our central and corporate Jira support, to change the name of the state RESOLVED to for exmple ACCEPTED, and remove the field RESOLUTION or rename it accordingly with the right state.

For DEFECT type issue the same field RESOLUTION have been set also in CLOSE state, it should be named REASON OF CLOSURE instead.

The answer of our support is :

Currently , there is no way to remove Resolution from the view screen since it belongs to system default configuration, we only can remove it on Edit/Create Screen .
For Defect issue type , i have modified the values and i couldn't rename it due to it also configured by system . If you want a field named REASON FOR CLOSURE when close , i believe i could make it ."

I want to remove the field RESOLUTION when it does not make sense.

Can someone help me please, explain to me if it is possible ?

Thanks in advance for the help.

Regards

Lamine

[Alex Christensen]

Firstly, it's not possible to change the "Resolution" field to any other name or to remove it from a View screen. Your corporate JIRA Support is correct in that the field is a system default field that cannot be changed.

Secondly, I'm not really understanding the difference between using the "Resolution" field and a new field called "Reason of Closure." In JIRA, the Resolution field should contain the reason for the closure with a value like "Fixed," "Won't Fixed," etc. Then, the Status of the issue should indicate whether or not the issue (regardless of type) is closed or resolved, and the Resolution field explains what the resolution was.

Really, the Resolution field should make sense for any issue type since you are closing the issue and you would need to record the end result. You can add new values to the Resolution field, so maybe that's what you really need to do in this case, instead. I think it would be redundant to create another field called "Reason for Closure," because that's basically what the Resolution field is used for, in my opinion.

[Lamine MESSAOUDEN]

Thanks Alex for your prompt answer.

Sorry, I do not agree , because I do not  understand the meaining of resolution field in a task for example, or for a story? The task could not be resolved, it could done, cancelled, postponed...etc.. The same for a story, accepted, assessed, ready, implemented...

The real reason perhaps in Jira all the issue types are in fact based  the same built-in issue "prewired" type.

[Alex Christensen]

I guess it also depends on how you have set up the workflows for each issue type.

Let's take a Task as an example. We'll say that the workflow has these statuses:

• To Do
• In Progress
• Closed
• Postponed

When going to a Closed status, you would set the Resolution to one of these values based on how the Task was addressed:

• Completed
• Cancelled

You would go into the Postponed status if the Task needs to be put on hold - a Resolution wouldn't be assigned to a Postponed Task because you're going to come back to it at some point, so there's been no resolution to the Task yet.

It is true that there are probably cases in which Resolution can only be one value - you might have an issue type to track small Action Items and the resolution is either "Unresolved" while the Action Item is open and then it is "Completed" once the Action Item is closed. Regardless, Resolution should apply to every issue type in some way.

Basically, Status is used to indicate where the issue is in its lifecycle. Once the issue is closed, the Resolution is used to indicate why it was closed.

[Lamine MESSAOUDEN]

Thanks Alex for your clear and prompt explanation, the Resolution  play here the role of Reason of Closure, it could be acceptable if we explain it to the users. (Resolution  and Reason of Closure are synonyms)

But what I need also to understand, is if this Resolution  field appears automatically in some prefined statuses?

In the implementation, I have this field appears for some issues in RESOLVED and CLOSED statuses.

Could we rename RESOLVED  status for some  types of issues by more relevant names?

Thanks again for the patience and help.

[Alex Christensen]

Just to clarify, you have two statuses in a workflow, one called Resolved and the other called Closed. Is my understanding correct?

If these two statuses are in the same workflow, then I would get rid of one of them all together. They seem like synonyms, in my opinion. Personally, I'd get rid of "Resolved," then use the Resolution field to explain why an issue is in the "Closed" status.

Re: where the Resolution field appears - do you mean during a transition to another status? This is configurable in the admin settings, so the field can appear anywhere you want it to. You can also set post-functions during status transitions - for example, if you go from "In Progress" to "Closed," you can have your system set a Resolution automatically, which is helpful when you're never going to have more than one value in the Resolution field.

As for renaming or changing statuses and workflows - technically, it's entirely possible to do that. However, it's really up to your corporate JIRA Support if they want to change things or not. They may have their reasons for naming things the way they do or their own opinions on workflows - you should probably check with them on that.

[Lamine MESSAOUDEN]

Thanks!