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 <[email protected]> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
