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.
These tests were failing randomly because there is no guarantee
the methods `Budget#email_selected` and `Budget#email_unselected` will
always send the emails in the same order, because `investments.selected`
and `investments.unselected` don't necessarily return the records in the
order they were created.
Ordering by id is certainly not very elegant; however, ordering by
another field like `created_at` is dangerous because the record could be
created at (almost) the exact same time.
Related to issue #2446 and issue #2519.
This is a preventive change which will be useful once the rake to
migrate from `spending_proposals` to `budget_investments` is complete
As after running that migration, old `spending_proposal` budgets will
have a newer `id` than the existing budgets. And therefore the last
budget will be one of those migrated from the old `spending_proposal`
model
By ordering by `created_at` and probably updating the `created_at`
attribute in the rake that migrates `spending_proposals` to
`budget_investments`, we will have a coherent order for budgets
Before Budget.current could return multiple budgets, now there can only
be a single current_budget.
Adding the concept of open, which better reflects what the admin sees
in this page: A tab for open budgets and a tab for finished budgets
When there was only one budget this implementation worked fine
Nowadays there can be multiple budgets, and therefore the definition of
the current_budget has changed. It is no longer a budget that has not
finished, but rather, the last budget created that is not in the
initial drafting phase.
Budgets in the drafting phase are not considered the current_budget,
but rather a budget that is still being prepared and that soon will
become the current_budget
* What: We need to generate slug on Budget, Group and Heading classes, validating its unique for its scope
* How: Adding a presence and unique validation using Budget always as scope.
