Since Globalize gem update to v5.2.0 we cannot override translations
anymore in the same way that before the update. Milestone::Translation
class removed in this commit were no longer loaded correctly when
translation class is retrieved by translation_class method provided by
Globalize. Here is the diff between both gem versions:
https://github.com/globalize/globalize/compare/v5.0.0...v5.2.0#diff-a1370b109e0dd567545b072bc6447b8fR51
This problem is not happening on test environment but is throwing an
exception in other environments as it has not loaded the delegation
definition inside our custom translation class.
To fix this we added a new class method inside globalizable model
concern to allow to define method delegation on translations classes from
parent globalizable classes when needed without having to override
Translation classes.
Another way to properly load our custom Milestone::Translation class is
to place it inside parent model class, like the example below:
class Milestone
...
class Translation
delegate :status_id, to: :globalized_model
end
end
Or maybe monkey patching translation_class method from globalize gem
to make it find our custom translation class. I don't like this option.
DEPRECATION WARNING: uniq is deprecated and will be removed from Rails
5.1 (use distinct instead) (called from block in <class:User> at
/home/travis/build/consul/consul/app/models/user.rb:67)
This section is used to select to which poll a question belongs to.
Budget polls are not meant to include questions that come from Citizen
Proposals or Government Questions, thus we do not display them
The order of the array before being shuffled needs to be the same if we
want to have the same array after being shuffled with a certain seed.
We were using `pluck(:id)`, which doesn't guarantee the order of the
elements returned.
Replacing it with `order(:id).pluck(:id)` adds an `ORDER BY` clause and
so guarantees the order of the elements.
This way we can easily add a test which will fail if by accident we
change the method to use `Date.today`. Until now using `Date.today`
would only fail if we ran specs in a time zone with a different date.
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.
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.
