Up front, I'm one of the developers of django-authtools I'm feel strongly that a new contrib application is the wrong way to accomplish this. Based on my memory of auth and django-authtools, most of `auth` will just work with the AbstractEmailUser class provided by django-authtools. Why not just include a new swappable user class in django.contrib.auth that uses email as username? I believe that all of the built in django.contrib.auth views will work with the AbstractEmailUser model in django-authtools, All of the forms from django.contrib.auth except UserCreationForm and UserChangeForm work with AbstractEmailUser. There would need to be changes to the ModelAdmin provided by django.contrib.auth. django-authtools has a ModelAdmin that works for the normal auth.User and with AbstractEmailUser, which would be a very minor change to django.contrib.auth.admin
Adding a new contrib application for this seems very heavy weight and to duplicate a lot of logic that already has a well established home. Is there other support for doing this more inline with the way it was done in django-authtools. On Tuesday, September 17, 2013 9:01:18 AM UTC-6, tanderegg wrote: > > Quick addendum: I forgot that django-libtech-emailuser does not use an > AbstractUser intermediary step, it simply has one model. My approach has > an abstract model, just like auth.User, with a concrete model that inherits > from it and is swappable. > > -Tim > > On Tuesday, September 17, 2013 10:46:32 AM UTC-4, tanderegg wrote: >> >> Hi Jorge - >> >> Thanks for the response. Rookie mistake: I had cloned from 1.6.x stable >> instead of master, the branch is now fixed to be branched from >> django/master from 10 minutes ago, that should resolve your conflicts. >> >> In terms of API, the API I went with is basically identical to the API >> used in django-libtech-emailuser, with the exception that I did not include >> a new password_reset form. Testing showed this was not necessary, the one >> in django.contrib.auth works fine with my model. The reason our API's are >> the same is because we both copied the existing API for >> django.contrib.auth.User exactly. This means first_name and last_name, >> along with the email, password, is_active, is_staff, and is_superuser all >> exist in the auth_email.AbstractUser model, just like they do in >> auth.AbstractUser. >> >> I went this route one the principle that simplicity is best, and I wanted >> folks to get the exact same behaviour from auth_email.AbstractUser, and >> auth_email.User, that they would expect from auth.AbstractUser and >> auth.User. >> >> django-libtech-emailuser did not includ any tests, so my code goes beyond >> that to include a small test suite that covers everything I thought was >> nesseccary to cover. >> >> I did not go the route of django-authtools because I felt that it went >> above and beyond the scope of this ticket, since it included multiple >> layers of abstraction, a rewrite of the views to use Class Based Views, >> etc. I felt that if I were to go that route, then the re-write should >> occur in django.contrib.auth, not in my extension of it. Hence, out of >> scope for this ticket since that could potentially affect an established >> API. >> >> Let me know if that logic makes sense! >> >> Tim >> >> On Tuesday, September 17, 2013 3:25:01 AM UTC-4, Jorge Cardoso Leitão >> wrote: >>> >>> Hi Tim. >>> >>> Thanks for posting this here. I was not aware of this ticket. >>> Thank you also for taking the initiative and starting moving on this >>> front. >>> >>> First of all, like you, I'm also recent in Django dev. This means that >>> most likely, we will both make mistakes in the approach. >>> The important is that we learn with them, and that is also why we are in >>> a community of more experience users. >>> >>> >>> Let me try to convey why is important that we take into account what >>> other people have already done (i.e. existing apps). >>> >>> I'm using django-authtools; I found the the app is has tests and it is >>> well documented. >>> I'm using it in production and so far I didn't found any issue. >>> >>> My point is: the main reason we try to use existing code is not because >>> the code is there, but because it is normally tested (both UnitTests and >>> people using it and reporting issues) and documented, which means it is >>> less prone to errors and more robust to integration. >>> >>> That said, I would start by comparing APIs. >>> That allow us to have a solid ground on what there is already out there, >>> to see if any of the existing apps fulfils our expectations of what we >>> would like to have in the core. >>> >>> I tried to clone your branch ticket_20824 from github to compare your >>> app with django-authtools, but it is (far) behind Django master branch, >>> which is causing merge conflicts that I don't know how to resolve (because >>> I don't know what you are exactly doing). >>> Maybe I'm doing something wrong or I don't know enough of git, but could >>> you please tell us (or maybe is just me that need to be told!) how can we >>> compare your patch with Django-master? >>> >>> Let me try to give an example: >>> >>> After taking a look at >>> github.com/Liberationtech/django-libtech-emailuser, the following are >>> the main differences and similarities with django-authtools. >>> Please notice that I'm a (so far) 1-time comitter of django-authtools, >>> so take this comparison with appropriate care as I'm certainly biased. >>> >>> Where they are *similar*: >>> >>> 1. Both are subclasses of AbstractBaseUser and PermissionsMixin (thus >>> allow permissions API to be used) >>> >>> 2. Both implement the required forms for creation, change, passwordReset. >>> >>> 3. Both implement admin interface >>> >>> Where they are *different*: >>> >>> 1. Models implementation: >>> >>> emailuser uses one model with 3 fields: email, first_name, last_name >>> (USERNAME_FIELD = 'email) >>> >>> django-authtools uses defines three models: >>> >>> A. AbstractUserMail (with one field 'email', like emailuser), >>> B. AbstractNamedUser, derived from AbstractUserMail with an additional >>> field "name". >>> C. User, derived from AbstractNamedUser, which is swappable and >>> non-abstract. >>> >>> 2. django-authtools has tests, emailuser doesn't >>> >>> 3. django-authtools is documented, emailuser doesn't >>> >>> 4. django-authtools implements views, emailuser doesn't. >>> >>> 5. they have different licences, but I don't know enough about them to >>> know what are the differences. >>> >>> 6. django-authtools passes on travis-ci.org tests, and, as far as I >>> know, enforces clean commit history (don't know if it is relevant thought). >>> >>> 7. usermail has a form to ask reset-password (by email?), but I didn't >>> found any implementation of the actual reset. >>> >>> >>> Tom, would you be willing to provide the differences and similarities of >>> your API with django-authtools and emailuser, or teach me how can I compare >>> it against django-master so I can make a comparison? >>> It would be nice to have your API documented here so we can take the >>> most out of the all existing implementations. >>> >>> Best regards, >>> Jorge >>> >>> On Sep 16, 2013, at 10:04 PM, tanderegg <timothy....@gmail.com> wrote: >>> >>> Hey folks - I took a crack at implementing this, please check out my >>> comment here (which contains a link to the branch in my fork): >>> https://code.djangoproject.com/ticket/20824#comment:4 >>> >>> Let me know if I missed anything! >>> >>> Tim >>> >>> On Friday, September 13, 2013 1:03:23 AM UTC-4, Aaron Merriam wrote: >>>> >>>> Check out django-authtools >>>> >>>> https://django-authtools.readthedocs.org/en/latest/ >>>> >>>> Provides a few abstract base classes that make this very easy to >>>> accomplish. I'm sure there are other 3rd party apps doing the same. >>>> >>>> >>>> On Thursday, September 12, 2013 2:44:53 PM UTC-6, Abdulaziz Alfoudari >>>> wrote: >>>>> >>>>> This is a continuation of my post on >>>>> stackoverflow<http://stackoverflow.com/questions/18769729/django-removing-username-from-user-model> >>>>> . >>>>> >>>>> With the introduction of Django 1.5, it was possible to create a >>>>> custom User model which is flexible enough to have any user profile the >>>>> developer wants created. However, looking at a very common problem which >>>>> is >>>>> using the email as the primary user identifier instead of username, the >>>>> solution requires copying most of Django's internal definition of >>>>> AbstractUser and that is only to remove the username field. >>>>> >>>>> A better solution in my opinion is make AbstractUser even more >>>>> abstract by removing username field, and allowing the developer to >>>>> explicitly specify the field to be used as the user identifier. This will >>>>> require a tiny extra work for those that use the current default >>>>> behavior, >>>>> but it will also greatly reduce the work needed for the very common >>>>> problem >>>>> of using email as the user identifier. >>>>> >>>>> Please share your thoughts and opinions on this. >>>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
