As mentioned in the Rails console:
DEPRECATION WARNING: Passing a class to the `class_name` is deprecated
and will raise an ArgumentError in Rails 5.2. It eagerloads more classes
than necessary and potentially creates circular dependencies. Please
pass the class name as a string.
Budget polls behave slightly differently to non-budget polls.
In budget polls we use Budget::Ballot::Lines to verify if a user has already voted online. In non-budget polls we use Poll::Voter to verify this.
In this commit we are adding an extra check to make sure that the correct message is displayed if the user has already voted online for a budget poll[1]
[1] https://github.com/AyuntamientoMadrid/consul/blob/master/spec/features/budget_polls/voter_spec.rb#L122
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.
DEPRECATION WARNING: Using positional arguments in functional tests
has been deprecated, in favor of keyword arguments, and will be
removed in Rails 5.1.
Deprecated style:
get :show, { id: 1 }, nil, { notice: "Flash message" }
New keyword style:
get :show, params: { id: 1 }, flash: { notice: "Flash message" }
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.
This code might be slightly slower because it performs one query per
field in the form, but I didn't notice any differences on my development
machine, and the code is now much easier to understand.
Due to technical issues, sometimes users voted in booths and their vote
couldn't be added to the database. So we're including them in the users
with no demographic data.
Using SQL's `select` instead of converting the records to a ruby array
increases performance dramatically when there are thousands of records.
For a poll with 200000 voters, calculating stats took more than 7
minutes, and now it takes less than 2 minutes.
We're generating stats every 2 hours because it's less than the time it
will take to generate stats for every process. Once stats are generated,
this task should take less than a second.
The regenerate task has been added so we can manually execute it.
