This method is already existent in the application_controller but it
seems a little overkill to create a concern just for this method
Maybe when we have multiple method it makes sense to create a nice
controller. Another option would be to make the
management_base_controller extend from the application_controller
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.
This spec used to pass, because even though there were no budgets, as
Budget.current returned an array, it gracefully handled situations
without budgets
Now we assume that there can only be a single current budget, and so
calling any method of budget will raise an exception unless there is a
current budget present
Valuators should not access this page when there is no budget present,
however it might be wise to create an issue to cover this case, just in
case
Before we could have multiple current budgets, as we now only have one
current_budget, some specs broke.
As there is no need to display multiple budgets to Valuators, only the
current budget is necessary, we can remove arrays and assume that only
a single budget, the current budget, is displayed to Valuators
In the specs, some investment were missing a heading_id, thus creating
another unexpected budget
By explicitly setting the heading_id we can control better which
budgets are created in each test
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
