Redmine

Did the database migration run ok? Could you please provide the error trace from log/production.log?

Unfortunately the log file doesn't provide anything helpful:

# Logfile created on Thu Aug 19 13:38:28 -0400 2010Sending email notification to: <internal email addresses>
Sending email notification to: <internal email address>
Sending email notification to: <internal email address>

(I've been trying to upgrade for awhile, keeps getting sidelined though, heh)

Well, the 500 has to come from somewhere, what about the webserver log?

btw, the db migration did go ok... added some columns in a few places I noticed.

I managed to find this in the access logs:

10.10.20.186 - - [15/Nov/2010:15:31:01 -0500] "GET /projects/whfifq/issues/new HTTP/1.1" 500 576
10.10.20.186 - - [15/Nov/2010:15:31:01 -0500] "GET /projects/whfifq/issues/new HTTP/1.1" 500 576 "http://redmine1.myaddress.com/projects/whfifq/issues" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12" PID=16131

and then this in the error log:

ActionView::TemplateError (undefined method `-' for nil:NilClass) on line #10 of app/views/issues/_attributes.rhtml:
7: <p><label><%= l(:field_status) %></label> <%= @issue.status.name %></p>
8: <% end %>
9:
10: <p><%= f.select :priority_id, (@priorities.collect {|p| [p.name, p.id]}), {:required => true}, :disabled => !@issue.leaf? %></p>
11: <p><%= f.select :assigned_to_id, (@issue.assignable_users.collect {|m| [m.name, m.id]}), :include_blank => true %></p>
12: <% unless @project.issue_categories.empty? %>
13: <p><%= f.select :category_id, (@project.issue_categories.collect {|c| [c.name, c.id]}), :include_blank => true %>

    app/views/issues/_attributes.rhtml:10:in `_run_rhtml_app47views47issues47_attributes46rhtml_locals_attributes_object'
    app/views/issues/_attributes.rhtml:1:in `_run_rhtml_app47views47issues47_attributes46rhtml_locals_attributes_object'
    app/views/issues/_form.rhtml:25:in `_run_rhtml_app47views47issues47_form46rhtml_locals_f_form_object'
    app/views/issues/new.rhtml:7:in `_run_rhtml_app47views47issues47new46rhtml'
    app/helpers/application_helper.rb:702:in `labelled_tabular_form_for'
    app/views/issues/new.rhtml:3:in `_run_rhtml_app47views47issues47new46rhtml'
    app/controllers/issues_controller.rb:122:in `new'
    app/controllers/issues_controller.rb:121:in `new'
    passenger (2.2.11) lib/phusion_passenger/rack/request_handler.rb:92:in `process_request'
    passenger (2.2.11) lib/phusion_passenger/abstract_request_handler.rb:207:in `main_loop'
    passenger (2.2.11) lib/phusion_passenger/railz/application_spawner.rb:418:in `start_request_handler'
    passenger (2.2.11) lib/phusion_passenger/railz/application_spawner.rb:358:in `handle_spawn_application'
    passenger (2.2.11) lib/phusion_passenger/utils.rb:184:in `safe_fork'
    passenger (2.2.11) lib/phusion_passenger/railz/application_spawner.rb:354:in `handle_spawn_application'
    passenger (2.2.11) lib/phusion_passenger/abstract_server.rb:352:in `__send__'
    passenger (2.2.11) lib/phusion_passenger/abstract_server.rb:352:in `main_loop'
    passenger (2.2.11) lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously'
    passenger (2.2.11) lib/phusion_passenger/abstract_server.rb:163:in `start'
    passenger (2.2.11) lib/phusion_passenger/railz/application_spawner.rb:213:in `start'
    passenger (2.2.11) lib/phusion_passenger/spawn_manager.rb:262:in `spawn_rails_application'
    passenger (2.2.11) lib/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add'
    passenger (2.2.11) lib/phusion_passenger/spawn_manager.rb:256:in `spawn_rails_application'
    passenger (2.2.11) lib/phusion_passenger/abstract_server_collection.rb:80:in `synchronize'
    passenger (2.2.11) lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize'
    passenger (2.2.11) lib/phusion_passenger/spawn_manager.rb:255:in `spawn_rails_application'
    passenger (2.2.11) lib/phusion_passenger/spawn_manager.rb:154:in `spawn_application'
    passenger (2.2.11) lib/phusion_passenger/spawn_manager.rb:287:in `handle_spawn_application'
    passenger (2.2.11) lib/phusion_passenger/abstract_server.rb:352:in `__send__'
    passenger (2.2.11) lib/phusion_passenger/abstract_server.rb:352:in `main_loop'
    passenger (2.2.11) lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously'

Stephen Fuhry wrote:

btw, the db migration did go ok... added some columns in a few places I noticed.

That's the point of the migration, and you still seem to have a data inconsistency somewhere. Does the issue list show OK? Do you have any plugins installed? Did this redmine ever have the subtasks plugin installed? Does any row in the issues table have either lft, rgt or root_id empty?

I did have plugins installed, but uninstalling them did not seem to fix the problem. The issue list does show up fine... the only thing that doesn't work it seems is creating a new issue. Also, since we're currently running 0.9 in production, I ran this to get the issues back up to date:

UPDATE
  redmine.issues i
SET
  root_id = id
  , lft = 1
  , rgt = 2
WHERE root_id IS NULL

You're not seriously using the same DB with two different versions of the same app, are you?

heh, your tone suggests that i shouldn't have left the upgrade half complete back in Aug when I first tried and ran into this problem.. i didn't suspect that the db changes would be significant enough between releases to cause any significant issue..

either way, the problem i'm running into now is the same as the one I ran into when I first ran

rake db:migrate RAILS_ENV=production

Just as a side note, one of our guys in house wrote a script to migrate our issue tracker from FlySpray to Redmine 0.9 (actually, if anyone finds this post and needs a way to do the FlySpray => Redmine conversion, I could clean up and make the PHP script we used and make it publicly available).. so we're pretty handy with the Redmine db schema, and nothing looks odd except for the new tree in 1.0 in the issue table, which I fixed.

Stephen Fuhry wrote:

so we're pretty handy with the Redmine db schema

That's not the point. The point is that the schema is part of a rails app, for example models get their attributes directly from the schema in the DB, if some other code requests some attribute from a model that has an old schema in which that attribute doesn't exist, the app errors out. Furthermore, database migrations don't just change the database schema but might update database content, going from a boolean to a more complex text attribute might imply more than just "replace true with foo and false with bar".

My point being: you're on your own if you don't keep the DB at the "same" version as the app, doubly so if you go and meddle in there by hand, and if you really use your live production DB to test the upgrade, well, I really don't see the point of the upgrade test then.

Moving on with your issue: I can't really figure out what could cause this error on the new issue page. Random things that come to mind: How did you upgrade, did you download the package from source, from svn, from…? Do you have a default priority configured? What does Issue.new run in RAILS_ENV=production script/console in your redmine directory yield? Are you really sure you run that instance against the correct DB, and not one configured for another environment?

How did you upgrade, did you download the package from source, from svn, from…?

I did an svn checkout into a different directory and did a parallel install, except I used the same production db.

Do you have a default priority configured?

yes, there is a is_default set to 1 for IssuePriority in the enumerations table

What does Issue.new run in RAILS_ENV=production script/console in your redmine directory yield?

?> Issue.new
=> #<Issue id: nil, tracker_id: 0, project_id: 0, subject: "", description: nil, due_date: nil, category_id: nil, status_id: 1, assigned_to_id: nil,
 priority_id: 4, fixed_version_id: nil, author_id: 0, lock_version: 0, created_on: nil, updated_on: nil, start_date: nil, done_ratio: 0, estimated_hours: nil,
parent_id: nil, root_id: nil, lft: nil, rgt: nil>

Are you really sure you run that instance against the correct DB, and not one configured for another environment?

we only have one db setup for redmine.. I did run this again to be sure though:

rake db:migrate RAILS_ENV=production

I don't see anything bad with that, and I'm a little out of ideas, sorry.