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.
