|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Joanna Thurmann - 20/Oct/06 02:14 PM
Seeing as it's been 2 years since this issue was first created, I am not sure it's going to get much visibility
 but here goes anyway. We would like this feature implemented as a permission (via permission lists). Anyone with the permission "set-issue-status-during-move" could select the target status that was given to issue in either individual issue Move operations or during bulk-moves. This would mean that even if the target status existed in both source and target projects, the person with the designated permissions could still choose to select a different status. Please comment if/when you could address such a change. Thanks. We need this ability since the same statuses have diffrenet meanings in different projects.
Our constant problem is that moved issues get statuses such as "Open" or "In Progress" which are in the "middle" of our workflow. Because of this fact they are undetected by our filters (They lack info that should have been added in prior steps that they didn't go thouh because of the banture of the move) and when detected - we need to manually move them back to the initial status. [ Show » ] Dikla Tavor [22/Oct/06 07:45 AM] We need this ability since the same statuses have diffrenet meanings in different projects. Our constant problem is that moved issues get statuses such as "Open" or "In Progress" which are in the "middle" of our workflow. Because of this fact they are undetected by our filters (They lack info that should have been added in prior steps that they didn't go thouh because of the banture of the move) and when detected - we need to manually move them back to the initial status. This is important for our organisation as we have multiple workflows, issue types and projects. An issue may be raised in one workflow of one issue type incorrectly, and then need to be moved to an appropriate issue type. Without being able to set the status, the issue may be locked into an invalid or unnecessary status for the current stage of the issue. For example, certain issue types are raised and need approval before work is done on them. Others do not, but moving an issue from a type that needs approval to one that does not necessarily while still at the Awaiting Approval status does not allow the status to be unset.
If I have a step called Open in two different workflows but they have different step IDs, will the wizard force status selection (even if they are called the same)? Having said that, I'd rather not have to re-write and re-publish all my workflows to workaround this, although I'd like to know whether this is an option. Can you confirm therefore whether the status matching is based on step ID, step name, associated status or another property, and whether this scenario would give the desired result? Thanks Jag,
The status ID is what is matched when migrating issues between projects. The wizard simply looks to see whether the originating status matches a valid status in the target workflow, if not the status must be selected. There is no override for this behavior at the moment. Joanna, that seems to be a reasonable way in which to implement it. Unfortunately, this feature is not scheduled at present. Hi Jed,
Thanks very much for your time and answer. Yes, I figured that is what it was doing (i.e. looking for the same Status ID). Although I myself have never seen it any other way, one of our user groups is certain that it was different in some prior version of Jira (i.e it 'used to allow them to change status even if it was the same), but then it stopped during one of the Jira upgrades. It might have been before I got to Polycom, so I cannot be certain. Or.. they could be mistaken .. Or, it's possible that we had two status values with the same name (or misspelled but still look-alike name). In which case, when they were moving an issue, the underlying status IDs were different, and therefore it used to ask them to map. Any of those thigns are possible, so if you say that it was always like this in Jira, I certainly believe you. In any case, it would be nice (in the future) to implement what we are requesting.. The ability for a permission group to override the status mapping during an issue move – even if the Status ID is identical among the projects (or issue types for that matter). Thanks for your consideration. Joanna We have different workflows for Bugs and Change Request for instance. At some point both have a state Open, but with a different meaning and for the CR the Open state comes further in its life cycle than for the Bug. So when our users have to move a Bug to a CR (not quite uncommon), they always go crazy a little bit. And there is no workaround, because at this point we do not allow the steps back process-wise.
I really hope this feature will be scheduled in the near future. |
||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Allow Admin to force set target status for all 'Move Issue' operations.