#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
Accommodationinstead ofInnorHotel. - In the change form, the
content_type_idcontext variable will be the one ofAccommodationcontent 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 , 12 years ago
| Has patch: | set |
|---|---|
| Needs tests: | set |
| Triage Stage: | Unreviewed → Accepted |
comment:3 by , 12 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 , 12 years ago
I've written an updated patch and submitted a PR: https://github.com/django/django/pull/2518
comment:5 by , 12 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.