Until we correctly make MapLocation relation with mappables a polymorphic
one... we'll need to return the investment_id and proposal_id values.
Right now it was returning the MapLocation ID, and the JS was making a
call searching for an Investment with the MapLocation ID... sometimes
finding a record with same ID but totally NOT the one associated to the
MapLocation.
The csv generation doesn't seem like a Model concern, at least not taking
into account the amount of lines of the method (36+). Just a simple ruby
class that encapsulates the logic makes it easier to read and maintain as
we increase the columns exported.. also customize in case other forks need
different values.
There's no good reason to call assigned_valuators(investment) when the
logic can be at the model.
Also removed the valuator_groups texts to be added in an independent
method
Why:
Heading filter where not being correctly displayed
How:
Increasing scenario to cover all possible combinations, and fixing the
heading_filters method of the Valuation Budget Investment Controller to
correctly:
* Find how many investments the valuator can access
* Count investments for each heading
Why:
ValuatorGroup name should be unique and present to be able to identify
correctly each of them.
How:
- Adding a presence & uniqueness validation at the model
- Adding a sequenced value for name attribute at its factory
- Adding missing model spec that covers validations
When there are no budgets we were seeing an exception in the budgets’
index
There are two parts to take into account here:
1) Making sure there is a current_budget present, otherwise we display
the “no budgets” message
2) The map helper is called from the controller, so we need to make
sure current_budget is present there too
Note: We could have added a bunch of `try` statements in the budgets’s
index, instead of using a conditional, however there are quite a few
`current_budget` calls so it seems more appropriate to use a conditional
Date.new(...) does not take into account the current timezone, while other
parts of the application do. By default always parsing any date with the
default timezone and converting the resulting Time to Date would prevent
this kind of issues
DateTime.parse(...).in_time_zone gives an unexpected result, as the
DateTime.parse(...) will create a DateTime with +0000 time zone and the
`in_time_zone` will modify the DateTime to adjust to the default zone.
Maybe its better explained with an example, using 'Lima' as timezone:
DateTime.parse("2015-01-01")
> Thu, 01 Jan 2015 00:00:00 +0000
DateTime.parse("2015-01-01").in_time_zone
> Wed, 31 Dec 2014 19:00:00 -05 -05:00
And that's not the desired date but the previous day!
Not sure how this error creeped in 😕 probably a new gem version or
other conflicting code
The problem was we were getting an `unpermitted param email` when
updating a user’s email address
This stackoverflow solution seems to work nicely 😌https://stackoverflow.com/questions/17384289/unpermitted-parameters-addi
ng-new-fields-to-devise-in-rails-4-0#answer-19036427
The back button when the user changes the password
(in the print password page) redirects to the
edit manually page.
The routes to access password edit pages has been added,
along with the ones to send reset password email and
reset password manually.
A submenu has been added to the side menu's
'Edit user account' option. This submenu has
two options:
- Reset password via email: an email is send
so that the user can change their password by
themselves.
- Reset password manually: the manager has to
write the password manually (or generate a random
one).
The passwords generated by the random password
generator don't contain characters like $ or !.
It uses some capital letters, some other lower
case letters and some numbers. Ambiguous
characters like 1, l, I has been removed.
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
