Some queries were accessing original column instead of the new translatable one. This should have been causing unexpected behavior for requests maded in a different locale than the application default.
Some queries were accessing original column instead of the new
translatable one. This should have been causing unexpected behavior
for requests maded in a different locale than the application default.
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.0diff-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.
Since module Sanitizable takes care of traslations, it's enough to
include the module in order to correctly sanitize the description.
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.0diff-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.
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.0diff-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.
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.0diff-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 Translation class is
to place it inside parent model class.
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.
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.
