Vote #68475
完了ActionView::TemplateError (undefined method `empty?' for nil:NilClass) on line #12 of app/views/context_menus/issues.html.erb:
0%
説明
Visiting this URL always results in a 500 internal server error. The error in the production log has been attached.
http://dev.somedomain.com/issues/context_menu
I found this problematic URL after a search engine navigated to it, and reported it as a problem.
Using::
Redmine 1.0.2
Rails 2.3.5
MySQL 5.1.49
Phusion passenger 2.2.11
Ruby 1.8.7.299
Processing ContextMenusController#issues (for 192.168.1.1 at 2010-10-26 18:59:35) [GET]
Parameters: {"action"=>"issues", "controller"=>"context_menus"}
Rendering context_menus/issues
ActionView::TemplateError (undefined method `empty?' for nil:NilClass) on line #12 of app/views/context_menus/issues.html.erb:
9: :class => 'icon-edit', :disabled => !@can[:edit] %>
10: <% end %>
11:
12: <% unless @allowed_statuses.empty? %>
13: -
app/views/context_menus/issues.html.erb:12
app/controllers/context_menus_controller.rb:36:in `issues'
/usr/lib/ruby/1.8/phusion_passenger/rack/request_handler.rb:92:in `process_request'
/usr/lib/ruby/1.8/phusion_passenger/abstract_request_handler.rb:207:in `main_loop'
/usr/lib/ruby/1.8/phusion_passenger/railz/application_spawner.rb:418:in `start_request_handler'
/usr/lib/ruby/1.8/phusion_passenger/railz/application_spawner.rb:358:in `handle_spawn_application'
/usr/lib/ruby/1.8/phusion_passenger/utils.rb:184:in `safe_fork'
/usr/lib/ruby/1.8/phusion_passenger/railz/application_spawner.rb:354:in `handle_spawn_application'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:352:in `__send__'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:352:in `main_loop'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:196:in `start_synchronously'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:163:in `start'
/usr/lib/ruby/1.8/phusion_passenger/railz/application_spawner.rb:213:in `start'
/usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:262:in `spawn_rails_application'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add'
/usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:256:in `spawn_rails_application'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server_collection.rb:80:in `synchronize'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server_collection.rb:79:in `synchronize'
/usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:255:in `spawn_rails_application'
/usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:154:in `spawn_application'
/usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:287:in `handle_spawn_application'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:352:in `__send__'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:352:in `main_loop'
/usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:196:in `start_synchronously'
/usr/lib/phusion_passenger/passenger-spawn-server:61
Rendering /home/user/domains/dev.somedomain.com/public_html/public/500.html (500 Internal Server Error)
journals
Thanks for the bug report.
It's easier if you post the error message into the body of the issue so someone doesn't have to download the file to see the error.
--------------------------------------------------------------------------------
Noted. :)
--------------------------------------------------------------------------------
Two problems at first sight:
* we should use @blank?@ everywhere, which works with @nil@, whereas @empty?@ doesn't
* we should refine HTTP method usable for this action ; today context_menu is accessed through POST, so GET could be blocked at routing level, but we should switch to GET and don't use POST if we want to follow REST principles
I'll look at the first one before tomorrow, but second one won't be addressed in 1.0.3 I think.
--------------------------------------------------------------------------------
Jean-Baptiste Barth wrote:
> Two problems at first sight:
> * we should use @blank?@ everywhere, which works with @nil@, whereas @empty?@ doesn't
+1, or if it's a negative like here use @present?@ and change the @unless@ to an @if@ (@if @allowed_statuses.present?@)
> * we should refine HTTP method usable for this action ; today context_menu is accessed through POST, so GET could be blocked at routing level, but we should switch to GET and don't use POST if we want to follow REST principles
I think GET is better. Since the parameters passed to the context menu don't change anything on the server, GET is safe. Should we open a new issue for this?
--------------------------------------------------------------------------------
Eric Davis wrote:
> I think GET is better. Since the parameters passed to the context menu don't change anything on the server, GET is safe. Should we open a new issue for this?
Yes, I'll do.
--------------------------------------------------------------------------------
Original problem fixed in r4302. I'll open new issues for the other things we mentionned.
--------------------------------------------------------------------------------
Merged into 1.0-stable for release in 1.0.3
--------------------------------------------------------------------------------