Using arrays made it difficult to order by more than one field (like the
`most_voted` scope does), and so we were ordering by `confidence_score`
and ignoring the `created_at` column.
Using an AR relation makes it easy to reuse the existing `most_voted`
scope.
This change has one side effect: now comments with equal votes are
ordered in descending order instead of having no specific order. That
means flaky specs which failed sometimes because they assumed comments
were ordered by date are now always green.
I've also re-added the `oldest` scope removed in 792b15b thinking it was
removed because using it with arrays was too hard.
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.
Even if this class looks very simple now, we're trying a few things
related to these stats. Having a class for it makes future changes
easier and, if there weren't any future changes, at least it makes
current experiments easier.
Note we keep the method `participants_by_geozone` to return a hash
because we're caching the stats and storing GeozoneStats objects would
need a lot more memory and we would get an error.
These tasks dealt with data migrations or stats generations which were
done only once, so we don't need them anymore.
New CONSUL installations don't need these tasks, and existing CONSUL
installations will execute them when upgrading one release at a time.
Execute rake task every day to detect new actions available for not archived proposals. If there are new actions available for today, send email to proposal's author with information text, new actions available and link to proposal dashboard url.
From now on these static pages:
`/privacy'
`/conditions'
`/accesibility'
`/help/faq'
`/welcome'
have been moved to the DB and can be modified easily by any
administrator in `/admin/site_customization/pages'
The list of emails for sending newsletters will always be ordered by
user creation date, so it will be easier to debug and to know for
which users the email has been sent.
When we insert a record in PostgreSQL and we specify the ID, the
internal ID sequence for that table isn't updated.
In order to keep the original IDs so we didn't break any foreign keys,
we specified the IDs when copying the table, resulting in a table having
its ID sequence with a value of an existing record. When trying to
insert a new record, we got a `PG::UniqueViolation` exception.
Updating the sequence after the data migration might not be the most
elegant solution, but it's easy to do and it's already been tested on a
production environment.
