| | 35 | == Option 2: The authtools approach == |
| | 36 | |
| | 37 | This option is similar to https://django-authtools.readthedocs.org/en/latest/. The idea would be to create a separate app that houses admin, views, etc., that are analogous to the ones that support User in django.contrib.auth. |
| | 38 | |
| | 39 | === Advantages === |
| | 40 | |
| | 41 | * Allows for other, potentially more sweeping alterations if desired (e.g. authtools combines first_name and last_name). |
| | 42 | |
| | 43 | === Disadvantages === |
| | 44 | |
| | 45 | * More code duplication |
| | 46 | * Doesn't really follow principle of least surprise. Ideally, the email-based User should behave exactly like the stock User, with this one exception. |
| | 47 | |