[Python-modules-commits] [python-django-registration] 06/13: Import python-django-registration_2.2.orig.tar.gz
Stephan Suerken
absurd at moszumanska.debian.org
Tue Nov 29 11:49:57 UTC 2016
This is an automated email from the git hooks/post-receive script.
absurd pushed a commit to branch master
in repository python-django-registration.
commit a3e514d8c57466d7c7b5463f3b1af78f3831d173
Author: Stephan Sürken <absurd at olurdix.de>
Date: Mon Nov 28 17:42:37 2016 +0000
Import python-django-registration_2.2.orig.tar.gz
---
PKG-INFO | 3 +-
README.rst | 2 +-
django_registration.egg-info/PKG-INFO | 3 +-
docs/conf.py | 6 +-
docs/custom-user.rst | 45 ++++----
docs/faq.rst | 58 +++++-----
docs/forms.rst | 18 +++-
docs/hmac.rst | 2 +-
docs/index.rst | 4 +-
docs/install.rst | 24 +++--
docs/model-workflow.rst | 32 +++---
docs/quickstart.rst | 16 +--
docs/settings.rst | 4 +-
docs/signals.rst | 2 +-
docs/simple-workflow.rst | 2 +-
docs/upgrade.rst | 42 +++++---
docs/validators.rst | 6 +-
docs/views.rst | 12 ++-
registration/__init__.py | 2 +-
registration/backends/hmac/__init__.py | 2 +-
registration/backends/model_activation/__init__.py | 2 +-
registration/backends/simple/__init__.py | 2 +-
registration/models.py | 10 +-
registration/runtests.py | 18 +++-
registration/tests/base.py | 117 ++++++++++++++++++---
registration/tests/test_forms.py | 6 ++
registration/tests/test_hmac_workflow.py | 105 ++++++++++++------
registration/tests/test_model_workflow.py | 63 ++++++++---
registration/tests/test_models.py | 17 ---
registration/tests/test_simple_workflow.py | 16 ++-
registration/validators.py | 4 +
registration/views.py | 4 +-
setup.cfg | 2 +-
setup.py | 1 +
34 files changed, 434 insertions(+), 218 deletions(-)
diff --git a/PKG-INFO b/PKG-INFO
index 942f37e..4c45b31 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: django-registration
-Version: 2.1.2
+Version: 2.2
Summary: An extensible user-registration application for Django
Home-page: https://github.com/ubernostrum/django-registration/
Author: James Bennett
@@ -13,6 +13,7 @@ Classifier: Environment :: Web Environment
Classifier: Framework :: Django
Classifier: Framework :: Django :: 1.8
Classifier: Framework :: Django :: 1.9
+Classifier: Framework :: Django :: 1.10
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: OS Independent
diff --git a/README.rst b/README.rst
index 1c547f2..d2c1c1f 100644
--- a/README.rst
+++ b/README.rst
@@ -9,4 +9,4 @@ requires a functional installation of Django 1.8 or newer, but has no
other dependencies.
Full documentation is `available online
-<https://django-registration.readthedocs.org/>`_.
+<https://django-registration.readthedocs.io/>`_.
diff --git a/django_registration.egg-info/PKG-INFO b/django_registration.egg-info/PKG-INFO
index 942f37e..4c45b31 100644
--- a/django_registration.egg-info/PKG-INFO
+++ b/django_registration.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: django-registration
-Version: 2.1.2
+Version: 2.2
Summary: An extensible user-registration application for Django
Home-page: https://github.com/ubernostrum/django-registration/
Author: James Bennett
@@ -13,6 +13,7 @@ Classifier: Environment :: Web Environment
Classifier: Framework :: Django
Classifier: Framework :: Django :: 1.8
Classifier: Framework :: Django :: 1.9
+Classifier: Framework :: Django :: 1.10
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: OS Independent
diff --git a/docs/conf.py b/docs/conf.py
index fd7fead..9b58b39 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -8,9 +8,9 @@ templates_path = ['_templates']
source_suffix = '.rst'
master_doc = 'index'
project = u'django-registration'
-copyright = u'2007-2015, James Bennett'
-version = '2.1'
-release = '2.1.2'
+copyright = u'2007-2016, James Bennett'
+version = '2.2'
+release = '2.2'
exclude_trees = ['_build']
pygments_style = 'sphinx'
html_static_path = ['_static']
diff --git a/docs/custom-user.rst b/docs/custom-user.rst
index badf8b4..2904769 100644
--- a/docs/custom-user.rst
+++ b/docs/custom-user.rst
@@ -3,15 +3,15 @@
Custom user models
==================
-When ``django-registration`` was first developed, Django's
+When django-registration was first developed, Django's
authentication system supported only its own built-in user model,
``django.contrib.auth.models.User``. More recent versions of Django
have introduced support for `custom user models
<https://docs.djangoproject.com/en/stable/topics/auth/customizing/#substituting-a-custom-user-model>`_.
-Older versions of ``django-registration`` did not generally support
+Older versions of django-registration did not generally support
custom user models due to the additional complexity required; as of
-version |version|, however, ``django-registration`` now can support
+version |version|, however, django-registration now can support
custom user models. Depending on how significantly your custom user
model differs from Django's default, you may need to change only a few
lines of code; custom user models significantly different from the
@@ -21,29 +21,29 @@ default model may require more work to support.
Overview
--------
-The primary issue when using ``django-registration`` with a custom
+The primary issue when using django-registration with a custom
user model will be
:class:`~registration.forms.RegistrationForm`. ``RegistrationForm`` is
a subclass of Django's built-in ``UserCreationForm``, which in turn is
a ``ModelForm`` with its model set to
``django.contrib.auth.models.User``. The only changes made by
-``django-registration`` are to apply the reserved name validator
+django-registration are to apply the reserved name validator
(:class:`registration.validators.ReservedNameValidator`) and make the
``email`` field required (by default, Django's user model makes this
field optional; it is required in ``RegistrationForm`` because two of
-the three built-in workflows of ``django-registration`` require an
+the three built-in workflows of django-registration require an
email address in order to send account-activation instructions to the
user). As a result, you will always be required to supply a custom
-form class when using ``django-registration`` with a custom user
+form class when using django-registration with a custom user
model.
In the case where your user model is compatible with the default
-behavior of ``django-registration``, (see below) you will be able to
+behavior of django-registration, (see below) you will be able to
simply subclass ``RegistrationForm``, set it to use your custom user
model as the model, and then configure the views in
-``django-registration`` to use your form subclass. For example, you
+django-registration to use your form subclass. For example, you
might do the following (in a ``forms.py`` module somewhere in your
-codebase -- do **not** directly edit ``django-registration``'s code):
+codebase -- do **not** directly edit django-registration's code):
.. code-block:: python
@@ -80,7 +80,7 @@ activation workflow):
]
If your custom user model is not compatible with the built-in
-workflows of ``django-registration`` (see next section), you will
+workflows of django-registration (see next section), you will
probably need to subclass the provided views (either the base
registration views, or the views of the workflow you want to use) and
make the appropriate changes for your user model.
@@ -89,10 +89,10 @@ make the appropriate changes for your user model.
Determining compatibility of a custom user model
------------------------------------------------
-The built-in workflows and other code of ``django-registration`` do as
+The built-in workflows and other code of django-registration do as
much as is possible to ensure compatibility with custom user models;
``django.contrib.auth.models.User`` is never directly imported or
-referred to, and all code in ``django-registration`` instead uses
+referred to, and all code in django-registration instead uses
``settings.AUTH_USER_MODEL`` or
``django.contrib.auth.get_user_model()`` to refer to the user model,
and ``USERNAME_FIELD`` when access to the username is required.
@@ -104,10 +104,10 @@ The two-step activation workflows -- both :ref:`HMAC <hmac-workflow>`-
and :ref:`model <model-workflow>`-based -- require that your user
model have the following fields:
-* ``email`` -- a ``CharField`` or ``EmailField`` holding the user's
- email address. Note that this field is required by
- ``RegistrationForm``, which is a difference from Django's default
- ``UserCreationForm``.
+* ``email`` -- a textual field (``EmailField``, ``CharField`` or
+ ``TextField``) holding the user's email address. Note that this
+ field is required by ``RegistrationForm``, which is a difference
+ from Django's default ``UserCreationForm``.
* ``is_active`` -- a ``BooleanField`` indicating whether the user's
account is active.
@@ -124,11 +124,12 @@ The model-based activation workflow requires one additional field:
:ref:`The simple one-step workflow <simple-workflow>` requires that
your user model set ``USERNAME_FIELD``, and requires that it define a
-field named ``password`` for storing the user's password; the
-combination of ``USERNAME_FIELD`` and ``password`` must be sufficient
-to log a user in. Also note that ``RegistrationForm`` requires the
-``email`` field, so either provide that field on your model or
-subclass ``RegistrationForm``.
+field named ``password`` for storing the user's password (it will
+expect to find this value in the ``password1`` field of the
+registration form); the combination of ``USERNAME_FIELD`` and
+``password`` must be sufficient to log a user in. Also note that
+``RegistrationForm`` requires the ``email`` field, so either provide
+that field on your model or subclass ``RegistrationForm``.
If your custom user model defines additional fields beyond the minimum
requirements, you'll either need to ensure that all of those fields
diff --git a/docs/faq.rst b/docs/faq.rst
index 02a296f..968b6a3 100644
--- a/docs/faq.rst
+++ b/docs/faq.rst
@@ -16,7 +16,7 @@ General
By using `django-allauth
<https://pypi.python.org/pypi/django-allauth>`_. No single
application can or should provide a universal API for every
- authentication system ever developed; ``django-registration``
+ authentication system ever developed; django-registration
sticks to making it easy to implement typical signup workflows
using Django's own user model and auth system (with some ability
to use custom user models), while apps like ``django-allauth``
@@ -25,7 +25,7 @@ General
**What license is django-registration under?**
- ``django-registration`` is offered under a three-clause BSD-style
+ django-registration is offered under a three-clause BSD-style
license; this is `an OSI-approved open-source license
<http://www.opensource.org/licenses/bsd-license.php>`_, and allows
you a large degree of freedom in modifiying and redistributing the
@@ -36,22 +36,23 @@ General
**What versions of Django and Python are supported?**
- As of ``django-registration`` |version|, Django 1.8 and 1.9 are
- supported, on Python 2.7, 3.3, 3.4 or 3.5. Although Django 1.8
- supported Python 3.2 at initial release, Python 3.2 is now at its
- end-of-life and ``django-registration`` no longer supports it.
+ As of django-registration |version|, Django 1.8, 1.9, and 1.10
+ are supported, on Python 2.7, 3.3 (Django 1.8 only), 3.4 and
+ 3.5. Although Django 1.8 supported Python 3.2 at initial release,
+ Python 3.2 is now at its end-of-life and django-registration
+ no longer supports it.
- It is expected that ``django-registration`` |version| will also
- work with Django 1.10 and Python 3.6 once they are released.
+ It is expected that django-registration |version| will work
+ without modification on Python 3.6 once it is released.
**I found a bug or want to make an improvement!**
- The canonical development repository for ``django-registration``
+ The canonical development repository for django-registration
is online at
<https://github.com/ubernostrum/django-registration>. Issues and
pull requests can both be filed there.
- If you'd like to contribute to ``django-registration``, that's
+ If you'd like to contribute to django-registration, that's
great! Just please remember that pull requests should include
tests and documentation for any changes made, and that following
`PEP 8 <https://www.python.org/dev/peps/pep-0008/>`_ is
@@ -61,41 +62,41 @@ General
**How secure is django-registration?**
- In the nine-year history of ``django-registration``, there have
+ In the nine-year history of django-registration, there have
been no security issues reported which required new releases to
- remedy. This doesn't mean, though, that ``django-registration`` is
+ remedy. This doesn't mean, though, that django-registration is
perfectly secure: much will depend on ensuring best practices in
deployment and server configuration, and there could always be
security issues that just haven't been recognized yet.
- ``django-registration`` does, however, try to avoid common security
+ django-registration does, however, try to avoid common security
issues:
- * ``django-registration`` |version| only supports versions of
+ * django-registration |version| only supports versions of
Django which were receiving upstream security support at the time
of release.
- * ``django-registration`` does not attempt to generate or store
+ * django-registration does not attempt to generate or store
passwords, and does not transmit credentials which could be used
to log in (the only "credential" ever sent out by
- ``django-registration`` is an activation key used in the two-step
+ django-registration is an activation key used in the two-step
activation workflows, and that key can only be used to make an
account active; it cannot be used to log in).
- * ``django-registration`` works with Django's own security features
+ * django-registration works with Django's own security features
(including cryptographic features) where possible, rather than
reinventing its own.
**How do I run the tests?**
- ``django-registration`` makes use of Django's own built-in
+ django-registration makes use of Django's own built-in
unit-testing tools, and supports several ways to execute its test
suite:
* Within a Django project, simply invoke ``manage.py test
registration``.
- * If you've installed ``django-registration`` (so that it's on
+ * If you've installed django-registration (so that it's on
your Python import path) and Django, but don't yet have a
project created or want to test independently of a project, you
can run ``registration/runtests.py``, or you can invoke ``python
@@ -103,8 +104,8 @@ General
``registration/runtests.py``).
Additionally, the ``setup.cfg`` file included in
- ``django-registration`` provides configuration for `coverage.py
- <https://coverage.readthedocs.org/>`_, enabling
+ django-registration provides configuration for `coverage.py
+ <https://coverage.readthedocs.io/>`_, enabling
easy recording and reporting of test coverage.
@@ -149,7 +150,7 @@ Configuration
You're free to choose whichever one you think best fits your
needs. However, :ref:`the model-based workflow <model-workflow>`
is mostly provided for backwards compatibility with older versions
- of ``django-registration``; it dates to 2007, and though it is
+ of django-registration; it dates to 2007, and though it is
still as functional as ever, :ref:`the HMAC workflow
<hmac-workflow>` has less overhead (i.e., no need to install or
work with any models) due to being able to take advantage of more
@@ -172,7 +173,7 @@ Configuration
**I don't want to write my own URLconf because I don't want to write patterns for all the auth views!**
- You're in luck, then; ``django-registration`` provides a URLconf
+ You're in luck, then; django-registration provides a URLconf
which *only* contains the patterns for the auth views, and which
you can include in your own URLconf anywhere you'd like; it lives
at ``registration.auth_urls``.
@@ -214,4 +215,13 @@ Tips and tricks
you'd like to activate, then select the "Activate users" action.
In the HMAC-based workflow, simply toggle the ``is_active`` field
- of the user in the admin.
\ No newline at end of file
+ of the user in the admin.
+
+**How do I allow Unicode in usernames?**
+
+ Use Python 3. Django's username validation allows any word
+ character plus some additional characters, but the definition of
+ "word character" depends on the Python version in use. On Python
+ 2, only ASCII will be permitted; on Python 3, usernames containing
+ word characters matched by a regex with the ``UNICODE`` flag will
+ be accepted.
diff --git a/docs/forms.rst b/docs/forms.rst
index b80a963..d0a0124 100644
--- a/docs/forms.rst
+++ b/docs/forms.rst
@@ -4,10 +4,10 @@
Base form classes
=================
-Several form classes are provided with ``django-registration``,
+Several form classes are provided with django-registration,
covering common cases for gathering account information and
implementing common constraints for user registration. These forms
-were designed with ``django-registration``'s built-in registration
+were designed with django-registration's built-in registration
workflows in mind, but may also be useful in other situations.
@@ -44,9 +44,21 @@ workflows in mind, but may also be useful in other situations.
of ``django.contrib.auth.models.User``. The repeated entry of the
password serves to catch typos.
+ .. note:: **Unicode usernames**
+
+ There is one important difference in form behavior depending on
+ the version of Python you're using. Django's username validation
+ regex allows a username to contain any word character along with
+ the following set of additional characters: ``. at +-``. However,
+ on Python 2 this regex uses the ``ASCII`` flag (since Python 2's
+ string type is ASCII by default), while on Python 3 it uses the
+ ``UNICODE`` flag (since Python 3's string type is Unicode). This
+ means that usernames containing non-ASCII word characters are
+ only permitted when using Python 3.
+
The validation error for mismatched passwords is attached to the
``password2`` field. This is a backwards-incompatible change from
- ``django-registration`` 1.0.
+ django-registration 1.0.
.. note:: **Validation of usernames**
diff --git a/docs/hmac.rst b/docs/hmac.rst
index 04c5355..c466266 100644
--- a/docs/hmac.rst
+++ b/docs/hmac.rst
@@ -14,7 +14,7 @@ key; instead, the activation key sent to the user is a timestamped,
value.
Unless you need to maintain compatibility in an existing install of
-``django-registration`` which used the model-based workflow, it's
+django-registration which used the model-based workflow, it's
recommended you use the HMAC activation workflow for two-step signup
processes.
diff --git a/docs/index.rst b/docs/index.rst
index e9ced02..281c32a 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -3,7 +3,7 @@
django-registration |version|
=============================
-``django-registration`` is a simple, extensible application providing
+django-registration is a simple, extensible application providing
user registration functionality for `Django
<https://www.djangoproject.com/>`_-powered Web sites.
@@ -19,7 +19,7 @@ cases:
To get up and running quickly, consult :ref:`the quick start guide
<quickstart>`, which describes the steps necessary to configure
-``django-registration`` for the built-in workflows. For more detailed
+django-registration for the built-in workflows. For more detailed
information, including how to customize the registration process (and
support for alternate registration systems), read through the
documentation listed below.
diff --git a/docs/install.rst b/docs/install.rst
index abe31d2..b7d083c 100644
--- a/docs/install.rst
+++ b/docs/install.rst
@@ -4,34 +4,36 @@
Installation guide
==================
-Before installing ``django-registration``, you'll need to have a copy
+Before installing django-registration, you'll need to have a copy
of `Django <https://www.djangoproject.com>`_ already installed. For
information on obtaining and installing Django, consult the `Django
download page <https://www.djangoproject.com/download/>`_, which
offers convenient packaged downloads and installation instructions.
-The |version| release of ``django-registration`` supports Django 1.8
-and 1.9, on any Python version supported by those versions of Django:
+The |version| release of django-registration supports Django 1.8,
+1.9, and 1.10, on the following Python versions:
* Django 1.8 suports Python 2.7, 3.3, 3.4 and 3.5.
* Django 1.9 supports Python 2.7, 3.4 and 3.5.
-It is expected that ``django-registration`` |version| will also work
-with Django 1.10 and Python 3.6 once they are released.
+* Django 1.10 supports Python 2.7, 3.4 and 3.5.
+
+It is expected that django-registration |version| will work
+without modification on Python 3.6 once it is released.
.. important:: **Python 3.2**
Although Django 1.8 supported Python 3.2 at the time of its
release, the Python 3.2 series has reached end-of-life, and as a
result support for Python 3.2 has been dropped from
- ``django-registration`` as of |version|.
+ django-registration.
Normal installation
-------------------
-The preferred method of installing ``django-registration`` is via
+The preferred method of installing django-registration is via
``pip``, the standard Python package-installation tool. If you don't
have ``pip``, instructions are available for `how to obtain and
install it <https://pip.pypa.io/en/latest/installing.html>`_. If
@@ -47,7 +49,7 @@ Once you have ``pip``, simply type::
Manual installation
-------------------
-It's also possible to install ``django-registration`` manually. To do
+It's also possible to install django-registration manually. To do
so, obtain the latest packaged version from `the listing on the Python
Package Index
<https://pypi.python.org/pypi/django-registration/>`_. Unpack the
@@ -55,21 +57,21 @@ Package Index
python setup.py install
-Once you've installed ``django-registration``, you can verify
+Once you've installed django-registration, you can verify
successful installation by opening a Python interpreter and typing
``import registration``.
If the installation was successful, you'll simply get a fresh Python
prompt. If you instead see an ``ImportError``, check the configuration
of your install tools and your Python import path to ensure
-``django-registration`` installed into a location Python can import
+django-registration installed into a location Python can import
from.
Installing from a source checkout
---------------------------------
-The development repository for ``django-registration`` is at
+The development repository for django-registration is at
<https://github.com/ubernostrum/django-registration>. Presuming you
have `git <http://git-scm.com/>`_ installed, you can obtain a copy of
the repository by typing::
diff --git a/docs/model-workflow.rst b/docs/model-workflow.rst
index de9a687..4a314ae 100644
--- a/docs/model-workflow.rst
+++ b/docs/model-workflow.rst
@@ -10,11 +10,11 @@ activation -- process for user signup.
.. note:: **Use of the model-based workflow is discouraged**
The model-based activation workflow was originally the *only*
- workflow built in to ``django-registration``, and later was the
+ workflow built in to django-registration, and later was the
default one. However, it no longer represents the best practice for
registration with modern versions of Django, and so it continues to
be included only for backwards compatibility with existing
- installations of ``django-registration``.
+ installations of django-registration.
If you're setting up a new installation and want a two-step process
with activation, it's recommended you use :ref:`the HMAC activation
@@ -22,7 +22,7 @@ activation -- process for user signup.
Also, note that this workflow was previously found in
``registration.backends.default``, and imports from that location
- still function in ``django-registration`` |version| but now raise
+ still function in django-registration |version| but now raise
deprecation warnings. The correct location going forward is
``registration.backends.model_activation``.
@@ -60,7 +60,7 @@ argument ``form_class`` to the registration view.
Two views are provided:
``registration.backends.model_activation.views.RegistrationView`` and
``registration.backends.model_activation.views.ActivationView``. These
-views subclass ``django-registration``'s base
+views subclass django-registration's base
:class:`~registration.views.RegistrationView` and
:class:`~registration.views.ActivationView`, respectively, and
implement the two-step registration/activation process.
@@ -212,6 +212,22 @@ Additionally, :class:`RegistrationProfile` has a custom manager
:type activation_key: string, a 40-character SHA1 hexdigest
:rtype: user or bool
+ .. method:: expired
+
+ Return instances of :class:`RegistrationProfile` corresponding
+ to expired users. A user is considered to be "expired" if:
+
+ * The activation key of the user's :class:`RegistrationProfile`
+ is not set to :attr:`RegistrationProfile.ACTIVATED`, and
+
+ * The user's ``is_active`` field of is ``False``, and
+
+ * The user's ``date_joined`` field is more than
+ :data:`~django.conf.settings.ACCOUNT_ACTIVATION_DAYS` in the
+ past.
+
+ :rtype: ``QuerySet`` of :class:`RegistrationProfile`
+
.. method:: delete_expired_users
Removes expired instances of :class:`RegistrationProfile`, and
@@ -219,14 +235,6 @@ Additionally, :class:`RegistrationProfile` has a custom manager
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
- with associated user accounts which are inactive (have their
- ``is_active`` field set to ``False``). To disable a user account
- without having it deleted, simply delete its associated
- :class:`RegistrationProfile`; any ``User`` which does not have
- an associated :class:`RegistrationProfile` will not be deleted.
-
A custom management command is provided which will execute this
method, suitable for use in cron jobs or other scheduled
maintenance tasks: ``manage.py cleanupregistration``.
diff --git a/docs/quickstart.rst b/docs/quickstart.rst
index 769471f..7839d89 100644
--- a/docs/quickstart.rst
+++ b/docs/quickstart.rst
@@ -3,12 +3,12 @@
Quick start guide
=================
-First you'll need to have Django and ``django-registration``
+First you'll need to have Django and django-registration
installed; for details on that, see :ref:`the installation guide
<install>`.
The next steps will depend on which registration workflow you'd like
-to use. There are three workflows built in to ``django-registration``;
+to use. There are three workflows built in to django-registration;
one is included largely for backwards compatibility with older
releases, while the other two are recommended for new
installations. Those two are:
@@ -33,7 +33,7 @@ The guide below covers use of these two workflows.
<https://docs.djangoproject.com/en/stable/topics/auth/customizing/#substituting-a-custom-user-model>`_,
you'll probably want to pause and read :ref:`the custom user
compatibility guide <custom-user>` before using
- ``django-registration``.
+ django-registration.
Configuring the HMAC activation workflow
@@ -62,7 +62,7 @@ Django settings::
You'll also need to have ``django.contrib.auth`` in your
``INSTALLED_APPS`` setting, since all of the registration workflows in
-``django-registration`` make use of it.
+django-registration make use of it.
.. warning:: You should **not** add ``registration`` to your
``INSTALLED_APPS`` setting if you're following this document. This
@@ -78,7 +78,7 @@ You'll also need to have ``django.contrib.auth`` in your
Setting up URLs
~~~~~~~~~~~~~~~
-Each bundled registration workflow in ``django-registration`` includes
+Each bundled registration workflow in django-registration 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
@@ -113,9 +113,9 @@ Required templates
~~~~~~~~~~~~~~~~~~
You will also need to create several templates required by
-``django-registration``, and possibly additional templates required by
+django-registration, and possibly additional templates required by
views in ``django.contrib.auth``. The templates required by
-``django-registration`` are as follows; note that, with the exception
+django-registration are as follows; note that, with the exception
of the templates used for account activation emails, all of these are
rendered using a ``RequestContext`` and so will also receive any
additional variables provided by `context processors
@@ -209,7 +209,7 @@ following context:
Note that the templates used to generate the account activation email
use the extension ``.txt``, not ``.html``. Due to widespread antipathy
toward and interoperability problems with HTML email,
-``django-registration`` defaults to plain-text email, and so these
+django-registration defaults to plain-text email, and so these
templates should simply output plain text rather than HTML.
To make use of the views from ``django.contrib.auth`` (which are set
diff --git a/docs/settings.rst b/docs/settings.rst
index a7cd755..864d356 100644
--- a/docs/settings.rst
+++ b/docs/settings.rst
@@ -8,7 +8,7 @@ Custom settings
Although the choice of registration workflow does not necessarily
require changes to your Django settings (as registration workflows are
selected by including the appropriate URL patterns in your root
-URLconf), the built-in workflows of ``django-registration`` make use
+URLconf), the built-in workflows of django-registration make use
of several custom settings.
@@ -56,7 +56,7 @@ of several custom settings.
This setting is optional, and a default of ``"registration"`` will
be used if not specified. The value of this setting does not need
- to be kept secret; see ref:`the note about this salt value and
+ to be kept secret; see :ref:`the note about this salt value and
security <salt-security>` for details.
Used by:
diff --git a/docs/signals.rst b/docs/signals.rst
index 29e317f..1a59530 100644
--- a/docs/signals.rst
+++ b/docs/signals.rst
@@ -5,7 +5,7 @@
Signals used by django-registration
===================================
-Much of ``django-registration``'s customizability comes through the
+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,
diff --git a/docs/simple-workflow.rst b/docs/simple-workflow.rst
index 9caa359..c28c0db 100644
--- a/docs/simple-workflow.rst
+++ b/docs/simple-workflow.rst
@@ -6,7 +6,7 @@ The simple one-step workflow
As an alternative to the :ref:`HMAC <hmac-workflow>` and
:ref:`model-based <model-workflow>` two-step (registration and
-activation) workflows, ``django-registration`` bundles a one-step
+activation) workflows, django-registration bundles a one-step
registration workflow in ``registration.backends.simple``. This
workflow is deliberately as simple as possible:
diff --git a/docs/upgrade.rst b/docs/upgrade.rst
index b98c58b..2254ce2 100644
--- a/docs/upgrade.rst
+++ b/docs/upgrade.rst
@@ -5,25 +5,25 @@ Upgrading from previous versions
================================
Prior to 2.0, the last widely-deployed release of
-``django-registration`` was 0.8; a 1.0 release was published, and
+django-registration was 0.8; a 1.0 release was published, and
|version| is mostly backwards-compatible with it, but 1.0 appears not
to have seen wide adoption. As such, this guide covers the process of
-upgrading from ``django-registration`` 0.8, as well as from 1.0.
+upgrading from django-registration 0.8, as well as from 1.0.
Backends are now class-based views
----------------------------------
-In ``django-registration`` 0.8, a registration workflow was
+In django-registration 0.8, a registration workflow was
implemented as a class with specific methods for the various steps of
-the registration process. In ``django-registration`` |version|, a
+the registration process. In django-registration 2.0 and later, a
registration workflow is implemented as one or more class-based views.
In general, the required changes to implement a 0.8 registration
-workflow in ``django-registration`` |version| is:
+workflow in django-registration |version| is:
+-------------------------------------------------------------+------------------------------------------------------------------+
-| 0.8 backend class implementation | |version| view subclass implementation |
+| 0.8 backend class implementation | 2.0+ view subclass implementation |
+=============================================================+==================================================================+
| Backend class implementing ``register()`` | :meth:`registration.views.RegistrationView.register` |
+-------------------------------------------------------------+------------------------------------------------------------------+
@@ -43,10 +43,10 @@ URLconf changes
---------------
If you were using one of the provided workflows in
-``django-registration`` 0.8 without modification, you will not need to
+django-registration 0.8 without modification, you will not need to
make any changes; both ``registration.backends.default.urls`` and
``registration.backends.simple.urls`` have been updated in
-``django-registration`` |version| to correctly point to the new
+django-registration 2.0+ to correctly point to the new
class-based views:
+---------------------------------+---------------------------------------------------+
@@ -86,14 +86,14 @@ the errors dictionary.
Changes since 1.0
-----------------
-If you used ``django-registration`` 1.0, or a pre-release checkout of
-the |version| code, you will need to make some minor adjustments.
+If you used django-registration 1.0, or a pre-2.0 checkout of the
+code, you will need to make some minor adjustments.
If you previously used ``registration.backends.default``, you will now
see deprecation warnings, as the former "default" workflow is now
found in ``registration.backends.model_activation``. Use of
``registration.backends.default`` continues to work in
-``django-registration`` |version|, but will be removed in the future.
+django-registration |version|, but will be removed in the future.
Similarly, references to ``registration.urls`` should become
references to ``registration.backends.model_activation.urls``, and
@@ -125,14 +125,22 @@ following changes need to be noted:
Changes since 2.0
-----------------
-Only one major change occurred between ``django-registration`` 2.0 and
-|version|: the addition of the
+Only one major change occurred between django-registration 2.0 and
+|version|: the addition in version 2.1 of the
:class:`~registration.validators.ReservedNameValidator`, which is now
used by default on :class:`~registration.forms.RegistrationForm` and
its subclasses.
This is technically backwards-incompatible, since a set of usernames
-which previously could be registered now cannot be registered. If you
-need to allow users to register with usernames forbidden by this
-validator, see its documentation for notes on how to customize or
-disable it.
+which previously could be registered now cannot be registered, but was
+included because the security benefits outweigh the edge cases of the
+now-disallowed usernames. If you need to allow users to register with
+usernames forbidden by this validator, see its documentation for notes
+on how to customize or disable it.
+
+In |version|, the behavior of the
+:meth:`~registration.models.RegistrationProfile.expired` method was
+clarified to accommodate user expectations; it does *not* return (and
+thus,
+:meth:`~registration.models.RegistrationProfile.delete_expired_users`
+does not delete) profiles of users who had successfully activated.
\ No newline at end of file
diff --git a/docs/validators.rst b/docs/validators.rst
index d540da6..423b778 100644
--- a/docs/validators.rst
+++ b/docs/validators.rst
@@ -5,7 +5,7 @@ Validation utilities
====================
To ease the process of validating user registration data,
-``django-registration`` includes some validation-related data and
+django-registration includes some validation-related data and
utilities in ``registration.validators``.
The available error messages are:
@@ -38,7 +38,7 @@ The available error messages are:
All of these error messages are marked for translation; most have
translations into multiple languages already in
-``django-registration``.
+django-registration.
Additionally, one custom validator is provided:
@@ -73,7 +73,7 @@ Additionally, one custom validator is provided:
which conflicts with an important URL, email address or
subdomain, and this might give that user control over it.
- ``django-registration`` includes a list of reserved names, and
+ django-registration includes a list of reserved names, and
rejects them as usernames by default, in order to avoid this
issue.
diff --git a/docs/views.rst b/docs/views.rst
index 07393cc..32f6e36 100644
--- a/docs/views.rst
+++ b/docs/views.rst
@@ -5,13 +5,13 @@ Base view classes
=================
In order to allow the utmost flexibility in customizing and supporting
-different workflows, ``django-registration`` makes use of Django's
+different workflows, django-registration makes use of Django's
support for `class-based views
<https://docs.djangoproject.com/en/stable/topics/class-based-views/>`_. Included
-in ``django-registration`` are two base classes which can be
+in django-registration are two base classes which can be
subclassed to implement whatever workflow is required.
-The built-in workflows in ``django-registration`` provide their own
+The built-in workflows in django-registration provide their own
subclasses of these views, and the documentation for those workflows
will indicate customization points specific to those subclasses. The
following reference covers useful attributes and methods of the base
@@ -103,8 +103,10 @@ classes, for use in writing your own custom subclasses.
method. If you choose to override ``form_invalid()`` in a
subclass of ``RegistrationView``, be sure to read the
implementation and comments in the source code of
- ``django-registration`` first. Note that Django 1.9.1, once
- released, will not be affected by this bug.
+ django-registration first. The relevant bug was fixed in
+ Django 1.9.1, but django-registration will continue to work
+ around it for as long as the Django 1.9 release series is
+ supported.
.. class:: ActivationView
diff --git a/registration/__init__.py b/registration/__init__.py
index c185e77..7f581d8 100644
--- a/registration/__init__.py
+++ b/registration/__init__.py
@@ -1,4 +1,4 @@
-VERSION = (2, 1, 2, 'final', 0)
+VERSION = (2, 2, 0, 'final', 0)
def get_version():
diff --git a/registration/backends/hmac/__init__.py b/registration/backends/hmac/__init__.py
index c8b6b9e..339f803 100644
--- a/registration/backends/hmac/__init__.py
+++ b/registration/backends/hmac/__init__.py
@@ -8,6 +8,6 @@ configuration.
For more details, see the documentation in the docs/ directory of the
source-code distribution, or online at
-http://django-registration.readthedocs.org/
+https://django-registration.readthedocs.io/
"""
diff --git a/registration/backends/model_activation/__init__.py b/registration/backends/model_activation/__init__.py
index baeb85d..59759fe 100644
--- a/registration/backends/model_activation/__init__.py
+++ b/registration/backends/model_activation/__init__.py
@@ -9,6 +9,6 @@ configuration.
For more details, see the documentation in the docs/ directory of the
source-code distribution, or online at
-http://django-registration.readthedocs.org/
+https://django-registration.readthedocs.io/
"""
diff --git a/registration/backends/simple/__init__.py b/registration/backends/simple/__init__.py
index 4305336..acbc59c 100644
--- a/registration/backends/simple/__init__.py
+++ b/registration/backends/simple/__init__.py
@@ -8,6 +8,6 @@ configuration.
For more details, see the documentation in the docs/ directory of the
source-code distribution, or online at
-http://django-registration.readthedocs.org/
+https://django-registration.readthedocs.io/
"""
diff --git a/registration/models.py b/registration/models.py
index e616d13..7f49e50 100644
--- a/registration/models.py
+++ b/registration/models.py
@@ -72,13 +72,11 @@ class RegistrationManager(models.Manager):
else:
now = datetime.datetime.now()
return self.exclude(
- user__is_active=True
+ models.Q(user__is_active=True) |
+ models.Q(activation_key=self.model.ACTIVATED)
).filter(
- models.Q(activation_key=self.model.ACTIVATED) |
- models.Q(
- user__date_joined__lt=now - datetime.timedelta(
- settings.ACCOUNT_ACTIVATION_DAYS
- )
+ user__date_joined__lt=now - datetime.timedelta(
+ settings.ACCOUNT_ACTIVATION_DAYS
)
)
diff --git a/registration/runtests.py b/registration/runtests.py
index 1f5755e..dfe4664 100644
--- a/registration/runtests.py
+++ b/registration/runtests.py
@@ -42,9 +42,21 @@ SETTINGS_DICT = {
'django.contrib.auth.middleware.AuthenticationMiddleware',
),
'SITE_ID': 1,
- 'TEMPLATE_DIRS': (
- os.path.join(APP_DIR, 'tests/templates'),
- ),
+ 'TEMPLATES': [{
+ 'BACKEND': 'django.template.backends.django.DjangoTemplates',
+ 'DIRS': [os.path.join(APP_DIR, 'tests/templates')],
+ 'OPTIONS': {
+ 'context_processors': [
+ 'django.contrib.auth.context_processors.auth',
+ 'django.template.context_processors.debug',
+ 'django.template.context_processors.i18n',
+ 'django.template.context_processors.media',
+ 'django.template.context_processors.static',
+ 'django.template.context_processors.tz',
+ 'django.contrib.messages.context_processors.messages',
+ ],
+ },
+ }],
}
diff --git a/registration/tests/base.py b/registration/tests/base.py
index 2964566..8d99a94 100644
--- a/registration/tests/base.py
+++ b/registration/tests/base.py
@@ -2,18 +2,71 @@
Base classes for other test cases to inherit from.
"""
+from contextlib import contextmanager
from django.contrib.auth import get_user_model
from django.core import mail
from django.core.urlresolvers import reverse
+from django.http import HttpRequest
from django.test import TestCase, override_settings
from ..forms import RegistrationForm
+from .. import signals
User = get_user_model()
... 619 lines suppressed ...
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/python-django-registration.git
More information about the Python-modules-commits
mailing list