ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
internal error on journals for deleted custom fields (Bug #640)
Description
UPDATE (Felix Schäfer): The journal rendering errors out on trying to show attributes of deleted custom fields, this should be handled gracefully.
When attempting to show certain issues the following backtrace is printed in the log:
Processing IssuesController#show (for 192.168.10.32 at 2011-09-23 12:38:23) [GET] Parameters: {"action"=>"show", "id"=>"942", "controller"=>"issues"} Rendering template within layouts/base Rendering issues/show.rhtml ActionView::TemplateError (undefined method `name' for nil:NilClass) on line #2 of app/views/issues/_history.rhtml: 1: <% for journal in journals %> 2: <%= render_journal issue, journal, :edit_permission => :edit_issue_notes, 3: :edit_own_permission => :edit_own_issue_notes %> 4: <%= call_hook(:view_issues_history_journal_bottom, { :journal => journal }) %> 5: <% end %> app/helpers/journals_helper.rb:48:in `render_journal_details' app/helpers/journals_helper.rb:47:in `each' app/helpers/journals_helper.rb:47:in `collect' app/helpers/journals_helper.rb:47:in `render_journal_details' app/helpers/journals_helper.rb:46:in `render_journal_details' app/helpers/journals_helper.rb:29:in `render_journal' app/views/issues/_history.rhtml:2:in `_run_rhtml_app47views47issues47_history46rhtml_locals_history_issue_journals_object' app/views/issues/_history.rhtml:1:in `each' app/views/issues/_history.rhtml:1:in `_run_rhtml_app47views47issues47_history46rhtml_locals_history_issue_journals_object' app/views/issues/show.rhtml:95:in `_run_rhtml_app47views47issues47show46rhtml' app/controllers/issues_controller.rb:102:in `show' app/controllers/issues_controller.rb:101:in `show' /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 /var/chiliproject-git/public/500.html (500 Internal Server Error)
Here are two DB entries for a working (id=943) and not working (id=942) issue in case there is some problem with the DB:
id tracker_id project_id due_date category_id status_id assigned_to_id priority_id fixed_version_id author_id lock_version created_on updated_on start_date done_ratio estimated_hours parent_id root_id lft rgt 942 2 4 2011-09-30 NULL 2 5 5 NULL 5 13 2011-08-19 17:25:08 2011-09-23 12:39:23 2011-08-19 20 NULL 931 931 6 7 943 5 4 NULL NULL 5 2 3 NULL 2 5 2011-08-22 11:49:45 2011-09-23 13:31:06 2011-08-22 0 NULL NULL 943 1 2
The issues come from a recent migration from trac to chiliproject.
Please let me know if you need further info to analyze the problem.
History
Updated by Chris Dähn at 2011-09-23 05:20 pm
...for me too, didn't had this issue with 2.1.1 - then upgraded to 2.2.0 on wednesday and since then a few of my tickets produce the above error on viewing -> but NOT when editing wonder
Any hints are appreciated.
Updated by Marcin Garski at 2011-09-28 06:41 am
I've got this same problem. Any ideas?
Updated by Felix Schäfer at 2011-10-06 09:22 pm
Chris Dähn wrote:
...for me too, didn't had this issue with 2.1.1 - then upgraded to 2.2.0 on wednesday and since then a few of my tickets produce the above error on viewing -> but NOT when editing wonder
That's probably a problem with the journals, though I also noticed the non-working issue has a parent. Anyway, the journals/history is one part that's shown on the issue view but not on the edit view.
Can you see to provide the entries of the journals
table that correspond to the non-working issue.
(I also had a look at the diff between 2.1.1 and 2.2.0 and honestly can't find anything, you sure you run all migrations correctly, or that you don't have a plugin hooking into the issue view that wreaks some havoc?)
Updated by Chris Dähn at 2011-10-07 08:31 am
Hi,
I've grabbed one problem issue and pasted it's issue table and journals table entry into a text file (see attached file).
The internal errors even occur without any thirdparty plugins.
Hope it helps a bit.
ciao,
Chris
- File issue_640_debug.txt added
Updated by Felix Schäfer at 2011-10-07 08:40 am
One thought that crossed my mind: do you happen to have deleted users at some point, either because you had a Redmine version that allowed user deletion or because you toyed with the DB?
Updated by Chris Dähn at 2011-10-07 08:49 am
I checked that:
All users from id 1 up to 14 are still existing, like in Trac before. There was no Redmine installation using this database, nor did anyone modify the database directly (because it's a production system and everybody get's his hands cut off when touching it) ;-)
ciao,
Chris
Updated by Chris Dähn at 2011-10-14 08:07 am
Hi,
are there any news or hints how to process further?
This bug is extremely annoying in daily use and it's very disappointing to get comments "Hey, why can't I read my tickets in ChiliProject like years before in Trac?".
If I can suport the debugging with further infos or test data, don't hesitate to ask me for it.
ciao,
Chris
Updated by Felix Schäfer at 2011-10-14 08:28 am
Chris Dähn wrote:
If I can suport the debugging with further infos or test data, don't hesitate to ask me for it.
I haven't gotten around to looking into your data, sorry.
I understand your frustration, but it's also very hard for us to debug problems we can't reproduce as it is "asynchronous" and I have to "get back into the issue" each time, which is pretty time consuming.
Updated by Chris Dähn at 2011-10-14 08:38 am
Hi Felix,
I understand your situation, of course. Thus my question for supporting you - maybe you can give me a hint how I can ran some debugging myself - or provide me some links for that.
Further I'll try to learn Ruby to better get the ChiliProject system up running (like before in Trac, where I was used to patch plugins etc. just to keep the system running).
And - even if I currently have very less spare time - I'm really interested and motivated to support the ChiliProject team/project - e.g. by creating some help and documentation and some information sources for beginners/users like me :-)
So I hope to be able to support you with patches in the near future.
ciao,
Chris
Updated by Eric Davis at 2011-10-14 06:28 pm
It might also be something other than a user. All of these fields have a name attribute, any one of them being deleted might cause this error (though it shouldn't).
- custom field
- priority (enumeration)
- issue category
- issue status
- tracker
- version
Updated by Chris Dähn at 2011-10-14 07:10 pm
Ok, that's a point which I can check myself easily...
Thanks for the hint!
ciao,
Chris
Updated by Chris Dähn at 2011-10-17 02:12 pm
Hi,
I checked the custom fields and found some deleted ones - after re-inserting them from a backup, all tickets where usable again without errors!
Thanks for your hint Eric!
So this ticket can be marked as [SOLVED] :-)
ciao,
Chris
Updated by Felix Schäfer at 2011-10-17 03:47 pm
Chris Dähn wrote:
I checked the custom fields and found some deleted ones - after re-inserting them from a backup, all tickets where usable again without errors!
Thanks for your hint Eric!
So this ticket can be marked as [SOLVED] :-)
That's nice to hear, but it doesn't solve the problem, only your symptoms :-) Renaming the issue accordingly, and thanks for the feedback.
- Target version set to 2.4.0
- Subject changed from internal error when trying to access some issues to internal error on journals for deleted custom fields
- Category changed from Issue tracking to Journals / History
Updated by Chris Dähn at 2011-10-17 10:33 pm
Felix Schäfer wrote:
That's nice to hear, but it doesn't solve the problem, only your symptoms :-) Renaming the issue accordingly, and thanks for the feedback.
Agree to that: Just throwing an internal error isn't the preferred behaviour - there should be a fall back handling missing custom fields more transparently.
Further I deleted the custom fields, because they were unneeded and are replaced by other ones - so my current solution is just a dirty workaround.
But: Now the debugging should be much more easier :-)
I'll ask Gunter to rename the issue.
ciao,
Chris
Updated by Felix Schäfer at 2011-10-18 04:59 am
Chris Dähn wrote:
Agree to that: Just throwing an internal error isn't the preferred behaviour - there should be a fall back handling missing custom fields more transparently.
Further I deleted the custom fields, because they were unneeded and are replaced by other ones - so my current solution is just a dirty workaround.
Agreed.
I'll ask Gunter to rename the issue.
Already done :-)
Updated by Felix Schäfer at 2011-10-29 04:33 pm
Pull request to avoid erroring out on the history view with deleted custom fields ist at https://github.com/chiliproject/chiliproject/pull/117
Updated by Felix Schäfer at 2011-10-29 04:34 pm
- Status changed from Open to Ready for review
Updated by Holger Just at 2011-10-29 04:45 pm
Pushed in 6fcb1de
- Assignee set to Felix Schäfer
- Status changed from Ready for review to Closed