Commits

James Bennett committed b1f96e4

More documentation updates.

Comments (0)

Files changed (3)

docs/default-backend.rst

 registers, then confirms and activates the new account by following a
 link sent to the email address supplied during registration.
 
+
+Default behavior and configuration
+----------------------------------
+
 This backend makes use of the following settings:
 
 ``ACCOUNT_ACTIVATION_DAYS``
 overridden by passing the keyword argument ``success_url`` to the
 :func:`~registration.views.register` view.
 
+
+How account data is stored for activation
+-----------------------------------------
+
 During registration, a new user account is created, with the
 ``is_active`` field set to ``False``. An email is then sent to the
 email address of the account, containing a link the user must click to
       Returns the ``User`` instance representing the account if
       activation is successful, ``False`` otherwise.
 
+      :param activation_key: The activation key to use for the
+         activation (a SHA1 hash as a forty-character hexadecimal
+         digest).
+
    .. method:: delete_expired_users
 
       Removes expired instances of :class:`RegistrationProfile`, and
       their associated user accounts, from the database. This is
-      useful as a periodic maintenance task to clean out account which
-      registered by never activated.
+      useful as a periodic maintenance task to clean out accounts
+      which registered but never activated.
 
       Accounts to be deleted are identified by searching for instances
       of :class:`RegistrationProfile` with expired activation keys and

docs/quickstart.rst

 
 There are several ways to install django-registration:
 
-* Automatically, via a Python package installer.
+* Automatically, via a package manager.
 
 * Manually, by downloading a copy of the release package and
   installing it yourself.
 
     hg clone http://bitbucket.org/ubernostrum/django-registration/
 
-This will create a copy of the django-registration Mercurial
-repository on your computer; you can then add the
+You can also obtain a copy of a particular release of
+django-registration by specifying the ``-r`` argument to ``hg clone``;
+each release is given a tag of the form ``vX.Y``, where "X.Y" is the
+release number. So, for example, to check out a copy of the 0.8
+release, type::
+
+    hg clone -r v0.8 http://bitbucket.org/ubernostrum/django-registration/
+
+In either case, this will create a copy of the django-registration
+Mercurial repository on your computer; you can then add the
 ``django-registration`` directory inside the checkout your Python
 import path, or use the ``setup.py`` script to install as a package.
 
 Setting up URLs
 ~~~~~~~~~~~~~~~
 
-The default backend includes a Django ``URLConf`` which sets up URL
-patterns for :ref:`the views in django-registration <views>`, as well
-as several useful views in ``django.contrib.auth`` (e.g., login,
-logout, password change/reset). This ``URLConf`` can be found at
+The :ref:`default backend <default-backend>` includes a Django
+``URLConf`` which sets up URL patterns for :ref:`the views in
+django-registration <views>`, as well as several useful views in
+``django.contrib.auth`` (e.g., login, logout, password
+change/reset). This ``URLConf`` can be found at
 ``registration.backends.default.urls``, and so can simply be included
 in your project's root URL configuration. For example, to place the
 URLs under the prefix ``/accounts/``, you could add the following to
 custom backend, or by connecting listeners to :ref:`the signals sent
 during the registration process <signals>`.
 
-Changes to the ``RegistrationProfile`` model
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Changes to the :class:`~registration.models.RegistrationProfile` model
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-``RegistrationProfile.objects.create_inactive_user()`` now
-has an additional required argument: ``site``. This allows
+The
+:meth:`~registration.models.RegistrationManager.create_inactive_user`
+method of :class:`~registration.models.RegistrationManager` now has an
+additional required argument: ``site``. This allows
 django-registration to easily be used regardless of whether
 ``django.contrib.sites`` is installed, since a ``RequestSite`` object
 can be passed in place of a regular ``Site`` object.
 
 The :data:`~registration.signals.user_registered` signal is no longer
-sent by ``RegistrationProfile.objects.create_inactive_user()``, and
-the :data:`~registration.signals.user_activated` signal is no longer
-sent by ``RegistrationProfile.objects.activate_user()``; these signals
-are now sent by the backend after these methods have been called.
+sent by
+:meth:`~registration.models.RegistrationManager.create_inactive_user`,
+and the :data:`~registration.signals.user_activated` signal is no
+longer sent by
+:meth:`~registration.models.RegistrationManager.activate_user`; these
+signals are now sent by the backend after these methods have been
+called.
 
 The sending of activation emails has been factored out of
-``RegistrationProfile.objects.create_inactive_user()``, and now exists
-as the method ``send_activation_email()`` on instances of
-``RegistrationProfile``.
+:meth:`~registration.models.RegistrationManager.create_inactive_user`,
+and now exists as the method
+:meth:`~registration.models.RegistrationProfile.send_activation_email`
+on instances of :class:`~registration.models.RegistrationProfile`.