Swappable User model #57

wants to merge 5 commits into

9 participants


I'm working on support for custom user model as described in the docs for the upcoming Django 1.5.

My idea is to first get a working solution that allows for extending normal User model (subclassing django.contrib.auth.models.AbstractUser) and after that possibly replacing it with a totally custom one that is based on the AbstractBaseUser.

Is this something you would like to be included in the app? Any feedback and testing greatly appreciated.


I also have worked on this but I haven't submitted a pull request yet, so let this be the place for discussion on the implementation details. Probably there are things that we've both done that should be combined.

My current diff can be found here:

The most important detail is that the from django.contrib.auth import get_user_model feature will be backported to Django 1.4 once Django 1.5 is released. This is great and means that there is no reason for django-user-accounts not to accept the patch as soon as they drop support for Django 1.3. Until then that means maintaining a fork.

It is common for a reusable app to support only the current and last version of Django, but as long as this app supports Django 1.3 it will be a challenge to support the old and the new simultaneously.

It would be great to hear the Pinax dev's chime in on this topic because there are certainly other apps in the Pinax ecosystem that will need to be similarly updated sooner, rather than later.

@nigma nigma Use Django version to check for availability of ``get_user_model`` he…

Avoid intercepting accidental import errors
Pinax Project member

I like to keep the approach to custom User models as simple as possible. Initially, I don't mind keeping the Account model for now. Even though those fields are be done at the User level they are fundamentally handled differently by the app and I don't want a very big change as we want to land a 1.0 very soon.

Here is some feedback based on the current pull request:

  • I would prefer to use the name User over UserModel. Just because it can be plugged into under the covers shouldn't mean the APIs should suffer in beauty.

  • It doesn't seem to me that we are doing the best integration when it comes to looking up User instances. I see the use of get_by_natural_key good, but that assumes we pass in a username, but the point of the new User code is that this unique field could be anything. Perhaps we should be passing the data defined by get_username_field on the User model. This also leads to the a distinct difference between looking up a user by user input versus when we know the exact data. Not sure how to best handle that.

  • We need to rethink the sign up and log in forms possibly. On one hand we could leave it as-is and support username and email address and we can be dandy, but on the other hand is there something more we can do to avoid requiring custom forms? Perhaps it would be too much. Needs some thought.

The bottom-line is that we need to find a solution for this prior to 1.0 so I love feedback on my questions from others.


I am starting a new Django 1.5 project, and I would love to use django-user-accounts to handle user accounts. However, the relationship between auth.contrib.user, the django 1.5 custom user model, and django-user-accounts isn't very clear.

Will this application eventually work as a custom user model for django 1.5?

Pinax Project member

You did find the ticket! :-)

We are definitely going to support custom User models in 1.5. I have been toying on how best to do it. Expect something to land in the next week tops.


With the release of Django 1.5, are there any updates on support for the custom user model? Thanks!

Pinax Project member

The only update I have is that there is no update. I haven't spent the time thinking/working on this issue. Not sure when I'll have the time, but I will try for making some soon!


I did a simple hack which I found on this pull request for django-registration My commit diff is here justhamade@6466395

It does seem to work and should also work with 1.3 and 1.4 versions that don't support get_user_model and 1.4 versions that do have get_user_model backported.

Pinax Project member

There is an issue with calling get_user_model in global scope. It can cause import issues. This should be avoided at all cost. I won't accept anything that calls get_user_model in global scope.


I've updated my fork with a different approach with a from future idea taken from django-postman:



This takes into account not to call get_user_model in the global scope. There are a few failing tests, but they may have been failing to begin with because poking around the account forms on 1.4/1.5 everything appears to be working with the default configuration.


Is this ready to have a custom model for django 1.5 or not yet?


@rizumu why didn't you submitted a PR with your custom-user-model branch ? it's seems the perfect way to do that to me.


@dulaccc well, opening another PR would create a new ticket in github and since all the discussion is here and includes links to my PR I'd rather not start a new ticket.

Last I spoke with @brosner he said he'd like to test it out locally, so we are waiting on that. However, I can confirm it is working for me, if you and others can do the same, hopefully we could get this it merged sooner.


Pull request was opened 11 month ago... Problem still here.. :-/ Can we merge to develop any of this pull requests to fix problem and improve solution later?..

I need to use this package with Django 1.6 + Custom User Model + Python 3.3 ...

Pinax Project member

I'd like to update those following this PR. I have had a recent renewed interest in adding this functionality. It has become a priority for me. I have a mostly working patch. I am testing and resolving the issues I've raised in the past. I will be committing it soon (later today or tomorrow.)

@brosner brosner added a commit that closed this pull request Jan 14, 2014
@brosner brosner Added support for customizable user models
DUA now supports Django 1.5 user models with compatibility to 1.4. Fixes #57.

Huge thanks to Filip Wasilewski (nigma) and Thomas Schreiber (rizumu) who helped
implement the feature.
@brosner brosner closed this in 65cc7cd Jan 14, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment