When introducing Rails 5 and the dashboard, we generated the schema file
without dropping the database first. When doing so locally, migrations
aren't always executed in order, changing the order of the columns.
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.
We have to doble check all emails deliveries from the dashboard.
Using a setting to skip all dashboard email deliveries for now.
Note that a rake task to activated the `Setting["dashboard.emails"]` will need to be addded when we want to activate deliveries of these emails.
spec/lib/tasks/dev_seed_spec.rb:8
This test was failing and we could see messages like:
db/dev_seeds/polls.rb:147:
warning: toplevel constant Answer referenced by Poll::Answer
Resulting in the error:
rake db:dev_seed seeds the database without errors
Failure/Error: expect { run_rake_task }.not_to raise_error
expected no Exception, got #<ActiveModel::UnknownAttributeError:
unknown attribute 'question_id' for Answer
Apparently the lookup was not correclty being performed, due to
conflicting names.
"Naming conflicts of this kind are rare in practice, but if one
occurs, require_dependency provides a solution by ensuring that
the constant needed to trigger the heuristic is defined in the
conflicting place."
https://guides.rubyonrails.org/v5.0/autoloading_and_reloading_constants.html
DEPRECATION WARNING: Directly inheriting from ActiveRecord::Migration
is deprecated. Please specify the Rails release the migration was
written for:
class MigrationClass < ActiveRecord::Migration[4.2]
(called from require at bin/rails:4)
This patch adds 2 missing colons (:) for 2 migrations that are failing when
the `rake db:migrate` task is ran. Whilst already-committed-to-source-control-
and-ran-on-production-environments migrations shouldn't be modified whatsoever,
this change does not modify in any way the current database schema so, technically,
it shouldn't affect forks that might have ran these migrations already and those
CONSUL installations that haven't done so should be able to without problems
DEPRECATION WARNING: #table_exists? currently checks both tables and
views. This behavior is deprecated and will be changed with Rails 5.1
to only check tables. Use #data_source_exists? instead.
