Some fields from Budget::Heading are translatable and we no longer need them. This commit will remove the annoying deprecation warning thrown by Globalize gem after gem version update.
Some fields from Budget::Group are translatable and we no longer need them. This commit will remove the annoying deprecation warning thrown by Globalize gem after gem version update.
Some fields from Budget are translatable and we no longer need them. This commit will remove the annoying deprecation warning thrown by Globalize gem after gem version update.
Some fields from Widget::Card are translatable and we no longer need
them. This commit will remove the annoying deprecation warning thrown
by Globalize gem after gem version update.
Some fields from SiteCustomization::page are translatable and we no
longer need them. This commit will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
Some fields from Legislation::Question::Option are translatable and we
no longer need them. This commit will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
Some fields from Legislation::Question are translatable and we no
longer need them. This commit will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
Some fields from Legislation::Process are translatable and we no longer
need them. This commit will remove the annoying deprecation warning
thrown by Globalize gem after gem version update.
Some fields from LegislationDraftVersion are translatable and we no
longer need them. This commit will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
Some fields from Milestone are translatable and we no longer need them.
This commit will remove the annoying deprecation warning thrown by
Globalize gem after gem version update.
Some fields from AdminNotification are translatable and we no longer
need them. This commit will remove the annoying deprecation warning
thrown by Globalize gem after gem version update.
Some fields from Poll::Question::Answer are translatable and we no
longer need them. This commit will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
Some fields from Poll::Question are translatable and we no longer need
them. This commit will remove the annoying deprecation warning thrown
by Globalize gem after gem version update.
Some fields from Poll are translatable and we no longer need them. This
commit will remove the annoying deprecation warning thrown by Globalize
gem after gem version update.
Some attributes from Banner are translatable and we no longer need to
have them at database table. This will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
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.
We need a way to manually expire the cache for a budget or poll without
expiring the cache of every budget or poll.
Using the `updated_at` column would be dangerous because most of the
times we update a budget or a poll, we don't need to regenerate their
stats.
We've considered adding a `stats_updated_at` column to each of these
tables. However, in that case we would also need to add a similar column
in the future to every process type whose stats we want to generate.
