createsuperuser in interactive mode assumes USERNAME_FIELD is unique

[Carl Meyer]

The checks framework allows for the possibility that you have a custom User model with a non-unique USERNAME_FIELD, as long as you're using a custom authentication backend that's able to handle that situation. But the createsuperuser management command (in interactive mode) always queries to see if the username you enter is already in use, and won't let you proceed if it is.

Instead, createsuperuser should check whether USERNAME_FIELD is actually a unique field, and only do the check if it is.

[Daniel Ward]

According to documentation on customising authentication, the USERNAME_FIELD must point to a field which holds unique values. Furthermore, the check framework will raise auth.W004 in the event of the field being non-unique. I'd suggest, therefore that the createsuperuser management command correctly works within the realm of this restriction regardless of any custom authentication backend.

Please see supportive documentation below:

​https://docs.djangoproject.com/en/dev/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD
​https://docs.djangoproject.com/en/dev/ref/checks/#auth

[Carl Meyer]

Yes, there is currently some documentation stating that USERNAME_FIELD must be a unique field.

However, the auth checks have clearly been written with the intent to allow a non-unique USERNAME_FIELD, as long as you are using a custom authentication backend. That's why there is both auth.E003 and auth.W004. The former is an error, raised if you have a non-unique USERNAME_FIELD and you are using the default authentication backend (which requires USERNAME_FIELD to be unique). The latter is merely a warning, raised if you have a non-unique USERNAME_FIELD and are using a custom authentication backend; the warning just reminds you that you need to ensure your custom backend can handle non-unique USERNAME_FIELD in some appropriate way.

I don't think there is any reason not to allow the latter usage, for advanced and unusual cases. So I think that a) createsuperuser should be updated to only enforce uniqueness if the field is actually unique, and b) the USERNAME_FIELD doc you linked should be updated to clarify that a non-unique USERNAME_FIELD is permissible as long as you are using a custom auth backend that can handle it.

[Alasdair Nicol]

Pull request ​https://github.com/django/django/pull/4812

[Tim Graham <timograham@…>]

In 1ea87c8:

Fixed #24910 -- Added createsuperuser support for non-unique USERNAME_FIELDs

Clarified docs to say that a non-unique USERNAME_FIELD is permissable
as long as the custom auth backend can support it.