#21084 closed Bug (fixed)
Wrong resolution of content type id for proxy models in ModelAdmin
Reported by: | alejandro | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | 1.5 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
I have a number of proxy models that I want to present separately in the admin interface. A simplified example would be:
class Accommodation(models.Model): name = models.CharField(max_length=10) class Inn(Accommodation): class Meta: proxy = True class Hotel(Accommodation): class Meta: proxy = True admin.site.register(Inn) admin.site.register(Hotel)
However, due to how ModelAdmin
gets the content type of the models the retrieved content type instances will always be those corresponding to Accommodation
. This causes several problems:
- The log entries shown in the admin index will have broken links because log entries have the content type id of
Accommodation
instead ofInn
orHotel
. - In the change form, the
content_type_id
context variable will be the one ofAccommodation
content type, causing the "View on site" link not to work.
I'm not sure wether there are more cases where getting the content type from the concrete model breaks things in the admin. A naive fix would be to pass for_concrete_model=False
for every ContentType.objects.get_for_model
call in ModelAdmin
code but I'm not aware of the consequences of that since I'm not familiar enough with Django internals.
Change History (8)
comment:1 by , 11 years ago
Has patch: | set |
---|---|
Needs tests: | set |
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 11 years ago
Needs tests: | unset |
---|---|
Patch needs improvement: | set |
As noted in the comments on github, the proposed pull request needs improvement.
comment:4 by , 11 years ago
I've written an updated patch and submitted a PR: https://github.com/django/django/pull/2518
comment:5 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Here is a PR for a duplicate ticket (#21260). Like the OP, I haven't look into whether or not this is the best fix and it also lacks tests.