[Django] #32035: AbstractUser.clean assumes default manager is named objects
Django
-----------------------------------------+------------------------
Reporter: ben-bitdotio | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 3.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-----------------------------------------+------------------------
From Managers documentation, "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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32035>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: ben-bitdotio | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 3.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Description changed by ben-bitdotio:
Old description:
> From Managers documentation, "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.
New description:
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32035#comment:1>
Django
Reporter: Ben Brooks | Owner: nobody
Type: Bug | Status: closed
Component: Uncategorized | Version: 3.1
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => needsinfo
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32035#comment:2>
Django
Reporter: Ben Brooks | Owner: nobody
Type: Bug | Status: closed
Component: Uncategorized | Version: 3.1
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Matthias Kestenholz):
* stage: Unreviewed => Accepted
Comment:
Makes sense to me.
[https://github.com/django/django/pull/13452 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/32035#comment:3>
Django
Reporter: Ben Brooks | Owner: nobody
Type: Bug | Status: closed
Component: Uncategorized | Version: 3.1
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32035#comment:4>
Django
Reporter: Ben Brooks | Owner: nobody
Type: Bug | Status: closed
Component: contrib.auth | Version: 3.1
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by felixxm):
* component: Uncategorized => contrib.auth
* stage: Accepted => Unreviewed
Comment:
We should wait for a clarification requested by Carlton.
--
Ticket URL: <https://code.djangoproject.com/ticket/32035#comment:5>
Django
Reporter: Ben Brooks | Owner: nobody
Type: Bug | Status: closed
Component: contrib.auth | Version: 3.1
Severity: Normal | Resolution: needsinfo
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Carlton Gibson):
> If people want a different name for the default manager they should
extend AbstractBaseUser instead.
So that was my thought yeah...
([https://docs.djangoproject.com/en/3.1/topics/auth/customizing/#specifying-a
-custom-user-model Specifying a custom user model] says to use
`AbstractBaseUser` from `django.contrib.auth.base_user`)
--
Ticket URL: <https://code.djangoproject.com/ticket/32035#comment:7>