jcugat
Not the same behavior as Django's default User
This project's description is:
Custom user model for Django >= 1.5 with the same behaviour as Django's default User but with email instead of username.
The thing is, this custom user model doesn't have the same behavior as Django's default User. I expected this to be exactly the same as what I get with from django.contrib.auth.models import User, only without a username. It turns out that it's missing the first_name and last_name fields. Also, the get_full_name and get_short_name methods behave differently than Django's default User.
I propose that these differences be brought into alignment with Django's default behavior. Either that or change this project's description so that it's not misleading. Other than that, this project is great!
Yes, that behaviour is different from Django's User model, but can be easily implemented as explained in https://github.com/jcugat/django-custom-user#extending-emailuser-model
Maybe it could be a good idea to add another model to this package (let's say DjangoEmailUser) with the fields first_name and last_name and both methods already implemented. Pull requests are welcome :)
Personally, I think it's cleaner and less confusing if this app just provides a single model. Currently, the email replacing the username is just one of the differences. Would you be open to having the existing EmailUser model modified so that the email replacing the username truly is the only difference? I think that's what most people are after anyway (and that's what this app's description says). I realize that's a pretty major change (and not backwards compatible), so maybe that would be a good time to bump the version up to 1.0. What do you think? Too drastic of a change? Are you set on having two separate models?
That is exactly what I'm looking for. Honestly, I can't believe there is not a package that does just that. There used to be, but it is no longer maintained, and doesn't support newer versions of Django.
I think having the first name and last name in the profile model rather than the user model makes more sense. It may take some additional effort moving it over initially but makes the project structure much cleaner:
- User model - contains user-specific unique stuff (email and password used to login)
- Profile model - contains profile stuff (including first and last name)
