Hello all, this thread as gone so fast that I didn't manage to catch up and jump in time probably, but I did write a contrib app for Email-only user model: https://bitbucket.org/3h/django-accounts
My experience: I had to copy-paste a LOT of code to be sure all works, definitely much more that I thought I would at the beginning, to get what sounded basic to me: a User model /without/ the annoying (to me) username. Had I to do it again I would probably simply work on "save" to copy the email into the username and hack the form bit not to ask for a username. It sounds to me like going the other way around (the current User model inherits from the email-only user model) would have been simpler, but I understand that the username model is the standard django one. Anyway, as I said I feel I'm jumping in slightly too late but I hope that the following is somehow useful: 1. I also prefere user models without usernames 2. My implementation (could definitelyl have been better, but maybe it gives ideas as to what could be made more abstract?) https://bitbucket.org/3h/django-accounts and thus my experience/feedback on it (too complex to make wihtout copying a lot of Auth things along!) I'll be eagerly following this thread to see where it gets, and hope to be able to contribute more. Thanks! Stefano On Friday, September 20, 2013 6:45:52 PM UTC+2, tanderegg wrote: > > Hi Luke - > > I just wanted to let you know that I've already started a patch on this, > you can see it here: > https://github.com/tanderegg/django/compare/ticket_20824_master If you > want to reduce duplicated effort, please take a look at what I have so far > and let me know what you think! > > Russ, Aaron - > > I tend to agree with Russ here that it makes sense to keep auth_email as a > separate app, especially if swappable is not meant to be used on any model > other than auth.User. If EmailUser was also put into auth, not only would > it create an unesseccary set of tables, it also would cause m2m accessor > clashes with groups and permissions. Additionally, it provides a > "template" of sorts for others to refer to if they want to roll their own > user models. > > That said, even if we use a separate app, we might benefit from > refactoring AbstractUser a bit. I could see the following chain: > > AbstractBaseUser -> > AbstractPermissionsUser (ass ins Permissions Mixin) -> > AbstractEmailUser (just adds email field and email_user method) -> > AbstractNamedUser (adds first_name and last_name) -> > AbstractUser (retains same API as before) > > The advantage of doing this would be to remove some code duplication from > auth_email.EmailUser, and to create a few more inheritance opportunities > for scenarios where someone wants a user with no name fields, or if they > want to implement their own naming conventions, or if they want permissions > but no email and name. > > Here's an example of what that might look like: > https://github.com/tanderegg/django/compare/ticket_20824_refactor_master > I also modified the UserManager class to support any of these abstract > models. > > The main issue with doing this is that email would now be required for all > users (which could be avoided by removing AbstractEmailUser from the > inheritance chain and adding an email field to AbstractUser), and to > maintain backwards compatibility, UserManager.create_user would require > passing the email twice, once as username and once as email, for any model > that uses email as the username (which could be avoided by overriding in a > sub class when using email as username). > > Not sure if this refactoring would help all that much in the grand scheme > of things though. > > -Tim > > On Thursday, September 12, 2013 4:44:53 PM UTC-4, 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-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.
