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.
