id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 19844 Uniqueness validation of USERNAME_FIELD should be overridable. josh@… nobody "The resolution of #19822 by commit bc6746ac303ab625f2bc6fc878bd63661c784a59 introduces validation of the uniqueness of the specified USERNAME_FIELD in a way that cannot be (easily?) overridden. This is probably a good default behavior, however it breaks in any cases where you may not want unique usernames. The discussion on the original ticket clearly assumes that having non-unique usernames is an inherently bad design decision. This may very well be true, but, as I'm sure we're all aware, the exigencies of web development do not always allow us to restrict ourselves to good design decisions. As a specific example, I am working on a site that is required to integrate with a legacy system. The requirements for the project are such that it is necessary for us to preserve the user information from the legacy system faithfully. As such, this requires us to, among other things, allow the users to log in with nothing more than their email address and password (easily done), and allow for the possibility that multiple people will use the same email address while still needing to have unique user accounts (a pain, but not horribly difficult). The enforced design decision introduced by bc6746ac303ab625f2bc6fc878bd63661c784a59 unfortunately means that we either need to fork Django to keep that commit out of our codebase, hack around the validation by designating some field other than the email address our USERNAME_FIELD, or restrict ourselves to older code that does not have this restriction. It seems to me that a much better solution would be to not unnecessarily restrict the flexibility introduced by swappable user models, and make this the default, but still changeable, behavior." Cleanup/optimization closed contrib.auth dev Normal fixed gsoc2013-checks chris.jerdonek@… Accepted 0 0 0 0 0 0