We could always generate a confirmation token but not sending a
confirmation email by invoking the skip_confirmation_notification!
method when creating the account.
But there were no way to do that when we were turning on reconfirmable
and updating email.
At times, validations may be skipped and no email address may be
provided. Such an instance comes when testing uniqueness validations of
specific attributes in a Devise model with confirmable, especially when
using Shoulda matchers.
* Rename #get_constraints_given_method to #constraints_for to make the
method clear.
* The method name now is required.
* Use symbols instead of strings.
* Make #constraints_for a protected method.
This updates Devise's StrongParameter support to feature:
- A Null base sanitizer to support existing Rails 3.x installations that
don't want to use StrongParameters yet
- A new, simpler API for ParameterSanitizer: #permit, #permit!, and #forbid
- Overrideable callbacks on a controller-basis, e.g. #create_sessions_params
for passing the current scope's parameters through StrongParameters and
a helper method, whitelisted_params, for rolling your own implementations
of #create_x_params in your own controllers.
- Lots of tests!
This brings support for Rails 4 StrongParameters changes.
- Parameter sanitizing is setup for Devise controllers via
resource_params except Omniauth Callbacks which doesn't use
resource_params.
- Change #build_resource to not call resource_params for get requests.
Parameter sanitizing is only needed when params are posted to the
server so there's no need to try to construct resource params on get
requests (new, edit).
There are a couple of gotchas in the existing documentation
about the `send_devise_notification` hook.
1. The `after_commit` callback can be called multiple times
so you should clear the array otherwise any additional
invocations will trigger extra copies of the email.
2. The `after_commit` callback is only called when a record
is created or updated so you need to check for `new_record?`
or `changed?` before adding it to `pending_notifications`
otherwise it's okay to send it immediately.
The `new_record? || changed?` condition is necessary because
the latter isn't always true for new records, e.g:
>> User.new.changed?
=> false
[ci skip]
