|
Thomas,
In this case you should "Re-open" an issue or have a similiar transition. Then on this transition have the resolution cleared using a post function. Please refer to the Re-open transition in the Default Jira workflow and look at its post functions. Cheers, This does not solve the issue, as the Resolution field is still
automatically considered required despite your Field Configuration Scheme. Yes, I suppose its possible to do the post action, but then you are immediately altering a value that the user was FORCED to enter (since they can't clear the field via the interface they are shown on the Re-Open). The only way I see that this suggestion would work and not horribly contradict good gui and system design would be if the Re-Open transition did not display any screen at all...but I don't think you can guarantee that that will be possible in all cases. The ideal solution here, IMHO, is to allow the user to clear the In Jira's default workflow, there is no Resolution Field on the screen for Re-Opening an issue.
It has a post-function the clears the Resolution. Isn't this what you are trying to acheive? Nick Yes, that is what I'm trying to achieve, but in my experience the
Resolution field shows up even though I have it set to Optional for that issue type. Joel,
It sounds as though you have the "Resolve Issue" screen set to your transition. Select the "Steps" link of the workflow you wish to edit. Let us know how you go. Cheers, I understand you can reopen issues, but since this is a fully customizalbe system, shouldn't there be an option to unset Resolution anyway? Especially if it isn't necessarily closed when it gets set?
Jeremy - see a similar discussion at
The main problem is that Jira is doubling up on the Resolution field to determine if an issue is actually closed or opened. This is really dependent upon the "Step" that the issue is in, and not whether or not the Resolution field actually has a value.
Each step (status or state) should have a open/close flag associated with it. If an issue is closed, it will be in a step where the open/closed flag is pointing to closed. In most cases, only one or two states will be associated with closed issues ("rejected", "closed", and maybe "deferred"). This would allow the "Resolution" to be treated just like any other field. I agree with Thomas Fenske.
for me it would best to have a BUILT-IN "unsolved" Resolution, to change a call back to unsolved without an extra workflow! (My fault this week was: give the resolution-field to the edit-screen - to be able to have a look on the resolution – within one day about 120 calls have disapeard from the "open call list" , because they have been edited (estimation or description) and automticaly be set to default-resolution "fixed"!!) It would be most beneficial if the Resolution field could be optional. We are tyring to limit the number of screens necessary for viewing/editing and cannot include the resolution field on these screens because it is required. we are having to duplicate a screen and add this field just to get around this.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Make Resolution field optional
IMO this is a common use case. How does Jira support workflows like this?