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
Create a new Budget::Phase model that:
* Stablishes a relation with its budget
* Stablishes relation with two other Budget::Phases (previous and next)
* Validates basic dates range, kind and description rules.
* Adds scopes to get the ones enabled as well as each individual phase
Create a factory that generates a basic and valid Budget::Phase
Create a model spec that checks kind, date range and budget validations.
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
As we are using an attr_accessor to make sure a user accepts that the
proposal “has no map”, the validation was being run in every save.
Making other things break, for example the updating of the counter
cache `cached_votes_up`, when someone voted for the proposal, as the
attr_accessor `skip_map` was not present
When editing the map of a proposal or investment(the mappable) the
updated_at attribute of the mappable was not been updated and so the
map still displayed the old location after updating it
