When accessing the URL `/admin/stats/budget_balloting?budget_id=X'
for a budget in a phase prior to the balloting phase, the following
error was raised due to the stats where not calculated yet.
Instead, we'll now show a flash message.
NoMethodError:
undefined method `[]' for nil:NilClass
./app/controllers/admin/stats_controller.rb:82
Joining the translations table caused duplicate records to appear.
Ordering with SQL is simply too hard because we need to consider
fallback locales.
Thanks Senén for providing most of the tests in the poll spec.
There were some custom routes created using the param[:id] but the
Rails routes use the param[:budget_id] by default, so the same
controller could be asked for different param keys.
Changed applied:
- Remove Archived proposals from tab and add a link under Proposals
lists
- Remove Popular proposals link from custom section and add it to the
Proposals lists
- Remove Retired proposals link from custom section and add it to the
Proposals lists
- Remove Selected proposals link from custom section and add it to the
Proposals lists
Using arrays made it difficult to order by more than one field (like the
`most_voted` scope does), and so we were ordering by `confidence_score`
and ignoring the `created_at` column.
Using an AR relation makes it easy to reuse the existing `most_voted`
scope.
This change has one side effect: now comments with equal votes are
ordered in descending order instead of having no specific order. That
means flaky specs which failed sometimes because they assumed comments
were ordered by date are now always green.
I've also re-added the `oldest` scope removed in 792b15b thinking it was
removed because using it with arrays was too hard.
Polls that were not votable by a user were not being displayed in the officing interface. Creating a confusing situation for officers.
With this commit polls that are not votable by a user will be displayed, with the corresponding message explaining that that poll can only be voted by residents of a certain geozone.
This table will store which reports (stats, results, ...) will be shown
for a certain process (polls, budgets, ...).
Note Rails fails to save a poll and its report when both are new records
if we add a `validate :process, presence: true` rule. Since it caused a
lot of trouble when creating records for tests during factories rule
completely. Instead, I've created the `results_enabled=` and
`stats_enabled=` methods, so tests are easier to set up, while also
automatically creating a report if it doesn't already exist. This also
decouples form structure and database implemenation.
Originally I named this table `enabled_reports` and instead of having
`stats` and `results` columns, it had an `enabled` column and a `kind`
column, which would be set to "stats" or "results". However, although
that table would allow us to add arbitrary reports easily, I found the
way we had to handle the `has_many` relationship was a bit too complex.
