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 tests that will check the featute
is working well added. There are four test:
1. Checks that the emails are been send to
the user. The test looks for the link in there
and takes the token. Visits the page and
changes the password.
2 and 3. Both change the password by hand. One
uses a password written by the manager, whilst
the other uses the 'Generate random password'
option. Both tests check that the user can
sign in with the new passwords.
4. Checks that the password can be printed
when it is saved.
The example tests if a certain selector is hidden after adding
one image but the assertion expected said selector to be visible,
which made the scenario to fail at random
The now-deprecated `.trigger('click')` API simulated a click against
the DOM rather a click on the UI, which made our tests fragile and
wouldn't simulate actual user interaction
Advanced search scenarios for Budget::Investments, Debates and
Proposals need proper date formatting as they behave unexpectedly
when APIs such as `7.days.ago` are used
JS modals/browser alerts are not automatically accepted now with
Selenium, events that trigger such events must be wrapped in one
of the following methods: `accept_alert`, `accept_confirm` or
`dismiss_confirm`
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
