Otherwise we'd be mistakenly displaying the original email in the
message (which is the same we're sending the message to).
Also tweak the messaging a bit in this case, to show that the email "is
being changed" (the change hasn't taken effect yet).
Related to #4455.
This better indicates what the setting is for, and when it's supposed to
be triggered.
We might eventually deprecate the existing password_change on in favor
of password_changed.
This adds a new setting `send_email_change_notification` which will
send an email to the original user email when their email is updated to
a new one.
It doesn't take into account the reconfirmable setting yet, it will be
added next, so that if confirmable is included and reconfirmable is
being used, the email will be triggered when the email change is
requested, not when confirmed (e.g when we store the email in
`unconfirmed_email`, not when it's later copied to `email` when that is
confirmed).
This change add warnings for these configurations:
* strip_whitespace_keys - It is already explicit on config template, now
it will be the same of the template.
* email_regexp - In the new version this regexp will be more
permissive.
* reconfirmable - It is already explicit on config template, now
it will be the same of the template.
* skip_session_storage - It is already explicit on config template, now
it will be the same of the template.
* sign_out_via - It is already explicit on config template, now
it will be the same of the template.
These ones is important to change, since the configuration says current
explicit value are the default. It can lead to misunderstanging if users
remove the explicit configuration.
It also updates the template explicit values:
* Warns the `config.mailer_sender` is nil by default
* Update `config.password_length` to use the current default
* Make the e-mail configuration explicit
Rails 5 deprecates inheriting directly from `ActiveRecord::Migration` in
favor of inheriting from `ActiveRecord::Migration[5.0]` where `5.0` is
the `major.minor` version of Rails that the migration was originally
written to support.
h/t to b0ce189c69.
* Expand the explanation of why it fail.
* Raise a subclass of `Thor::Error` so the Thor doesn't output the exception
backtrace as it isn't useful for developers facing this error.
Throughout the documentations, we are using 'encrypt' incorrectly.
Encrypt means that someone will eventually decrypt the message,
which is obviously not the case for Devise.
I'm changing the docs to use 'hashing' instead.
However, I left the database field as `encrypted_password` for now.
I'll update the db field in an upcoming PR.
Devise::ParameterSanitizer has a new syntax for permitting additional
attributes to a model. This commit updates the generated controllers to
reflect that.
Our Simple Form generator shouldn't be responsible for generating the `mailer`
view directory, so we should skip it and let the Erb generator do the job.
Closes#3254.
There's no real need to pass 2 variables to the view to figure that out,
we can simply display the message relying on whether or not the
`@minimum_password_length` variable is present.
BCrypt has a limit of 72 characters for the password. Anything beyond 72
characters is truncated. This commit updates the validation to limit
passwords to less than 72 characters, keeping within the limitation.
