Opened 4 years ago

Closed 4 years ago

#19284 closed Uncategorized (wontfix)

django.contrib.auth.forms imports User instead of using get_user_model

Reported by: kunitoki@… Owned by: nobody
Component: contrib.auth Version: 1.5-alpha-1
Severity: Release blocker Keywords: auth user
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


When adding a user in admin (for which i've subclassed the form), i'm getting this:

Manager isn't available; User has been swapped for 'base.MyUser'

As in there is the line:

from django.contrib.auth.models import User

Shouldn't this use get_user_model instead ?

Change History (2)

comment:1 Changed 4 years ago by Aymeric Augustin

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

This was discussed in this thread.

There's a proposed patch but it isn't entirely satisfying.

I'm pretty sure that the current implementation is a design decision and not on oversight; I'll ask its author to confirm.

Version 0, edited 4 years ago by Aymeric Augustin (next)

comment:2 Changed 4 years ago by Russell Keith-Magee

Resolution: wontfix
Status: newclosed

Just importing User shouldn't cause an error. You must be inadvertently using the User model in some way.

The only forms using User are UserCreationForm and UserChangeForm, both of which are documented as needing to be over

The patch form @akaariai won't work reliably, either -- because it assumes makes an assumption about the name and validation of the username field. This means the form will fail in interesting ways, depending on the User model you have in use.

As an aside, the patch also make testing difficult, because the form is bound to the User model that is in use at the time the auth module is imported.

It might be possible to make the Create and Change forms completely generic, but for my money, it just isn't worth the effort and complexity, given the effort required to fix in a subclass. There might be some opportunity for introducing a base class to make subclassing easier, but that's a topic for a separate ticket.

tl;dr - that particular User import was deliberate, and shouldn't be causing problems. Marking wontfix on that basis.

If someone can demonstrate the way to reproduce the described error, then feel free to reopen.

Note: See TracTickets for help on using tickets.
Back to Top