Defect #1147
closed
Updating tickets add a time log with zero hours
0%
Description
Updating a ticket but leaving the "spent time" field empty still add a time log entry with zero hours. These then show up on the spent time details and reports. This issue has only started occuring recently on trunk, possibly since some revision after roughly r1350 (unsure though - can't remember what revision I was at before this started happening).
Related issues
Updated by Jean-Philippe Lang over 16 years ago
- Status changed from New to Closed
- Priority changed from Normal to High
- Target version set to 0.7.1
- Resolution set to Fixed
Updated by David Petersen over 16 years ago
- Status changed from Closed to Reopened
I don't think this is really resolved. I have a fully updated svn check out of 0.7-stable (svn://rubyforge.org/var/svn/redmine/branches/0.7-stable) and am still having this problem.
Updated by Eric Davis over 16 years ago
David Petersen wrote:
I don't think this is really resolved. I have a fully updated svn check out of 0.7-stable (svn://rubyforge.org/var/svn/redmine/branches/0.7-stable) and am still having this problem.
I just tested this with 0.7-stable and I didn't get an empty time entry at all. Can you confirm the steps you are using to reproduce this issue?
- Went to /issues/show/954
- Added a new note with an empty Spent time field
- No time appears on the issue
- No time appears on the Spent Time report
Console reports no time entries either:
>> i = Issue.find(954) => #<Issue id: 954 ...> >> i.time_entries => []
Updated by Jean-Philippe Lang over 16 years ago
Time entries previously created by this bug won't be automatically deleted. You have to do it manually.
Do you still have 0 hours time entries that are created when updating a ticket ?
Updated by Eric Davis over 16 years ago
Do you still have 0 hours time entries that are created when updating a ticket ?
Nick Read, if you want to delete the old duplicate entries you can run this command after backing up your database
script/runner -e production "TimeEntry.delete_all('hours <= 0')"
Updated by Jean-Philippe Lang over 16 years ago
- Status changed from Reopened to Closed
Please submit a new ticket if this bug reappeared in recent revision.
Updated by David Petersen over 16 years ago
- Status changed from Closed to Reopened
I am still able to create this with .7.1 .
The database that we are using has a default value set for hours '0'. This is making the Hours field on the page when you update a ticket have the preset value of "0.0" which redmine is then saving in the database as a empty time entry. I haven't been able to get rid of the default value on the db for our live db but I did on the local db and that worked.
Shouldn't redmine not preset the value of the hours field even if there is a default value in the db?
Why if you enter 0 hours in to the field does redmine still accept it?
Updated by Thomas Lecavelier over 16 years ago
David Petersen wrote:
I am still able to create this with .7.1 .
you mean with branch 0.7_STABLE or trunk? Version 0.7.1 wasn't repackaged.
Updated by Mischa The Evil over 16 years ago
While doing some testing regarding issue #1650 I just found out that this is still happening with r1745 of the trunk. I did get an empty time entry while updating an issue using the context-menu.
Steps to reproduce:- Created a new issue / Or use an existing issue without spent-time
- Change the issue using the context-menu (e.g. change priority)
- 0.00 time appears on the issue
- 0.00 time appears on the Spent Time report
Updated by Mischa The Evil over 16 years ago
Updated by Mischa The Evil over 16 years ago
After my rantings above decided to test this issue more precise. Here's what I came up with:
Zero-Hour timelogs are still added using r1745 of the trunk. I did get an empty time entry while updating an issue using the context-menu.
Steps to reproduce:- Created a new issue / Or use an existing issue without spent-time
- Change the issue using the context-menu (e.g. change priority)
- No time appears on the issue
- 0.00 time appears on the Spent Time report
Testing this with a export of the current trunk (@ r1773) this is not happening any longer. It seems to be fixed as a side-effect of the changes made in r1765.
Updated by Jean-Philippe Lang about 16 years ago
- Status changed from Reopened to Closed
I confirm that this is fixed in current trunk.