tickets are getting off stricked when force to set resolution

[Suma Pralhad Kustagi]

Hi All,

     Even when the tickets are not resolved completely ,they are forcing to set resolution field and getting strike off in the boards. How to resolve this issue. For issue type story and change request.

Regards,

Suma 

[Nic Brough -Adaptavist-]

You need to change your workflow so that it does not set the resolution.

You might have a post-function or automation that is setting the resolution on the wrong transition, but I suspect the usual culprit - you have put the resolution field on the create or edit screen. 

If you remove it from those screens, that will stop the problem happening in the future. 

Resolution should only be put on transition screens, the ones that "close" the issue, putting it into a status you consider to be the end of the process.

[Suma Pralhad Kustagi]

Hi All,

    These are the only thing i see in post function and there are no validators set

1. Set issue status to the linked status of the destination workflow step.
2. Move up Move down Edit DeleteAdd a comment to an issue if one is entered during a transition.
3. Move up Move down Edit DeleteUpdate change history for an issue and store the issue in the database.
4. Move up Move down Edit DeleteRe-index an issue to keep indexes in sync with the database.
5. Move up Move down Edit DeleteFire a Generic Event event that can be processed by the listeners.

Regards,
Suma

[Walter Buggenhout]

Hi @Suma Pralhad Kustagi,

As you can see you got 3 completely different answers to your question, I think its fair to see your question leaves room for interpretation ;-)

Could you be more specific about what is going on exactly: is a resolution being set automatically or do you see a screen appear? And at what exact moment in your workflow does this happen?

Also: to what transition are the post functions you share here linked? 

[Nic Brough -Adaptavist-]

Validators don't matter here.

I think we need to focus on exactly how the resolutionis being set in this case, as there's lots of different ways to do it, and we could spend ages talking about the wrong one.

Please follow @Liam Green 's suggestion:

• Find an issue that has been resolved when it should not have been
• Open the issue in one of the larger issue views, one that gives you the history tab
• Read the history, looking for any change of resolution
• If (not when) you find one, look at what did it - which transition or edit was it?
• If you do not find one, then we know we need to look at
  • The create issue screen
  • The post-functions on the create transition
  • Possibly column settings on a board

[Suma Pralhad Kustagi]

This is the snippet of the workflow.

I do not see any thing in History of tickets regarding the Resolution.

[Liam Green]

Can you give us a snippet of the history too please?  It will have to be one that resolved when you thought it shouldn't.

[Liam Green]

Hi @Suma Pralhad Kustagi 

If you look at the history of one of the tickets that has been 'force resolved' what does it tell you?

[Walter Buggenhout]

Hi @Suma Pralhad Kustagi,

This is related to the design of the workflow being used for story and change request in your instance.

Through project settings > workflows see what workflow is being used for those issue types.

When you edit the workflow and select the transition that currently prompts you to set the resolution, you will see 2 things:

• there will be a screen that is used during the transition (probably something like resolve issue screen).
• under validators you should see a specific validator that makes Resolution a required field on the transition.

As it seems you want this to happen on another transition in your workflow, remove both the validator and the transition screen. But definitely add them again in the exact same way on the transition that you think should be the closing transition in the workflow.

After making the changes, publish your workflow and you should be good to go.

But make sure to do both. Setting the resolution in Jira is the key concept in making the difference between open and closed issues.