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.
