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.
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`.
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
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.
Why:
A Newsletter can only be sent if the are available user recipient emails
and that means the `segment_recipient` value actually corresponds to a
function on the UserSegments class.
We could rely on the UserSegments::SEGMENTS constant as the list of
possible user segments functions that a Newsletter can use to gather
emails, so any value not included in that hash would not be valid.
But to be 100% sure the newsletter can get a recipients_list we should
just check if the UserSegments class has a method with same name as the
`segment_recipient` value.
How:
* Adding an validation method that checks if UserSegment has a method
with same name as the `segment_recipient` value.
* Adding an scenario to the Newsletter model spec to check this
