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
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.
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.
If there's demographic data for all participants, it doesn't make sense
to show the message.
We're using translations instead of an `if` in the view because the text
is also different when there's only one participant. In some languages
the text might also be different depending on how many people with no
demographic data participated.
Another possibility would be to use an `if` in the view so we don't
display an empty paragraph when the cont is zero, and then using
translation for `one` and `other`. I haven't gone that way because I
thought the logic would be more complex and the benefits wouldn't be
that great.
So if we don't have information regarding gender, age or geozone, stats
regarding those topics will not be shown.
Note we're using `spec/models/statisticable_spec.rb` because having the
same file in `spec/models/concerns` caused the tests to be executed
twice.
Also note the implementation behind the `gender?`, `age?` and `geozone?`
methods is a bit primitive. We might need to make it more robust in the
future.
It will make it far easier to call other methods on the stats object,
and we're already caching the methods.
We had to remove the view fragment caching because the stats object
isn't as easy to cache. The good thing about it is the view will
automatically be updated when we change logic regarding which stats to
show, and the methods taking long to execute are cached in the model.
For now we think showing them would be showing too much data and it
would be a bit confusing.
I've been tempted to just remove the view and keep the methods in the
model in case they're used by other institutions using CONSUL. However,
it's probably better to wait until we're asked to re-implement them, and
in the meantime we don't maintain code nobody uses. The code wasn't that
great to start with (I know it because I wrote it).
