Hello, the Advanced workflow configuration documentation page states
If you need to set the 'Resolution' field when creating an issue, add the 'Update Issue Field' post function after the 'Create the issue' post function and after that, use the 'Store Issue' post function.
And now I'm wondering what's the use case of setting the resolution field even before transitioning an issue through a workflow 🤔
The only case I can think of for setting a resolution on creating the issue is for retrospective reporting (this thing happened, we fixed it before raising an issue, but we should raise one to report on it/log time against/etc)
And for the sake of simplicity, most of us never do that - we create the story and then just take one extra click to resolve it straight away!
Let's take your hypothetical case of retrospective reporting.
It still doesn't make sense as there's a single "Create Issue" initial transition. From there, you would need to duplicate your issue types to differentiate the retrospective situation from the non retrospective situation.
So yeah I'm still much intrigued by why there's a special note in the documentation. Must have appeared after a support ticket 🤷♂️
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Exactly, that's why I would never bother putting resolution on the create screen, it's a tiny edge case and can be dealt with by "click on resolve immediately after creating it", rather than having to set up a whole new issue type and matching workflow.
I too am intrigued as to why there is a special note in the documentation!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Gregory Pakosz ,
You are correct. Resolutions are the ways in which an issue can be closed. It makes no sense to add a post-function to create issue transition and populate a value for resolution field. A lot of functionalities depends on resolution field.
But if they are using resolution field in board's JQL or filter to differentiate issues, then they can be populated (even in that case, I do not find it as a good usage).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.