Not the same behavior as Django's default User
See original GitHub issueThis 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!
Issue Analytics
- State:
- Created 8 years ago
- Comments:5 (1 by maintainers)
Top Results From Across the Web
Using the Django authentication system
For projects where authentication needs differ from the default, Django supports ... Django does not store raw (clear text) passwords on the user...
Read more >Why does Django's User Model set the email field as non ...
I am using Django's default User model and the email is not unique, now I have multiple users with the same email address....
Read more >What You Should Know About The Django User Model
Even though the username field is marked as unique, by default it is not case-sensitive. That means the username john.doe and John.doe ...
Read more >Django Tutorial Part 8: User authentication and permissions
If you log in using valid credentials, you'll be redirected to another page (by default this will be http://127.0.0.1:8000/accounts/profile/ ).
Read more >Custom user models — django-registration 3.3 documentation
Django's built-in auth system provides a default model for user accounts, but also supports replacing that default with a custom user model.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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:
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 fieldsfirst_name
andlast_name
and both methods already implemented. Pull requests are welcome 😃