Changes between Initial Version and Version 1 of Ticket #10108


Ignore:
Timestamp:
Jan 23, 2009, 12:09:33 AM (15 years ago)
Author:
Karen Tracey
Comment:

I believe you can set up admin inlines for items related by OneToOne (though you're limited to one in the inline "list"), so I don't think we can change the function you mention to simply not consider OneToOnes candidates. Maybe the auto-added OneToOnes that come with inheritance, but the combination of inheritance and inlines in the admin makes my head spin (not helped by the fact that it is late night here), so input from someone who better understands admin, inheritance, and inlines and how they all fit together would help. I'm not sure it would make sense to always disallow the auto-added OneToOne as being the parent link for an inline model?

If not and in the meantime even if so, you can specify an fk_name (​http://docs.djangoproject.com/en/dev/ref/contrib/admin/#fk-name) for your inline model admin: 

class CPUInline(admin.TabularInline):
    model = CPU
    fk_name = 'computer'

That will tell the admin which ForeignKey to use for the parent link. And then you will need the patch on #10075 to fix the Cannot assign None: "CPU.item_ptr" does not allow null values error you will get if you try to save a computer with a newly-added inline CPU.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #10108 – Description

    initial v1  
    1414}}}
    1515
    16 This is caused by the OneToOne field created implicitly by the inheritance as mentioned on http://docs.djangoproject.com/en/dev/ref/models/fields/#onetoonefield conflicting with the defined ForeignKey on the model. This leads to unexpected behaviour as it is expected that the single defined ForeignKey field is used in the admin form. The error appears to be caused by the _get_foreign_key function in forms/models.py which uses isinstance(f, ForeignKey) on the fields on the model with the ForeignKey to find which field to use but this returns true on OneToOne fields, not just ForeignKey fields.
     16This is caused by the !OneToOne field created implicitly by the inheritance as mentioned on http://docs.djangoproject.com/en/dev/ref/models/fields/#onetoonefield conflicting with the defined !ForeignKey on the model. This leads to unexpected behaviour as it is expected that the single defined !ForeignKey field is used in the admin form. The error appears to be caused by the _get_foreign_key function in forms/models.py which uses `isinstance(f, ForeignKey)` on the fields on the model with the !ForeignKey to find which field to use but this returns true on !OneToOne fields, not just !ForeignKey fields.
    1717
    1818A traceback of the error is available at http://dpaste.com/112033/.
Back to Top