Commit 2ab6dfac authored by Samuel GAIST's avatar Samuel GAIST
Browse files

[ui][registration][docs] Pre-commit cleanup

parent e00b840f
......@@ -32,7 +32,7 @@ so. This model's sole purpose is to store data temporarily during
account registration and activation, and a mechanism for automatically
creating an instance of a site-specific profile model is provided via
the ``create_inactive_user`` on ``RegistrationManager``.
``RegistrationProfile`` objects have the following fields:
......@@ -47,15 +47,15 @@ the ``create_inactive_user`` on ``RegistrationManager``.
Determines whether this ``RegistrationProfile``'s activation key
has expired.
Returns ``True`` if the key has expired, ``False`` otherwise.
Key expiration is determined by a two-step process:
1. If the user has already activated, the key will have been reset
to the string constant ``ACTIVATED``. Re-activating is not
permitted, and so this method returns ``True`` in this case.
2. Otherwise, the date the user signed up is incremented by the
number of days specified in the setting
``ACCOUNT_ACTIVATION_DAYS`` (which should be the number of days
......@@ -68,25 +68,25 @@ The ``RegistrationManager``
Custom manager for the ``RegistrationProfile`` model.
The methods defined here provide shortcuts for account creation and
activation (including generation and emailing of activation keys), and
for cleaning out expired inactive accounts.
Validate an activation key and activate the corresponding
``User`` if valid.
If the key is valid and has not expired, return the ``User``
after activating.
If the key is not valid or has expired, return ``False``.
If the key is valid but the ``User`` is already active,
return ``False``.
To prevent reactivation of an account which has been
deactivated by site administrators, the activation key is
reset to the string constant ``RegistrationProfile.ACTIVATED``
......@@ -102,7 +102,7 @@ Methods:
Create a new, inactive ``User``, generate a
``RegistrationProfile`` and email its activation key to the
``User``, returning the new ``User``.
To disable the email, call with ``send_email=False``.
The activation email will make use of two templates:
......@@ -133,11 +133,11 @@ Methods:
argument ``user``) after the ``User`` and
``RegistrationProfile`` have been created, and after the email (if
any) has been sent.
Creates a ``RegistrationProfile`` for a given ``User``. Returns
the ``RegistrationProfile``.
The activation key for the ``RegistrationProfile`` will be a SHA1
hash, generated from a combination of the ``User``'s username and
a random salt.
......@@ -145,34 +145,34 @@ Methods:
Removes expired instances of ``RegistrationProfile`` and their
associated ``User`` objects.
Accounts to be deleted are identified by searching for instances
of ``RegistrationProfile`` with expired activation keys, and then
checking to see if their associated ``User`` instances have the
field ``is_active`` set to ``False``; any ``User`` who is both
inactive and has an expired activation key will be deleted.
It is recommended that this method be executed regularly as part
of your routine site maintenance; this application provides a
custom management command which will call this method, accessible
as `` cleanupregistration``.
Regularly clearing out accounts which have never been activated
serves two useful purposes:
1. It alleviates the ocasional need to reset a
``RegistrationProfile`` and/or re-send an activation email when
a user does not receive or does not act upon the initial
activation email; since the account will be deleted, the user
will be able to simply re-register and receive a new activation
2. It prevents the possibility of a malicious user registering one
or more accounts and never activating them (thus denying the
use of those usernames to anyone else); since those accounts
will be deleted, the usernames will become available for use
If you have a troublesome ``User`` and wish to disable their
account while keeping it in the database, simply delete the
associated ``RegistrationProfile``; an inactive ``User`` which
......@@ -127,7 +127,7 @@ need to do the following:
for details).
4. Add this line to your site's root URLConf::
(r'^accounts/', include('registration.urls')),
5. Link people to ``/accounts/register/`` so they can start signing
......@@ -23,7 +23,7 @@ change this, pass the name of a template as the keyword argument
The activation key to validate and use for activating the
**Optional arguments**
......@@ -40,7 +40,7 @@ change this, pass the name of a template as the keyword argument
The ``User`` object corresponding to the account, if the
activation was successful. ``False`` if the activation was not
The number of days for which activation keys stay valid after
......@@ -49,7 +49,7 @@ Any extra variables supplied in the ``extra_context`` argument (see
registration/activate.html or ``template_name`` keyword argument.
......@@ -57,14 +57,14 @@ registration/activate.html or ``template_name`` keyword argument.
Allow a new user to register an account.
Following successful registration, issue a redirect; by default, this
will be whatever URL corresponds to the named URL pattern
``registration_complete``, which will be
``/accounts/register/complete/`` if using the included URLConf. To
change this, point that named pattern at another URL, or pass your
preferred URL as the keyword argument ``success_url``.
By default, ``registration.forms.RegistrationForm`` will be used as
the registration form; to change this, pass a different form class as
the ``form_class`` keyword argument. The form class you specify must
......@@ -98,7 +98,7 @@ None.
The registration form.
Any extra variables supplied in the ``extra_context`` argument (see
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment