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.

Issue listing removing all columns (Bug #504)

Added by Tom Rochette at 2011-07-01 10:02 pm. Updated at 2011-07-28 06:56 am.

Status:Declined Start date:2011-07-01
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:Issue tracking
Target version:-
Remote issue URL: Affected version:unstable

Description

When listing the issues on issues page, if you click on the apply button, all the columns get removed from the list of displayed columns. If you click on the apply button again, the list is correctly displayed.

RAILS_ENV=production ruby script/about 
About your application's environment
Ruby version              1.8.7 (i686-linux)
RubyGems version          1.3.7
Rack version              1.1.2
Rails version             2.3.12
Active Record version     2.3.12
Active Resource version   2.3.12
Action Mailer version     2.3.12
Active Support version    2.3.12
Application root          /home/chiliproject
Environment               production
Database adapter          mysql
Database schema version   20110519194936

I was not able to reproduce the problem on a local machine, but able to determine that it was probably caused by the use of a proxy hiding thin server instances.

Attached is a list of of requests using both :3000 and the proxy itself. As you can see in the second part of the log (bogus), the c variable receives a list of comma separated value instead of receiving an array (like in the first part). Furthermore, the second request (clicking on the apply button a second time) does not contain any column list, but does display the default column listing (not the one requested).

incorrect_issue_listing.txt (2.3 kB) Tom Rochette, 2011-07-01 10:02 pm

History

#1
Updated by Eric Davis at 2011-07-01 10:03 pm

  • Target version deleted (2.0.0)
  • (deleted custom field) set to unstable

#2
Updated by Felix Schäfer at 2011-07-08 08:22 pm

Tom Rochette wrote:

I was not able to reproduce the problem on a local machine, but able to determine that it was probably caused by the use of a proxy hiding thin server instances.

  1. Can you give us more precise steps to reproduce the error? (e.g. go to the issue list, open the column selection, add a column to the active columns list, click apply)
  2. Can you rule out the proxy? If the problem is with the proxy mangling stuff before serving it to ChiliProject, I'm afraid there's not much we can do about it…

#3
Updated by Tom Rochette at 2011-07-09 12:26 am

  1. Go to the issue page
  2. Click on the apply button
    1. Notice that only the checkbox column as well as the id are displayed, while others columns are not
  3. Click on the apply button again
    1. Notice that the default columns are now displayed

I know it is due to the proxy because like I've mentioned in the issue, going to the thin instance (port 3000) will not cause this problem if I do the steps listed above. But, if I actually go to the proxy instead (possibly redirecting to one of four thin instances), this bug appears.

I believe it is related to chiliproject due to the fact that I did not face this problem while I was using redmine for the past 2 years.

Best repro steps would be:
  1. Install chiliproject
  2. Use thin as server with 4 instances
  3. Use apache to proxy the 4 instances behind one domain name
  4. Test the above steps which should result in the bug

#4
Updated by Felix Schäfer at 2011-07-09 10:17 pm

Tom Rochette wrote:

  1. Go to the issue page
  2. Click on the apply button
    1. Notice that only the checkbox column as well as the id are displayed, while others columns are not
  3. Click on the apply button again
    1. Notice that the default columns are now displayed

I know it is due to the proxy because like I've mentioned in the issue, going to the thin instance (port 3000) will not cause this problem if I do the steps listed above. But, if I actually go to the proxy instead (possibly redirecting to one of four thin instances), this bug appears.

Can you turn on some logging on the proxy and see what it gets in and sends out to the thins? Your report still has me thinking it's a problem with the proxy.

I believe it is related to chiliproject due to the fact that I did not face this problem while I was using redmine for the past 2 years.

I don't remember any changes that were in ChiliProject only in that area, hence I have a hard time accepting your fact.

Best repro steps would be:
  1. Install chiliproject
  2. Use thin as server with 4 instances
  3. Use apache to proxy the 4 instances behind one domain name
  4. Test the above steps which should result in the bug

I'm sorry I won't go to that lengths to try to reproduce it. I'll try on my local devel install if I can replicate the behavior you're getting tomorrow, that will be on passenger and webrick only though.

#5
Updated by Tom Rochette at 2011-07-28 03:54 am

As I expected, this is not a bug with Chiliproject but a bad apache configuration on my part. The proxy being the problem was a good clue.

What was the actual problem was that my vhost was refering to my old redmine location, thus it would serve redmine's public folder instead of chiliproject's public folder. This would result in a different version of prototype.js being served when accessing the site through the proxy compared to the one served directly by the server instance.

I close this.

  • Status changed from Open to Declined

#6
Updated by Felix Schäfer at 2011-07-28 06:56 am

Tom Rochette wrote:

I close this.

Thanks for the heads-up!

Also available in: Atom PDF