The user was able to vote as many investments as wanted in the first
heading voted. However in the second heading voted, only one investment
could be voted
This was due to the previous implementation, where you could only vote
in one heading. Note the `first` call in method
`heading_voted_by_user?(user)`
This commits simplifies the logic and allows voting for any investment
in any heading that the user has previously voted in
This method was used only in Madrid’s fork, but it is now needed to
complete the backport for voting in multiple headings
There wasn’t a test in Madrid, so here goes one too. Even though, the
responsibility should probably be moved soon to the `Budget::Heading`.
For consistency with the related methods and tests it has been left in
the investment_spec
Now that we have the option of voting in multiple headings per group,
the method of voting in a “different heading assigned” has become
deprecated and thus removed
Slugs should only be updated on certain conditions, we need a trait that
meets that conditions and the name of the trait passed as a mandatory &
named argument on the sluggable concern
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.
Cambios para hacer commit:
modificado: app/controllers/admin/budget_headings_controller.rb
modificado: app/models/budget/heading.rb
nuevo archivo: app/views/admin/budget_headings/_errors.html.erb
nuevo archivo: app/views/admin/budget_headings/edit.js.erb
nuevo archivo: app/views/admin/budget_headings/update.js.erb
modificado: app/views/admin/budgets/_group.html.erb
nuevo archivo: app/views/admin/budgets/_heading.html.erb
nuevo archivo: app/views/admin/budgets/_heading_form.html.erb
modificado: config/locales/en/activerecord.yml
modificado: config/locales/es/activerecord.yml
modificado: spec/features/admin/budgets_spec.rb
modificado: spec/models/budget/heading_spec.rb
Why:
* We should recalculate winners also when an incompatible investment is flagged as compatible again
How:
* Removing the condition to recalculate that was checking only for a winner investment flagged as incompatible
* Extending the Budget::Result model spec to cover that new scenario
Why:
* Slug must be unique among:
1. Budget slug: among other budgets
2. Group slug: among other groups from its budget
3. Heading slug: among other headings from all the groups from its budget
How:
* Adding checks for all possible scenarios on each model specs
Why:
* Those classes have a slug attribute that needs to be filled
How:
* Just adding the shared example to Budget model spec, and creating the model spec file for Heading and Group to include it as well
Why:
* A incompatible investment can't be chosen as a winner
* When a winner investment is marked as incompatible, winnersmust be recalculated and it can't be a winner
How:
* Increasing existing scenarios to include a incompatible investment
* Adding a new scenario where a winner investment gets flagged as incompatible