New admin formfield_for_dbfield doesn't play nice with subclassing

[Alex Gaynor]

If you subclass a model field you don't get to keep the admin widgets unless you readd them to the formfield overides.

[Alex Gaynor]

use the mro

[Jacob]

Wow, I never knew mro existed. Learn something new every day.

[Jacob]

I'm really not sure this patch is needed. ModelAdmin.init already applies self.formfield_overrides *over* the defaults, so I don't quite see what the point is here. Plus, the description of the ticket implies something about custom model fields, which I don't quite get either.

I'm kicking this back to accepted; we need more details from the original poster about what he's trying to do and what's broken here.

[Tai Lee]

I hit this problem as well. The ModelAdmin.formfield_for_dbfield refactor in [9760] changed behaviour by using a dict key lookup instead of isinstance() to map model fields to form fields and widgets.

Previously if you had subclassed DateTimeField (for example as AUDateTimeField to use Australian format date input formats by default), formfield_for_dbfield() would still see it as a DateTimeField and use the SplitDateTimeField form field and AdminSplitDateTime form widget.

Now you need to explicitly add an item to ModelAdmin.formfield_overrides for every model that uses your custom AUDateTimeField, which seems to defeat the purpose of using a custom model field with a different default input format and violates DRY.

This patch should restore the existing behaviour from before the refactor and will still allow users to add their own mapping if in fact they do want to use their own form field or widget instead of the admin default.

[Tai Lee]

I couldn't apply this patch easily with the patch app. I'm not sure if that is because the diff was created with the wrong tool (diff --git as opposed to svn diff), or with the wrong base path ("a"), or is just not understood by patch because it includes the diff statement in the first line.

Whatever the reason, I applied it manually and ran the tests (before and after) and they do demonstrate the problem and show that it is fixed, so I'm changing the "needs tests" flag.

[Tai Lee]

Patch created with svn diff with correct root.

[Julien Phalip]

I applied the patch and I confirm that it fixes the bug I described in: ​http://groups.google.com/group/django-users/browse_thread/thread/ffd3d498724fd0a1

+1 for checking this in.

[Jacob]

Fixed in r10454.

[Jacob]

Milestone 1.1 deleted