[Django] #28594: Value error on related user name during save of user model
Django
-------------------------------------+-------------------------------------
Reporter: mc3 | Owner: nobody
Type: Bug | Status: new
Component: | Version: 1.11
contrib.auth | Keywords: Value error, user
Severity: Normal | model, normalize_username
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
problem:
While upgrading from 1.9 to 1.11, ForwardManyToOneDescriptor.__set__()
tries to assign a string (description of the related instance) to the
related user name field
of user model.
diagnosis:
In 1.10 normalize_username(), a class method of AbstractBaseUser, has been
introduced.
This class method forces the related user name instance to a string.
Fix:
Overwriting this with a method which just returns the 'username' fixes the
problem.
Details:
class AbstractEmailUser(AbstractBaseUser, PermissionsMixin,
FieldlistForDetailTemplateMixin):
localemail = models.OneToOneField('Mailbox', verbose_name=_('Local
E-mail'),
related_name='localemail', db_column='localemail',
editable=('UR', 'UE', 'UL'))
objects = UserManager()
USERNAME_FIELD = 'localemail'
REQUIRED_FIELDS = []
class Meta:
abstract = True
ordering = ['localemail']
def get_username(self):
return getattr(self, self.USERNAME_FIELD)
class Mailbox(models.Model):
id = models.AutoField(primary_key=True)
localpart = models.CharField(_('Localpart'), max_length=40)
localdomainfk = models.ForeignKey(Localdomain,
verbose_name=_('Domain'), db_column='localdomainfk', editable=('AL',))
…
def __str__(self):
return self.localpart+ '@'+self.localdomainfk.name
Internal Server Error: /admin/erdb/account/19/change/
Traceback (most recent call last):
File "...python3.5/site-packages/django/core/handlers/exception.py", line
41, in inner
response = get_response(request)
File "...python3.5/site-packages/django/core/handlers/base.py", line 249,
in _legacy_get_response
response = self._get_response(request)
File "...python3.5/site-packages/django/core/handlers/base.py", line 187,
in _get_response
response = self.process_exception_by_middleware(e, request)
File "...python3.5/site-packages/django/core/handlers/base.py", line 185,
in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/contextlib.py",
line 30, in inner
return func(*args, **kwds)
File "...python3.5/site-packages/django/contrib/admin/options.py", line
551, in wrapper
return self.admin_site.admin_view(view)(*args, **kwargs)
File "...python3.5/site-packages/django/utils/decorators.py", line 149,
in _wrapped_view
response = view_func(request, *args, **kwargs)
File "...python3.5/site-packages/django/views/decorators/cache.py", line
57, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
File "...python3.5/site-packages/django/contrib/admin/sites.py", line
224, in inner
return view(request, *args, **kwargs)
File "...python3.5/site-packages/django/contrib/admin/options.py", line
1511, in change_view
return self.changeform_view(request, object_id, form_url,
extra_context)
File "...python3.5/site-packages/django/utils/decorators.py", line 67, in
_wrapper
return bound_func(*args, **kwargs)
File "...python3.5/site-packages/django/utils/decorators.py", line 149,
in _wrapped_view
response = view_func(request, *args, **kwargs)
File "...python3.5/site-packages/django/utils/decorators.py", line 63, in
bound_func
return func.__get__(self, type(self))(*args2, **kwargs2)
File "...python3.5/site-packages/django/contrib/admin/options.py", line
1408, in changeform_view
return self._changeform_view(request, object_id, form_url,
extra_context)
File "...python3.5/site-packages/django/contrib/admin/options.py", line
1440, in _changeform_view
if form.is_valid():
File "...python3.5/site-packages/django/forms/forms.py", line 183, in
is_valid
return self.is_bound and not self.errors
File "...python3.5/site-packages/django/forms/forms.py", line 175, in
errors
self.full_clean()
File "...python3.5/site-packages/django/forms/forms.py", line 386, in
full_clean
self._post_clean()
File "...python3.5/site-packages/django/forms/models.py", line 408, in
_post_clean
self.instance.full_clean(exclude=exclude, validate_unique=False)
File "...python3.5/site-packages/django/db/models/base.py", line 1234, in
full_clean
self.clean()
File "...python3.5/site-packages/django/contrib/auth/base_user.py", line
77, in clean
setattr(self, self.USERNAME_FIELD,
self.normalize_username(self.get_username()))
File "...python3.5/site-
packages/django/db/models/fields/related_descriptors.py", line 216, in
__set__
self.field.remote_field.model._meta.object_name,
ValueError: Cannot assign "'unp...@framailx.de'": "Account.localemail"
must be a "Mailbox" instance.
[21/Aug/2017 16:08:37] "POST /admin/erdb/account/19/change/ HTTP/1.1" 500
166385
Discussion:
https://www.mail-archive.com/django...@googlegroups.com/msg178769.html
--
Ticket URL: <https://code.djangoproject.com/ticket/28594>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: contrib.auth | Version: 1.11
Severity: Normal | Resolution:
Keywords: Value error, user | Triage Stage:
model, normalize_username | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
New description:
problem:
While upgrading from 1.9 to 1.11, `ForwardManyToOneDescriptor.__set__()`
tries to assign a string (description of the related instance) to the
related user name field of user model.
diagnosis:
In 1.10 `normalize_username()`, a class method of `AbstractBaseUser`, has
objects = UserManager()
--
Comment (by Tim Graham):
Can you propose a patch for Django?
--
Ticket URL: <https://code.djangoproject.com/ticket/28594#comment:1>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: contrib.auth | Version: 1.11
Severity: Normal | Resolution:
Keywords: Value error, user | Triage Stage:
model, normalize_username | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* Attachment "28594.diff" added.
patch based on git master
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: contrib.auth | Version: 1.11
Severity: Normal | Resolution:
Keywords: Value error, user | Triage Stage:
model, normalize_username | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Axel Rau):
The attached trivial patch 28594.diff works for me with Django 1.11.4 on
Python 3.5.3
--
Ticket URL: <https://code.djangoproject.com/ticket/28594#comment:2>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: contrib.auth | Version: 1.11
Severity: Normal | Resolution:
model, normalize_username |
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_better_patch: 0 => 1
* has_patch: 0 => 1
* needs_docs: 0 => 1
* stage: Unreviewed => Accepted
Comment:
At the very least this should use `six.string_types` on 1.x branches. But
I think this is a documentation issue. If you change the type of the
username field, then you should reimplement normalize_username or prevent
it being called.
However, Django's documentation says:
:attr:`USERNAME_FIELD` now supports
:class:`~django.db.models.ForeignKey`\s. Since there is no way to
pass
model instances during the :djadmin:`createsuperuser` prompt,
expect the
user to enter the value of
:attr:`~django.db.models.ForeignKey.to_field`
value (the :attr:`~django.db.models.Field.primary_key` by default)
of an
existing instance.
The current behavior of `clean()` and `UserManager._create_user()` does
not support foreign keys as it should expect to be handed model instances
and not call `normalize_username` or as the patch suggests,
`normalize_username` should only act on strings.
--
Ticket URL: <https://code.djangoproject.com/ticket/28594#comment:3>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: contrib.auth | Version: 1.11
Severity: Normal | Resolution:
Keywords: Value error, user | Triage Stage: Accepted
model, normalize_username |
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* Attachment "28594.diff" added.
git diff of documentation patch
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: contrib.auth | Version: 1.11
Severity: Normal | Resolution:
Keywords: Value error, user | Triage Stage: Accepted
model, normalize_username |
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Axel Rau):
I agree, that this is a corner case and can be prevented by a hint in the
documentaion.
My proposal of the doc enhancement is attached. It replaces my original
code patch.
--
Ticket URL: <https://code.djangoproject.com/ticket/28594#comment:4>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: contrib.auth | Version: 1.11
Severity: Normal | Resolution: fixed
Keywords: Value error, user | Triage Stage: Accepted
model, normalize_username |
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"23b21db31bfcf2a065d485617412cca43a311a4c" 23b21db3]:
{{{
#!CommitTicketReference repository=""
revision="23b21db31bfcf2a065d485617412cca43a311a4c"
Fixed #28594 -- Removed Jython docs and specific code
Thanks Andrey Martyanov for the reporti, and Tim Graham for the review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28594#comment:5>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: contrib.auth | Version: 1.11
Severity: Normal | Resolution: fixed
Keywords: Value error, user | Triage Stage: Accepted
model, normalize_username |
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Claude Paroz <claude@…>):
In [changeset:"830636df739d359116e3106c35375ac838bf15c3" 830636d]:
{{{
#!CommitTicketReference repository=""
revision="830636df739d359116e3106c35375ac838bf15c3"
[2.0.x] Fixed #28594 -- Removed Jython docs and specific code
Thanks Andrey Martyanov for the report, and Tim Graham for the review.
Backport of 23b21db31bfcf2a065d485617412cca43a311a4c from master.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28594#comment:6>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: contrib.auth | Version: 1.11
Severity: Normal | Resolution:
model, normalize_username |
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: fixed =>
Comment:
Sorry, I referred to the wrong commit in my patch above.
--
Ticket URL: <https://code.djangoproject.com/ticket/28594#comment:7>
Django
-------------------------------------+-------------------------------------
| Mládek
Type: Bug | Status: assigned
Severity: Normal | Resolution:
Keywords: Value error, user | Triage Stage: Accepted
model, normalize_username |
Has patch: 1 | Needs documentation: 1
-------------------------------------+-------------------------------------
* owner: nobody => Michal Mládek
* status: new => assigned
Comment:
I will do some research here, but it seems done or old or unclosed ...
--
Ticket URL: <https://code.djangoproject.com/ticket/28594#comment:5>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: Value error, user | Triage Stage: Accepted
model, normalize_username |
Has patch: 1 | Needs documentation: 1
-------------------------------------+-------------------------------------
* owner: Michal Mládek => (none)
* status: assigned => new
Comment:
Hi, and thanks for the opportunity to look into this ticket.
It seems that the issue has already been addressed in some form (e.g. via
documentation updates), and it may have just been left open by oversight.
In any case, the problem is no longer present in supported Django versions
— as of 3.0, using a ForeignKey for USERNAME_FIELD is unsupported.
Given that, I would suggest closing this ticket as either resolved or
invalid, unless there’s still something outstanding I may have missed.
--
Ticket URL: <https://code.djangoproject.com/ticket/28594#comment:6>