Weird issue

[vvergnolle]

Hi,

(Debian Squeeze, Postgresql 8.4)

I have a weird issue with fixmystreet. When I try to access the admin/timeline page, it's doesn't work. Postgresql telling that there is an error :

the "created desc" column doesn't exists

Does someone know why dbix group this values ?

Even more weird, when I try to access the admin/reports page after having this issue, I have the same problem but if I don't visit first the admin/timeline page first I dont have this problem.

I really don't understand what's is going on.

Thanks by advance

[mhl]

@vincent7894 Thanks for reporting the problem. Could you possibly paste in the exact error message that you get, since what you've said:

the "created desc" column doesn't exists

doesn't sound right. Please could you also let us know:

• ... how you installed FixMyStreet
• ... what version of FixMyStreet you're using

If you installed FixMyStreet by following the manual instructions, could you check whether you did the step that ran db/alert_types.sql in your database? (That might explain an error similar to what you're describing.)

[vvergnolle]

Hi,

Sorry for the late of the response.

This is my apache error log file : https://dl.dropboxusercontent.com/u/54953699/fixmystreet_error.log

In the case of the installation, I have installed the plateform with the tutorial which is located on your website (http://code.fixmystreet.com/install/).

I precise that I have this error on the admin dashboard, more precisely on the report and the timeline page. But the error on the report page is weird because it's happening only if, at the beginning, i visit the timeline page. (The timeline page cause always an error))

I realy don't know what's going on

For the alert_type I have these rows in my database (select ref from alert_type) :

new_updates new_problems new_fixed_problems local_problems local_problems_state postcode_local_problems postcode_local_problems_state council_problems ward_problems area_problems

[dracos]

Thanks for posting the error log. The first error quoted is more important than the second (which is just a fallout from the first) - the issue is that the areas column does not exist in your database (and it shouldn't if you're running a recent version of the FixMyStreet code). The areas column ceased to exist back at FixMyStreet version 1.1, when we switched to using bodies, as explained at http://code.fixmystreet.com/2013/02/22/bodies/ , and all mentions of the areas column in the core code were removed at that time.

One of two things seems likely:

• your database version doesn't match the version of the code (the database being more up-to-date than the code); or
• you have created a custom cobrand .pm module file with a site_restriction() function that is out-of-date and referring to the non-existent column.

I don't know how you've installed/updated your code, so I can't say which of these it is - the first option does seem less likely, because it would seem odd to end up with the database schema newer than the code (the other way round is more likely). If however, you had made some custom files, then updated the core code to a more recent version, that could lead to the second option.

If you have created custom files, you will need to update them to match the current code you are running. Are your customisations available in a fork on github for us to look at (as described at http://code.fixmystreet.com/customising/ under Feeding back changes)? That would help in future if there are any other problems, plus we can potentially merge them back into upstream so that if there are future schema changes, or other changes that would affect your cobrand, it would get updated.

Once you get a bad database problem, as it should never happen and as the code remains in memory, it can 'infect' other pages, so I wouldn't worry about the admin report page unless it still happens after the timeline issue is fixed. Hope that's helpful.

[vvergnolle]

Hi thanks for the response,

Yes I have created two cobrands in order to use the plateform with customs boundaries and yes in my cobrand module I have redefined the site_restriction method.

If the "areas" column was removed which column I have to use for the restriction ?

For now do I need to get the code from the master branch, update the database and retry ?

(And no I don't have fork the repository, I created three files, the cobrands and I updated the configuration for my cobrand)

Maybe you want to take a look to the cobrand files ?

Thanks again for the help

[vvergnolle]

I just replace the restriction with the cobrand column.

sub site_restriction {
   return {
      'me.cobrand' => $self->moniker
   };
}

But if I do that, I have an error when I'm trying to show the map (/around). It's because I can't set the restriction to 'me.cobrand' as the 'me' is not the alias of the problem table.

[dracos]

Getting the code from master won't make any difference; the issue is that you have custom code changes that no longer match the rest of the code you are using - you must have updated the repository since you originally wrote your cobrand module. If you have custom code changes that are not public and aren't fed back to upstream, there's not a lot we can do to support those code changes :-) Please feel free to fork the code and commit your changes to your fork.

Note the code to do with restrictions isn't perfect - I see in cobrands there's both a site_restriction function and a restriction function (the latter is only used in bits of the admin, the former in other bits of the admin and RSS/ email alerts); and then both a problems_clause and problems functions for doing similar restrictions elsewhere (e.g. the front end).

[digitalfrost]

@dracos - I think this ticket can be closed