We are using the rapid board in Greenhopper. I added a new workflow to support the new 'statuses' - however, even though I have updated the task board mapping to include the new statuses as 'done' when they are transitioned to the custom column in the rapid board view (they show as done on the board, i.e. strikethrough) BUT on the planning board, they show as in progress (update the progress bar) but if you look at resolution status (its marked as done - in JIRA view).
I have added a post function to update to resolution fixed but it seems to ignore it, and only marks an issue as 'DONE' when it's in the JIRA standard 'Resolved' or 'Closed' state irrespective of resolution status (i.e. fixed, done, etc)
It seems as though the greenhopper rules dont apply to the kanban rapid view board. Please help!!!
I couldn't completely understand the situation, I am assuming that you added new statuses for Done and mapped them to Rapid Board columns. And in the transistions that leads to this status, you have added post conditions to set the resolved state.
Actually the resolutions and statues are of course respected by Rapid Board. Could you please paste a screenshot?
I can't upload any screenshots. I added a few extra statuses with transitions (Tested in UAT, Deployed to INT, Deployed to Prod.)
None of my statuses which I added which should be showing as 'resolved' don't show as resolved. Only the status which JIRA gives us (Resolved and closed) are closed and resolved, any other status that you add it ignores.
Jira determines whether and issues is Resolved purely based on whether the 'Resolution' field has some value or not. If it is empty it considers it as Unresolved. So in your workflow post conditions you should set the Resolution to the appropriate value (or during the transistion show a screen containing the Resolution field for the user to select) so that the issue is marked as Resolved.
I have added a post function to set a resolution status to done. It does not resolve the problem. Using a bulk change option to 'close' these may be suitable as a once off, but the workflow should essentially work the way it was intended, because otherwise, its not transitioning as a rapid board is designed nor is it adhering to the rules of the resolution state as per the task mapping board. Thank you for trying though. Anyone else have any other suggestions or ideas when Atlassian is going to fix this.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot