|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Jed Wesley-Smith [Atlassian] - 06/Dec/07 08:00 PM
The fix for this issue has not been able to make it into JIRA v3.12. We are hoping to incorporate it into v3.12.1. As of writing however, there are 163 items scheduled as Fix For v3.12.1. We will not be able to include all of them.
this would be really nice to have fixed...we try to fool proof our jira implementation and being able to do this on a workflow transition would help with that. this has become a special problem since we implemented greenhopper and started tracking time remaining in jira.
just as a note, i tried something i thought might work, by have a workflow transition record time spent of 1 minute before updating the time remaining to zero. alas, that did not work either. Having evangelized Jira to three companies now, I'm eagerly awaiting the day that I will be able to stop making excuses for this bug. With all the excellent time tracking improvements made recently, the problem only becomes more glaring, as our progress bars end up constantly inaccurate.
I´m agree with Lorien. It´s very annoying that you manually should set remaining time to 0 when closing an issue.
Please Atlassian,
Look at the comments on this issue and other high priority issues concerning the same bug. You cannot longer ignore this issue by keeing it on a .X release. Assign this issue to a release coming out soon. Please consider actually assigning this issue instead of keeping it on the 3.12.X bench. Kind regards, Hi All,
We would like to fix this issue. The problem is that I do not see a good way to fix it without introducing other problems. At the moment the Update Issue Field Post-Function is actually working consistently with the Time Tracking rules in JIRA. That is, if no work has been logged against an issue, the Original Estimate can be edited. When the Original Estimate is edited it will automatically update the Remaining Estimate. Once work has been logged against an issue the original estimate is frozen, as otherwise, it is not "original" anymore, and only the Remaining Estimate can be updated. If we allow the Update Issue Field Post-Function to be "special" by allowing it to update the issue Remaining Estimate without updating the Original Estimate before work is logged on the issue, there will be side affects. For example, if the issue is manually edited, without work being logged first, the Remaining Estimate will also be updated. This will be annoying and confusing, and the user will have no way of forcing the Remaining Estimate to be set to 0 again, apart from logging some work against the issue first, or forcing the issue through a workflow transition which uses the Update Issue Field Post-Function. I am afraid that this will also cause a lot of confusion down the track, and once we introduce this behaviour, we would not be able to take it away, as we take backwards compatibility seriously. So it looks like we would need to do more work then just fix the Post-Function. We would need to revisit how/when a user is able to update the Original Estimate and the Remaining Estimate. As far as I can tell, the main cause of the problem discussed in this issue, is that it is not currently possible to log work as part of the Resolve Issue transition (JRA-868). Therefore, people resolve first, then log work, and this is where the Original Estimate gets lost. Given that we cannot simply just put a fix into the Post-Function, would it be better to shoot for implementing JRA-868 instead? At the moment, it seems like a better solution that would actually solve the underlying problem, make more sense to users, and not cause further confusion down the track. What do you think? Cheers, I think solving JRA-868 is a great idea, please go for it, but I don't see how that helps with this issue or JRA-13733 or JRA-1993.
I understand that if no work has been logged, the original estimate can be updated. From your explanation I still do not understand why a post function can't update the Remaining Estimate only. Why does updating the remaining estimate have anything to do with the original estimate? Can't you just freeze the original estimate ALSO when updating the remaining estimate OR logging work? Remaining estimate and original estimate should be separate, unrelated values, and ONLY related when logging work, which as explained in JRA-13733 should be optional. People need to be able to set the remaining estimate to whatever they want, whenever they want. If this breaks some JIRA rules, then make this behavior a configurable option, off by default. Suppose you have 8h as original estimate. someone fix that task,... although no work time has been logged, why can´t we set remaining estimate to 0? without changing original estimate? If after that someone logs work time, it just should work as original, but remaining estimate should be 0 - "new work time logged" = 0.
Ok, I see your point now. What we should do in post function is just: 1) to log a time worked as 1 minute, for example (in fact, at least someone is thinking about that task  ), if no work time logged before.2) To set remaining estimate to 0 . So after step 1, setting remaining estimate in step 2 always will change true remaining estimate, as we are sure we have logged some time to work log. Is this ok? Hi Anton,
Thanks for your response. Although fixing I understand that changing the original estimate is complaint with the Jira rules. Great, but that is no reason to be able to change ONLY the remaining time. We don't want to change the default behavior of Jira. We just want you to enable us to change to workflow to our desire. And only changing the remaing time is a valid request. That others want to change the original estimate as well: fine. Allow them by a separate workflow action. Please keep us informed about how Atlassian will approach this issue. Kind regards, Jose,
I tried to implement what you suggested
I worked for me, but trying to store value 1 in time spent, in post function of workflow.
But now, can I create a custom post function so I can check if time spent is 0 before changins its value? Hi,
Thank you for your responses. They have helped a great deal! After evaluating possible solutions, I believe the best alternative is to separate the updates to Remaining Estimate from Original Estimate, such that it would be possible to update the Remaining Estimate at any time without affecting the Original Estimate. After the change, we will preserve the current behaviour of JIRA where the Original Estimate is "locked" after work has been logged on the issue. We would prefer not to add the functionality to the UpdateIssueFieldFunction such that it creates a work log with duration of "1 minute" if no work logs exist. The main reason for this is that we believe this solution would not be suitable for all JIRA users, and once released we would have to maintain this behaviour for ever. The fix to this issue would not be trivial, and therefore, for the sake of stability, it would be done as part of a major release. We're currently deep into developing JIRA 4.0 in which we are addressing the top 2 most popular issues - JRA-2509 and JRA-1604, as well as Cheers, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Critical
Setting remaining time to 0 in a post function of the workflow causes the original estimate to be set to 0 as well (only when no time was logged by the assignee)
