Use `autocomplete="new-password"` or `autocomplete="current-password"` to better signal to browsers and password managers how to handle the password fields.
This feature is especially useful for “change your password” and “new user” forms
Rails 5.1 has deprecated render :text, and HEAD requests on the
omniauth callbacks passthru method is causing errors because the render
:text is non-existant, and there's no template to fall back to.
Replacing :text with :plain, adds a content-type type of text/plain and
also returns the previous message.
render :plain was supported back in rails 4.1.0
http://api.rubyonrails.org/v4.1.0/classes/ActionView/Helpers/RenderingHelper.html#method-i-render
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).
The sign_in method permits the bypass option
that ignore the others options used. This behavior
has lead some users to a misconfusion what the
method really does.
This change deprecate the bypass option in favor
of a method that only does the sign in with bypass.
Closes#3981
Rails 5 will [not have `hide_action` any longer](https://github.com/rails/rails/pull/18371/files), as the Rails convention is to not expose private or protected methods as actions, thus obviating the need for `hide_action`.
Presumably, there is code inheriting from `DeviseController` that is
calling these helpers, so they cannot be private, so protected seems to
be the only way to get Devise working with Rails 5.
This should still keep the devise lookup in the case that a customed scope is not passed as option, but if instead the custom scope is passed, then the find_message method will use it.
This is kind of useful, if i don't want overwrite the devise locale, and use different locale files, but keeping still the fallback of my devise locale.
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.
