Avoid to raise an exception `Module::DelegationError' when trying to
show the name and/or email of a poll officer whose user account has
been deleted.
We'll show a message "User deleted" and "Email deleted" instead.
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.
Settings are displayed in the administration in the order they are
created, and reordering them alphabetically in the code caused them to
be displayed in a different order.
Since we don't want to confuse our users by randomly changing the order,
I've grouped the settings by namespaces and ordered each namespace the
way it used to be.
Note dev seeds don't need to be changed, since they are executed after
default settings have been created.
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
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.
