Opened 3 years ago

Last modified 3 years ago

#28594 new Bug

Value error on related user name during save of user model

Reported by: Axel Rau Owned by: nobody
Component: contrib.auth Version: 1.11
Severity: Normal Keywords: Value error, user model, normalize_username
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description (last modified by Tim Graham)

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.
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.
Overwriting this with a method which just returns the 'username' fixes the problem.


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'

   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+ '@'

Internal Server Error: /admin/erdb/account/19/change/
Traceback (most recent call last):
 File "...python3.5/site-packages/django/core/handlers/", line 41, in inner
   response = get_response(request)
 File "...python3.5/site-packages/django/core/handlers/", line 249, in _legacy_get_response
   response = self._get_response(request)
 File "...python3.5/site-packages/django/core/handlers/", line 187, in _get_response
   response = self.process_exception_by_middleware(e, request)
 File "...python3.5/site-packages/django/core/handlers/", line 185, in _get_response
   response = wrapped_callback(request, *callback_args, **callback_kwargs)
 File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/", line 30, in inner
   return func(*args, **kwds)
 File "...python3.5/site-packages/django/contrib/admin/", line 551, in wrapper
   return self.admin_site.admin_view(view)(*args, **kwargs)
 File "...python3.5/site-packages/django/utils/", line 149, in _wrapped_view
   response = view_func(request, *args, **kwargs)
 File "...python3.5/site-packages/django/views/decorators/", line 57, in _wrapped_view_func
   response = view_func(request, *args, **kwargs)
 File "...python3.5/site-packages/django/contrib/admin/", line 224, in inner
   return view(request, *args, **kwargs)
 File "...python3.5/site-packages/django/contrib/admin/", line 1511, in change_view
   return self.changeform_view(request, object_id, form_url, extra_context)
 File "...python3.5/site-packages/django/utils/", line 67, in _wrapper
   return bound_func(*args, **kwargs)
 File "...python3.5/site-packages/django/utils/", line 149, in _wrapped_view
   response = view_func(request, *args, **kwargs)
 File "...python3.5/site-packages/django/utils/", line 63, in bound_func
   return func.__get__(self, type(self))(*args2, **kwargs2)
 File "...python3.5/site-packages/django/contrib/admin/", line 1408, in changeform_view
   return self._changeform_view(request, object_id, form_url, extra_context)
 File "...python3.5/site-packages/django/contrib/admin/", line 1440, in _changeform_view
   if form.is_valid():
 File "...python3.5/site-packages/django/forms/", line 183, in is_valid
   return self.is_bound and not self.errors
 File "...python3.5/site-packages/django/forms/", line 175, in errors
 File "...python3.5/site-packages/django/forms/", line 386, in full_clean
 File "...python3.5/site-packages/django/forms/", line 408, in _post_clean
   self.instance.full_clean(exclude=exclude, validate_unique=False)
 File "...python3.5/site-packages/django/db/models/", line 1234, in full_clean
 File "...python3.5/site-packages/django/contrib/auth/", line 77, in clean
   setattr(self, self.USERNAME_FIELD, self.normalize_username(self.get_username()))
 File "...python3.5/site-packages/django/db/models/fields/", line 216, in __set__
ValueError: Cannot assign "''": "Account.localemail" must be a "Mailbox" instance.
[21/Aug/2017 16:08:37] "POST /admin/erdb/account/19/change/ HTTP/1.1" 500 166385


Attachments (1)

28594.diff (844 bytes) - added by Axel Rau 3 years ago.
git diff of documentation patch

Download all attachments as: .zip

Change History (5)

comment:1 Changed 3 years ago by Tim Graham

Description: modified (diff)

Can you propose a patch for Django?

comment:2 Changed 3 years ago by Axel Rau

The attached trivial patch 28594.diff works for me with Django 1.11.4 on Python 3.5.3

comment:3 Changed 3 years ago by Melvyn Sopacua

Has patch: set
Needs documentation: set
Patch needs improvement: set
Triage Stage: UnreviewedAccepted

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.

Changed 3 years ago by Axel Rau

Attachment: 28594.diff added

git diff of documentation patch

comment:4 Changed 3 years ago 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.

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