django-registration / docs / release-notes.rst

Release notes

The |version| release of django-registration represents a complete rewrite of the previous codebase, and as such introduces a number of new features and greatly enhances the flexibility and customizability of django-registration. This document summarizes those features; for a list of changes which impact existing installations, consult :ref:`the upgrade guide <upgrade>`.

The backend system

The largest overall change consists of factoring out the logic of user registration into pluggable/swappable backend classes. The :ref:`registration views <views>` now accept a (required) argument, backend, which indicates the backend class to use, and that class has full control over the registration (and, if needed, activation) process, including:

  • Determining whether registration will be allowed at all, on a per-request basis.
  • Specifying a form class to use for account registration.
  • Implementing the actual process of account creation.
  • Determining whether a separate activation step is needed, and if so what it will entail.
  • Specifying actions to take (e.g., redirects, automatic login, etc.) following successful registration or activation.

For full details, see the documentation for :ref:`the backend API <backend-api>`.

The workflow used by previous releases of django-registration (two-step registration/activation) has been implemented using this system, and is shipped as :ref:`the default backend <default-backend>` in django-registration |version|.

Other new features

An alternate :ref:`one-step registration system <simple-backend>` is provided, for use by sites which do not require a two-step registration/activation system.

During the registration and (optional) activation process, :ref:`custom signals <signals>` are now sent, allowing easy injection of custom processing into the registration workflow without needing to write a full backend.

The default backend now supplies several custom admin actions to make the process of administering a site with django-registration simpler.

The :func:`~registration.views.activate` view now supplies any captured keyword arguments from the URL (in the case of the default backend, this is the activation key) to its template in case of unsuccessful activation; this greatly simplifies the process of determining why activation failed and displaying appropriate error messages.

Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.