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.
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.
Running test suite the following appears: DEPRECATION WARNING: Defining
a route where `to` is a symbol is deprecated. Please change
`to: :json_data` to `action: :json_data`.
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
