#26502 closed Uncategorized (invalid)
Lookup of attribute 'id' on model inheritance models in InlineModelAdmin fails when using fk_name of parent model
| Reported by: | Waldemar Hamm | Owned by: | nobody | 
|---|---|---|---|
| Component: | Forms | Version: | 1.8 | 
| Severity: | Normal | Keywords: | id, model inheritance, inherited model, inline | 
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no | 
| Needs tests: | no | Patch needs improvement: | no | 
| Easy pickings: | no | UI/UX: | no | 
Description (last modified by )
Having two models, of which one inherits from another, for example:
class Person(models.Model):
    firstname = models.CharField(max_length=255, blank=True)
    lastname = models.CharField(max_length=255)
    person_something = models.ForeignKey(Something)
class Author(Person):
    publisher = models.CharField(max_length=255)
    author_something = models.ForeignKey(Something)
I can't access the id field like so:
class AuthorInline(admin.StackedInline):
    model = Author
    fk_name = 'person_something'
    fields = ['id', 'lastname', 'publisher']
    readonly_fields = fields
class SomethingAdmin(admin.ModelAdmin):
    inlines = [ AuthorInline ]
    list_display = ('somethinga', 'somethingb')
I get a KeyError and it says:
"Key 'id' not found in 'AuthorForm'"
Using Author._meta.get_all_field_names() the field id is definitely in the model, though. Removing 'id' from the fields list makes everything work. 
Am I doing something wrong or is this a legit bug?
Change History (15)
comment:1 by , 10 years ago
| Description: | modified (diff) | 
|---|---|
| Summary: | Lookup of attribute 'id' on model inheritance models in InlineModelAdmin fails → Lookup of attribute 'id' on model inheritance models in InlineModelAdmin fails when using fk_name of parent model | 
comment:2 by , 10 years ago
| Description: | modified (diff) | 
|---|
comment:3 by , 10 years ago
comment:5 by , 10 years ago
| Component: | contrib.admin → Forms | 
|---|---|
| Resolution: | → invalid | 
| Status: | new → closed | 
comment:7 by , 10 years ago
| Resolution: | invalid | 
|---|---|
| Status: | closed → new | 
I tried using your suggestion but changing 'id' to 'person_ptr' in fields doesn't make the actual field appear within the admin object view.
It just resolved the error so the view appears at all. Why isn't the id/person_ptr field displayed?
comment:8 by , 10 years ago
| Resolution: | → invalid | 
|---|---|
| Status: | new → closed | 
It's not an editable field as described in #11097. We might add some clarifying documentation as part of that ticket.
comment:9 by , 10 years ago
It's true that it is not visible in the example code I'm providing but actually I am using all of the provided fields as read_only fields. It's still not visible.
Is this also intended?
comment:10 by , 10 years ago
Not sure, you should provide your actual code. That said, "is it a bug?" questions are better handled through our support channels.
comment:11 by , 10 years ago
| Description: | modified (diff) | 
|---|
comment:12 by , 10 years ago
I changed the Inline class to reflect what I'm talking about.
The person_ptr field is not displayed in the admin form as a readonly_field as well.
And even though it may not be a field that you are able to edit, using it as readonly_field and not being able to see it is, from my point of view, either a bug or doesn't follow the intuitive logic.
I asked if this was a bug, because I may not fully comprehend the full code logic behind Django, since I just started using it half a year ago. Now that I know that *_ptr is the field I am looking for and that the only limitation to it is not being editable I understand this situation as a bug.
comment:13 by , 10 years ago
| Resolution: | invalid | 
|---|---|
| Status: | closed → new | 
comment:14 by , 10 years ago
| Resolution: | → invalid | 
|---|---|
| Status: | new → closed | 
The issue is that the field uses a hidden widget by default so the HTML uses a "hidden" CSS class triggered by Fieldline.has_visible_field. You could likely change the widget in a custom admin form to workaround this.
It might make sense to try to allow readonly_fields to override override the widget automatically, but I'm not sure if a solution is feasible or if it might cause some other problems. In any case, let's open a separate ticket if you want to pursue such a solution since we've deviated quite a bit from the original report. Thanks.
comment:15 by , 10 years ago
Thank you for clarifying this, I wouldn't have found out about this so quick :).
I will try to create a custom admin form then and not pursue this any further for now. Thank you again, very much.
I think you need to use
person_ptrin thefieldslist rather thanid. I created a PR to add the list of possible fields to theKeyErrormessage which would hopefully have helped you debug this. In this case, it adds "Choices are: DELETE, lastname, person_ptr, person_something, publisher."