During the backport for “Read Notifications”[1] this link was added,
which belongs to a different backport “Budget Recommendations” which is
not quite ready to bring to upstream, yet 😌
[1] https://github.com/AyuntamientoMadrid/consul/pull/1304
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
There was some inconsistency in this file, the `confirm_group` key was
in both the custom translations file and the default translations file.
Remove duplication and make it a default as it is a clearer message for
users. If an installation want to edit this message they can still do
it in the custom translations file
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
Changing a group’s `to_param` to return the slug instead of the id,
breaks many tests in the user facing interface
We should use slugs in upstream soon, but it should be done in a
separate PR, bringing the whole slug implementation from Madrid’s fork
and the corresponding test coverage
To maintain order after editing a heading’s name
We should probably add timestamps to `groups` and `headings` and order
by `created_at` instead
Could have done it in a separate PR, but gotta keep moving to other
priority issues. Creating issue for timestamps to do correctly and with
tests 😌
We were having a problem were some groups where not updating correctly.
That was because it was finding the first group with that name. However
we were looking for another group with the same name from another budget
Apart from the group_id, we also get the budget_id in the params for
updating a group. By finding groups within that budget we get the
expected behaviour
The old method have_css didn't wait, apparently,
the Capybara's max_wait_time.
It has been changed in favor of find,
one that waits the stablished time for
an element to appear in the screen.
Budget Investment factory creates a secondary budget as a collateral
effect because it has a Heading factory that has a Group factory that
creates a Budget.
This was resulting in problems due to having two "active" Budgets created
and `current_budget` method not choosing the one that we expected
When a valuator tries to edit/valuate an investment outside valuating
phase, an explanatory message will be shown along with a redirect to
prevent access.
