Project

General

Profile

Actions

Defect #3075

closed

Context-menu issue-status change fails under certain circumstances

Added by Mischa The Evil about 15 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
Issues
Target version:
-
Start date:
2009-03-30
Due date:
% Done:

0%

Estimated time:
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.


Files

error_on_contextmenu_status-change.jpg (23.1 KB) error_on_contextmenu_status-change.jpg Mischa The Evil, 2009-03-30 22:37
issue_after_issuestatus-change.jpg (22 KB) issue_after_issuestatus-change.jpg Mischa The Evil, 2009-03-30 22:37
spent-time_details_after_issuestatus-change.jpg (17.2 KB) spent-time_details_after_issuestatus-change.jpg Mischa The Evil, 2009-03-30 22:37
working_db_structure-time_entries_table.png (18 KB) working_db_structure-time_entries_table.png Corrected DB-structure of the time_entries-table (r2757) Mischa The Evil, 2009-05-19 01:27

Related issues

Related to Redmine - Defect #4449: Spent Time Default Value of 0.0Closed2009-12-18

Actions
Related to Redmine - Defect #1147: Updating tickets add a time log with zero hoursClosed2008-04-30

Actions
Actions #1

Updated by Mischa The Evil about 15 years ago

  • Affected version (unused) set to devel

Forgot to mention: tested this on Redmine trunk at r2641.

Actions #2

Updated by Jean-Philippe Lang about 15 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?

Actions #3

Updated by Mischa The Evil about 15 years ago

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.

Actions #4

Updated by Jean-Philippe Lang about 15 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
Actions #5

Updated by Mischa The Evil almost 15 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.

Actions #6

Updated by Mischa The Evil almost 15 years ago

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.

Actions #7

Updated by Jean-Philippe Lang over 14 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.

Actions #8

Updated by Mischa The Evil over 14 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...

Actions

Also available in: Atom PDF