macropin / django-registration / 346 / 6
97%
master: 97%

DEFAULT BRANCH: master
Ran
Files 31
Run time 1s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 96.975% (-0.2%) from 97.185%
DJANGO=Django==1.9.8

push

travis-ci

joshblum 
Add 3-step registration workflow by implementing another registration backend (#184)

* Add another registration backend (enhanced) to implement additional logic

Another registration workflow has been implemented. This is a 3-step
workflow which includes:

1) User registration
2) User activation
3) Admin approval of the newly registered account

This includes:

1) new url mappings
	(registration/backends/enhanced/urls.py)
2) new views to implement the modified & additional logic
	(registration/backends/enhanced/views.py)
3) a new signal, user_approved
	(registration/signals.py)
4) a new model, SupervisedRegistrationProfile:
	It inherits the previously used RegistrationProfile but uses another
	manager which is required for the additional workflow
	(registration/models.py)
5) a new manager, SupervisedRegistrationManager which includes some functions
	from already existent RegistrationManager, redefines the ones that
	need to be changed and adds some new functions as well
	(registration/models.py)
6) a new generic view, ApprovalView
	(registration/views.py)
7) new templates for the additional functionality
	(registration/templates/*)

To test the new functionality, new test cases have also been added
	(registration/tests/enhanced_backend.py)
	(registration/tests/models.py)

* Additional tests for function send_admin_approve_complete_email

* Fix template

* Refactor parameter "profile" to "profile_id"

* Make SupervisedRegistrationManager inherit from RegistrationManager

``SupervisedRegistrationManager`` now inherits from ``RegistrationManager``.
Functions ``create_inactive_user()``, ``create_profile()`` and
``resend_activation_email()`` have been removed, as they are identical to
the ones in ``RegistrationManager``.

* Refactor enhanced -> admin_approval

* Refactor user_id to profile_id

* Cosmetic changes

* Remove transaction.atomic() whenever not needed

* Remove RequestContext usage to prevent RemovedInDjango110Warning

* Create send_email() function

* Alter admin_approval backend tests

`tests/admin_approval.py` have been altered to prevent code duplication. To do so,
`tests/default.py` have been altered too. Changes:

1) add class variable in `DefaultBackendViewTests` to store registration profile
        (needs to be changed when subclassing from `AdminApprovalBackendViewTests`)
2) same process to store registration view
3) refactor direct usages to use class variable instead
4) changes in urls to run the correct tests (add mapping for `registration_resend_activation`)
5) add `ResendActivationView` in `backends/admin_approval/views.py`

* Alter models / managers tests

The tests for models (`RegistrationProfile`, `SupervisedRegistrationProfile`)
and their corresponding managers implemented in class `RegistrationModelTests`
have been altered to make it possible to inherit them in `SupervisedRegistrationModelTests'.

`RegistrationModelTests` now has a class variable storing the model of
the registration profile it uses. This way when subclassing it one can
change it.

`SupervisedRegistrationModelTests` now subclasses `RegistrationModelTests` and
extends them to redefine functions that need different parameters / add additional
tests

* Changes in templates

* Add ``_activate(..)`` private function

A new ``_activate()`` private function has been added in ``RegistrationManager``.
This allows us to change only this function when subclasssing ``RegistrationManager``
to implement 'admin_approval' backend instead of redefining ``RegistrationManager.activate_user()``

* Change ``admin_approval.views`` to inherit from ``default.views``

Most of the views in ``admin_approval.views`` followed the exact same
logic with the corresponding views in ``default.views`` but use
``SupervisedRegistrationProfile`` instead of ``RegistrationProfile``.
To be able to subclass those views instead of rewriting them we added
a field in each one of these storing the registration profile it uses.
This enables us to subclass the views changing only this field and
avoid repeating code.

* Revert ``test_app.settings`` to use default backend

* PEP8 compliance

* Remove commented imports, fix import for Python3.x compatibility

* Refactor ``id`` to ``profile_id``

* Remove ``__str__()`` method from ``SupervisedRegistrationProfile``

* Remove empty line from template

* Add docstring for ``SupervisedRegistrationProfile._activate``

* Change order of deletion in ``RegistrationManager.delete_expired_users()`` to inherit it

Executing user.delete() first and then profile.delete() is a logical error. It was not visible
before but now it is. ``RegistrationProfile`` has a ForeignKey (actually a OneToOneField
which cascades delete) to the user, so when the user was deleted his related ``RegistrationProfile``
was deleted too and when ``SupervisedRegistrationProfile`` was deleted it yielded the following error:

self.model.MultipleObjectsReturned( DoesNotExist: RegistrationProfile matching query does not exist)

* Follow ``RegistrationManager.activate_user()`` conventions when subclassing

* Refactor tests / add missing cases when subclassing

Tests have been refactored to use ``self.registration_profile`` instead
of directly using ``RegistrationProfile`` or ``SupervisedRegistrationProfile``
models.

In addition, some functionality has changed and after refactoring some tests
fail. To fix this, those tests have been redifined when subclassing.

* Add docstring in ``RegistrationManager._activate()``

* Remove whitespace

* Rename ``admin_approve()``->``approve``

* Remove unused ``UserModel.objects.all().delete()``

* Remove ``setUp()``, ``tearDown()``, use @override_settings instead

* Changes in tests, reverse url resolution

* Use `@override_settings` for Django 1.10 compatibility

1058 of 1091 relevant lines covered (96.98%)

0.97 hits per line

Source Files on job 346.6 (DJANGO=Django==1.9.8)