AbstractUser.clean assumes default manager is named objects

[Ben Brooks]

From Managers documentation (​https://docs.djangoproject.com/en/3.1/topics/db/managers/), "If you’re writing some code that must handle an unknown model, for example, in a third-party app that implements a generic view, use this manager (or _base_manager) rather than assuming the model has an objects manager."

Our third-party app implements a generic view (with objects = None) and set the default manager to be something else. When making calls to inherited methods, we run into NoneType errors due to normalize_email() implementation. The associated PR replaces objects with _default_manager to allow for the generic view implementation.

[Carlton Gibson]

Hi Ben,

I'm struggling to understand whether this is a valid report or not.

Our third-party app implements a generic view (with objects = None) and set the default manager to be something else.

So either...

1. You're implementing a view, in which case this doesn't make much sense, or
2. You're creating a custom user model, in which case if you're not happy with the default model implementation you should be extending AbstractBaseUser here.

Can I ask you to clarify?

Either way, it doesn't look like a valid report User and (by extension) AbstractUser don't really satisfy the "an unknown model" part of the docs you link.

Thanks.

[Matthias Kestenholz]

Makes sense to me.

​PR

[Matthias Kestenholz]

Oh sorry, I had the ticket open already and didn't see that you closed it Carlton. Unsure how to proceed now.

I think the problem is just that the clean() method assumes that the default user manager is called objects, and it shouldn't do that.

[Mariusz Felisiak]

We should wait for a clarification requested by Carlton.

[Matthias Kestenholz]

On second thought I agree with closing the issue; the AbstractUser definition contains objects = UserManager() therefore the code can and should expect that the manager is called objects.

If people want a different name for the default manager they should extend AbstractBaseUser instead.

[Carlton Gibson]

If people want a different name for the default manager they should extend AbstractBaseUser instead.

So that was my thought yeah...

(​Specifying a custom user model says to use AbstractBaseUser from django.contrib.auth.base_user)