Code

#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

Description

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 forms.py there is the line:

from django.contrib.auth.models import User

Shouldn't this use get_user_model instead ?

Attachments (0)

Change History (2)

comment:1 Changed 17 months ago by aaugustin

  • 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 an oversight; I'll ask its author to confirm.

Last edited 17 months ago by aaugustin (previous) (diff)

comment:2 Changed 17 months ago by russellm

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.