Username Independence in Auth Forms

[gavi...@gmail.com]

Some of the built-in auth forms only work on user models whose `USERNAME_FIELD` is `username`. It is possible to remove this constraint and allow them work on any user model. [django-authtools][1] demonstrates this possibility.

The two forms in question are `UserCreationForm` and `UserChangeForm`.  Both of them explicitly add a `username` field instead of letting the ModelForm add it automatically. For `UserChangeForm`, simply removing the `username` field from the form achieves user-model independence. `UserCreationForm` is slightly more complicated, due to the `clean_username` method. `clean_*` methods have to be named after their field, so it's hard to add one when you don't know the name of the field. This can be overcome by adding a validator to the field while initializing the form [2].

The reason the forms do have a `username` field currently is to change the help text, validation error messages, and validators. I don't think this should happen in the form, because all of these can be set on the model field instead. This could cause a backwards-compatibility concern if someone wasn't validating usernames in their custom User model (they are already validated in `auth.User`), and relied on the form instead. I don't think this is a serious issue--it only occurs if someone is using a custom User model, using the built-in forms, and not doing any username validation in their model.

If this approach sounds reasonable, I will submit it in the form of a patch.

[1]: https://github.com/fusionbox/django-authtools/blob/master/authtools/forms.py

[2]: https://github.com/fusionbox/django-authtools/blob/master/authtools/forms.py#L61

[Aymeric Augustin]

On 3 juin 2013, at 20:01, gavi...@gmail.com wrote:

> Some of the built-in auth forms only work on user models whose `USERNAME_FIELD` is `username`.

Hi Gavin,

The current code assumes that if you write a custom model, you'll also write the corresponding custom forms.

You may want to have a look at https://code.djangoproject.com/ticket/19353 which describes the same problem (as far as I can tell).

--
Aymeric.

[Gavin Wahl]

> The current code assumes that if you write a custom model, you'll also write the corresponding custom forms.

Right. This is what I am proposing be fixed.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/XxaZ50SxPj4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[ptone]

Really what you are proposing is an extension of the scope #19353, and I do feel that if the built in forms are to be made more usable with custom users, then both the hardcoding of auth.User and the username field should be addressed together.

One thing not addressed in your authtools approach that is done in the current RegexField of the builtin form is handling regex validation of valid usernames - if your custom user requires some other sort of validation, you have to hook up some sort of custom validator like you've done, which seems like more work than just creating a custom form where you can define the fields as you need them. Also you may not need or want all REQUIRED_FIELDS in your form - this is a somewhat unfortunate label for this property - as it is really more specific to the management command prompts (ie, you can specify a field as required in the model, but not include it in that list, or vs versa).

A good step here might be a little DDD, write the docs to cover the cases where you may need to work around this proposed flexible approach - if it seems like it gets too complicated to explain, perhaps just leaving it documented as requiring the author to create new forms (which is more work, but maybe more straightforward) - may still be the best choice.

If this can be done in a way that maximizes win, I'm all for it, but if it is trading less work in some cases, for more in others, I'm less sure.

-Preston