Signals used by django-registration¶
Much of django-registration’s customizability comes through the ability to write and use different workflows for user registration. However, there are many cases where only a small bit of additional logic needs to be injected into the registration process, and writing a custom workflow to support this represents an unnecessary amount of work. A more lightweight customization option is provided through two custom signals which the built-in registration workflows send, and custom workflows are encouraged to send, at specific points during the registration process; functions listening for these signals can then add whatever logic is needed.
For general documentation on signals and the Django dispatcher, consult Django’s signals documentation. This documentation assumes that you are familiar with how signals work and the process of writing and connecting functions which will listen for signals.
Sent when a user account is activated (not applicable to all workflows). Provides the following arguments:
ActivationViewsubclass used to activate the user.
- A user-model instance representing the activated account.
HttpRequestin which the account was activated.
This signal is automatically sent for you by the base
ActivationView, so unless you’ve overridden its
get()method in a subclass you should not need to explicitly send it.
Sent when a new user account is registered. Provides the following arguments:
RegistrationViewsubclass used to register the account.
- A user-model instance representing the new account.
HttpRequestin which the new account was registered.
This signal is not automatically sent for you by the base
RegistrationView. It is sent by the subclasses implemented for the three included registration workflows, but if you write your own subclass of
RegistrationView, you’ll need to send this signal as part of the implementation of the