Defect #3075
Context-menu issue-status change fails under certain circumstances
Status: | Closed | Start date: | 2009-03-30 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | Issues | |||
Target version: | - | |||
Resolution: | Fixed | Affected version: |
Description
An issue-status change of an issue, when using a required timelog-customfield without default value, which gets initiated by a context-menu action, fails (actually leads to the edit-view saying that the timelog-customfield value should be given for the to-be-created 0.0-timelog).
This seems to be caused by something that has affected Redmine earlier: 0.0 timelog entry creation. See defect #1147 which got closed but still not fixes this error when using the context-menu's status-change action.
Quote from myself on #1147:
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.
This side-effect clearly does not fixes the issue when using the context-menu's status-change action.
This is something I have experienced before on my tour around patch #1650. I've followed-up the discussion on that issues journal in this forum-thread http://www.redmine.org/boards/1/topics/show/2352 and I explain the actual defect in detail in this section and I proposed a (maybe dirty) solution for this issue in this section.
Related issues
Associated revisions
History
#1
Updated by Mischa The Evil over 13 years ago
- Affected version (unused) set to devel
Forgot to mention: tested this on Redmine trunk at r2641.
#2
Updated by Jean-Philippe Lang over 13 years ago
I'm not able to reproduce this problem. Here is what I do:
- I've created a required text timelog custom field with no default value
- Time tracking is enabled on the project
- I'm logged in as an admin
- On the project issue list, I right-click on an issue
- I change the issue status from the context menu
- The issue status is changed and the issue list is refreshed
Is there anything I'm missing?
#3
Updated by Mischa The Evil over 13 years ago
- File error_on_contextmenu_status-change.jpg added
- File issue_after_issuestatus-change.jpg added
- File spent-time_details_after_issuestatus-change.jpg added
Jean-Philippe Lang wrote:
I'm not able to reproduce this problem. Here is what I do:
- I've created a required text timelog custom field with no default value
- Time tracking is enabled on the project
- I'm logged in as an admin
- On the project issue list, I right-click on an issue
- I change the issue status from the context menu
I am doing exactly the same on a clean checkout of r2641 with only the default data loaded and after creating one timelog customfield of the type text which is required but which hasn't a default value. The admin I login with is the default admin which I've made manager of the corresponding project.
Jean-Philippe Lang wrote:
- The issue status is changed and the issue list is refreshed
Here the behaviour is different on my platform. I am being redirected to the edit-view which prompts me that the timelog customfield can't be blank:
If I remove the (required) timelog customfield and repeat the above steps the issue-status change is executed as you proposed above, though a 0.0
-timelogentry is then written to the DB which isn't visible on the issue-view:
but it is visible on the spent-time report(s):
Jean-Philippe Lang wrote:
Is there anything I'm missing?
I don't know... For what it's worth, here is a list of the components of my test-environment:
- Ruby distibution: Phusion Ruby Enterprise Edition 1.8.6-20080810
- Ruby version: 1.8.6 (i686-linux)
- RubyGems version: 1.3.1
- Rails version: 2.2.2
- Active Record version: 2.2.2
- Action Pack version: 2.2.2
- Active Resource version: 2.2.2
- Action Mailer version: 2.2.2
- Active Support version: 2.2.2
- Database adapter: MySQL 4.1.20
- Webserver: Apache 2.0.52 with Phusion Passenger 2.0.3
- Redmine: Trunk at revision r2641
- Browser: Mozilla Firefox 3.0.8
If more info is required please let me know...
Kind regards,
Mischa.
#4
Updated by Jean-Philippe Lang over 13 years ago
What is strange is that it seems you have a default value of 0.0 for the TimeEntry "hours" attribute.
Maybe that's why the TimeEntry gets saved.
Can you try this in your console:
>> TimeEntry.new.hours => nil
#5
Updated by Mischa The Evil over 13 years ago
Jean-Philippe Lang wrote:
What is strange is that it seems you have a default value of 0.0 for the TimeEntry "hours" attribute.
Maybe that's why the TimeEntry gets saved.Can you try this in your console:
[...]
I needed some time to get this tested well with a 100% clean trunk checkout (r2696) but here are my results:
In my case the console indeed gives me:
>> TimeEntry.new.hours => 0.0
This seems to be most-likely an incompatibility with MySQL 4.1.x since migration 32 (create_time_entries) includes:
create_table :time_entries do |t| t.column :project_id, :integer, :null => false t.column :user_id, :integer, :null => false t.column :issue_id, :integer t.column :hours, :float, :null => false t.column :comments, :string, :limit => 255 t.column :activity_id, :integer, :null => false t.column :spent_on, :date, :null => false t.column :tyear, :integer, :null => false t.column :tmonth, :integer, :null => false t.column :tweek, :integer, :null => false t.column :created_on, :datetime, :null => false t.column :updated_on, :datetime, :null => false end
but my current schema.rb
includes:
create_table "time_entries", :force => true do |t| t.integer "project_id", :default => 0, :null => false t.integer "user_id", :default => 0, :null => false t.integer "issue_id" t.float "hours", :default => 0.0, :null => false t.string "comments" t.integer "activity_id", :default => 0, :null => false t.date "spent_on", :null => false t.integer "tyear", :default => 0, :null => false t.integer "tmonth", :default => 0, :null => false t.integer "tweek", :default => 0, :null => false t.datetime "created_on", :null => false t.datetime "updated_on", :null => false end
This leads me to the conclusion that my DB isn't build correctly and since you're testing on MySQL 5.x and I am testing on 4.x I am to blame it another MySQL-compatibility issue... Though, correct me if I'm wrong...
With regards,
Mischa.
#6
Updated by Mischa The Evil over 13 years ago
- File working_db_structure-time_entries_table.png added
I've been trying to fix this error for myself and now found that the issue seems to be solved by changing the structure of hours
-column in the time_entries
-table.
The current (for me, working) structure of the table looks like this:
r2757)" alt="Corrected DB-structure of the time_entries-table (r2757)" />
Now, no default 0.0
-value is "pre-selected" when updating issues and adding timelogs (intended?) which solves the problem of the issue status-change, initiated from the context-menu, leading to the screens mentioned before asking me to correct the values.
This logically "solves" the output of TimeEntry.new.hours
of showing 0.0
instead of nil
. After my changes in the DB-structure, as displayed in the attached image, the console gives me a correct:
>> TimeEntry.new.hours => 0.0
HTH...
Regards,
Mischa.
#7
Updated by Jean-Philippe Lang over 12 years ago
- Status changed from New to Closed
- Resolution set to Fixed
Fix committed in r3232 for when a default value is set in the database.
#8
Updated by Mischa The Evil over 12 years ago
Jean-Philippe Lang wrote:
Fix committed in r3232 for when a default value is set in the database.
Thanks for the fix Jean...