We need to add an ORDER BY clause; not doing so was causing different
processes to show up sometimes. As mentioned in the PostgreSQL manual:
> Because the order of the rows in the database table is unpredictable,
> when you use the LIMIT clause, you should always use the ORDER BY
> clause to control the order of rows. If you don’t do so, you will get
> an unpredictable result set.
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.
Create new Dashboard::Action class method to detect new actions between yesterday and today for a proposal.
- Published proposal: Only detect new actions with "published_proposal" field eq true
- Draft proposal: Only detect new actions with "published_proposal" field eq false
When params[:budget_investment][:valuation_tag_list] was not present,
which is the case when updating an investment using the "mark as visible
to valuators" checkbox, we were removing all valuation tags.
Using a virtual attribute to assign the tags only if the parameter is
present simplifies the code in the controller and avoids the issue.
Using `setseed` and ordering by `RAND()` doesn't always return the same
results because, although the generated random numbers will always be
the same, PostgreSQL doesn't guarantee the order of the rows it will
apply those random numbers to, similar to the way it doesn't guarantee
an order when the `ORDER BY` clause isn't specified.
Using something like `reorder("legislation_proposals.id % #{seed}")`,
like we do in budget investments, is certainly more elegant but it makes
the test checking two users get different results fail sometimes, so
that approach might need some adjustments in order to make the results
more random.
So under the tab "without valuator" we don't show investments assigned
to a valuator group, just as expected by administrators.
There was a conflict while applying this commit to the CONSUL repo. I've
decided to re-introduce the test which was deleted in commit dddf026a,
which hadn't been deleted in AyuntamientoMadrid@192f1182.
The right syntax would have been:
`after_save :recalculate_heading_winners, if: :incompatible_changed?`
However, since the method `recalculate_heading_winners` already executes
the `if incompatible_changed?` condition, removing it keeps the intended
behaviour.
Show a flash message that it's not possible to delete booth shifts
when they have associated recounts or partial results. Before an
execption was raised.
