|
History
| Log In
|
|
|
|
Tonight I have to do another workflow change and tomorrow I will then endure another tongue lashing by all the developers and managers for corrupting issue integrity and rendering their filters useless.
Sorry but the act of changing the updated stamp for an administrative workflow replacement is data corruption and getting the fix in should be a bit higher priority than minor. Kevin,
Appologies again for this issue. Though I think our preference is to make workflows editable while active (as then this would become a bit of a non-issue). We are aware of the trouble this can cause and agree that it is not a minor priority issue ( Nick think I just opened a duplicate of this issue.
http://jira.atlassian.com/browse/JRA-10349 
This is evil, and should be fixed. I agree that this causes data corruption, and we do anticipate to update our workflows again as we adjust to this tool. Since this happens most during early days of Jira usage, you can turn off a lot of potential customers by having a nasty bug like this around. Guys, i just did another update of workflow, and it's screwing with all the issues again.
This is extremely annoying, when do you plan to fix this? Also, as other pointed out this is not an 'improvement' this is a BUG and a very bad one.
When we do this, we should also look at other places in the code where we 'bulk' update issues as a result of a change. We need to evaluate which of those changes are real changes, and which we need to ignore for the purposes of update date.
Firstly, apologies this did not quite make it into 3.6.3. It is one of the first being fixed for 3.6.4 (will be fixed this week).
Regarding migrating issues from one workflow to another, it is clear that if the issue status does not change, the issue updated date should not change. We are not entirely sure in the case where the issue status actually does need to change. In the normal case, the issue does not change status as you would normally change between fairly compatible workflows, however it is possible to change between vastly different workflows that have very different statuses and therefore the issue will materially change. In this limited case should the update date reflect the change or not. Please let us know if you have a firm opinion one way or the other.
What if you provide option on changing dates for every type of mapping FromOldToNewWorkflow? Well, it seems everyone interested in this issue is fairly clear that NOT changing the date is the correct behaviour. Where the issue simply moves from one workflow to another and the issue status is not changed there is no value in setting the updated date, as this issue describes. There would seem to be little value in having a checkbox that effectively says "How would you like your data? ( ) Corrupted ( ) Uncorrupted"
What we are interested in is the edge case. What do we do with ones where the status is changed. We are leaning to not setting the updated date, and simply adding a change record. D'oh! I was planning to upgrade to 3.6.3 with this fix so I could make my instance public. Now I have to wait again. I like your take - meaning why would anyone want the date changed when the workflow was changed. As to the case when an issue status is changed because of the workflow change, I do see your point. If someone is using last updated date as an indicator of their task list (as we do), we certainly don't want it changed just because some internal admin (changing workflow) took place. But if the status changed, would we? In my case, I would say no. If an internal workflow change meant my "Deferred" issues had to be marked as "Closed", I don't think anyone would care to see that reflected in the individual issue's status. And in the case where all or a majority of issues had their status changed as part of this process, then updating the date if the status changes would basically render this fix as unusable. So my vote would be
1st choice: When presenting the screen with the status mappings, include a checkbox (defaulted to off) "Update each issue's Last updated Date". 2nd choice: even if issue status changes, don't update the date. 3rd choice: Do number 2 now, and schedule an enhancement to do number 1 in a future release. We have changed the behavior for JIRA 3.6.4. We will not set the updated date if the only thing changing about the issue is the workflow. If the status is changing as a result of migrating the workflow then this constitues a change to the issues data and we will set the updated date.
To clarify, after some robust internal debate, it was decided that the changing of the issue status is analagous to a workflow transition that modifies its state. We can think of no really good reason that a status change should NOT be a material change, or why you want to change the workflow such that (in the example above) the workflow change forced the changing of "Deferred" status items to "Closed" status and this is NOT considered a material change to the issue.
Any bulk editing of issues that materially changes the data of that issue changes the updated date. For consistency, that remains true whether the bulk edit was through the bulk edit page or changing the workflow. The actual workflow of a particular issue is a generated artefact of the workflow scheme for the project, and so is not really part of the conceptual data for the issue, and therefore should never have been setting the updated date of the issue. This no longer occurs. I appreciate Atlassian giving this the priority and discussion. So can you raise an improvement request so that maybe in future versions, this would indeed be an option? I can certainly present use cases where this would be advantageous. For example, my users use the last updated date but don't care if the status was changed from "In testing" to "In Phase 1 of testing" or some similar administrative change. Thanks.
Any idea when 3.6.4 is to be released? I don't know if I can wait until then for this. I just upgraded to 3.6.3 and somehow I thought this issue was included. I guess not. Thanks.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Changing Workflow should not change Date Updated or provide option not to
JRA-7831would solve some of the problem ofJRA-7661