1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
.. _signals:
.. module:: django_registration.signals
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
<http://docs.djangoproject.com/en/stable/topics/signals/>`_. This
documentation assumes that you are familiar with how signals work and
the process of writing and connecting functions which will listen for
signals.
.. data:: user_activated
Sent when a user account is activated (not applicable to all
workflows). Provides the following arguments:
`sender`
The :class:`~django_registration.views.ActivationView` subclass used
to activate the user.
`user`
A user-model instance representing the activated account.
`request`
The :class:`~django.http.HttpRequest` in which the account was
activated.
This signal is automatically sent for you by the base
:class:`~django_registration.views.ActivationView`, so unless
you've overridden its
:meth:`~django.views.generic.base.TemplateView.get` method in a
subclass you should not need to explicitly send it.
.. data:: user_registered
Sent when a new user account is registered. Provides the following
arguments:
`sender`
The :class:`~django_registration.views.RegistrationView` subclass used
to register the account.
`user`
A user-model instance representing the new account.
`request`
The :class:`~django.http.HttpRequest` in which the new account
was registered.
This signal is **not** automatically sent for you by the base
:class:`~django_registration.views.RegistrationView`. It is sent by
the subclasses implemented for the three included registration
workflows, but if you write your own subclass of
:class:`~django_registration.views.RegistrationView`, you'll need
to send this signal as part of the implementation of the
:meth:`~django_registration.views.RegistrationView.register`
method.
|
