How to handle non-admin polymorphic forms?

[ShaheedHaque]

Let say I have an Employee model like this:

class Employee(models.Model):
    employee_id = models.CharField(...)
    company = models.ForeignKey(Company, ...)

and I'd like to attach a polymorphic address (to handle country-specific addressing rules). I create a "base" polymorphic class which contains a read-only "jurisdiction" like this:

class PostalDetail(PolymorphicModel):
    jurisdiction = models.CharField(max_length=ISO3166_MAX_LENGTH, editable=False)
    employee = models.ForeignKey(Employee, on_delete=models.CASCADE)
    line1 = models.CharField(max_length=LINE_MAX_LENGTH, help_text=_("First line of address"))
    ...

I can now define subclasses of PostalDetail to cover GB, US, whatever. Depending on which subclass it is, I can programmatically fill in the jurisdiction (based, as it happens, on the subclass model name). Now, using the admin facilities provided by django-polymorphic, I can create an admin interface based on PostalDetail that will let me create records of GB or US-specific flavours.

However, I'm left wondering how to create non-admin forms, like normal Django model forms, to create these addresses. I can see the formset support, but some guidance/exmaples/hints on how to proceed without formsets would be welcome.

(That would allow me to merge the PostalDetails into a polymorphic Employee.)

[vdboor]

Like the admin, you could offer a "choice" view first to select which type you're adding. In the next view, use a CreateView / FormView with an overridden get_form_class() that returns the correct form.

In case of address support, you could also look how django-oscar has done this. They have generalized it into line1, line2 and line3 fields to support all possible addreses. See: https://github.com/django-oscar/django-oscar/blob/master/src/oscar/apps/address/abstract_models.py

A Google search also reveals different packages that might solve the problem for you: https://github.com/furious-luke/django-address

[ShaheedHaque]

Thanks for the kind reply.

I ended up using the "choose a subtype" approach. Given that my actual problem involves 6-10 polymorphic bases, with perhaps half having 10+ subclasses, I needed a generic solution (and not just for the one case of multi-jurisdictional addresses!).

The nub of the problem is that the use of IDs from content_types obviously prevents them being used across machines and time. I needed the "user mode" stability of an explicit tag, i.e the "jurisdiction" in the example above. That, combined with the support polymorphic provides to handle filling in the polymorphic_ctype allowed the solution to be generic.

(Plus a bunch of analogous logic to handle fk lookups and the like).

When I say generic, I'd like to have been able to contribute it here, but I fear the tag and FK lookup logic isn't really portable. Having some stable way to use polymorphic_ctype would have made that more tractable I think.

[ShaheedHaque]

I propose to leave this issue open, based on the last point about needing a stable version of polymorphic_ctype. Without that, import/export/archive is not directly possible in a portable-across-time-and-machjne sense.

[bckohan]

@ShaheedHaque You can avoid using the polymorphic_ctype by using the Class object of the model instead. In version 5 polymorphic_ctype is going away so using the Class as an enumeration is the best bet. The example added in #749 shows how to use the model label instead of the ctype id.

[ShaheedHaque]

Thanks for the heads-up. Is there an ETA for version 5?

…

On Wed, 7 Jan 2026 at 03:45, Brian Kohan ***@***.***> wrote: @ShaheedHaque <https://github.com/ShaheedHaque> You can avoid using the polymorphic_ctype by using the Class object of the model instead. In version 5 polymorphic_ctype is going away so using the Class as an enumeration is the best bet. The example <https://django-polymorphic.readthedocs.io/en/latest/views.html> added in #749 <#749> shows how to use the model label instead of the ctype id. — Reply to this email directly, view it on GitHub <#801 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFHWKIEIMRMLFRTR3LOXH34FR6MLAVCNFSM6AAAAACQ42J2YKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBTGAZDENQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** .com>

[bckohan]

No ETA. As I can get to it.

[ShaheedHaque]

FWIW, I have reviewed the changes and the discussion, and since my code already uses the class name I think it is nicely aligned with the recommended way forward. Thanks for looking into this and formalising this as the way forward.

[bckohan]

Thanks @ShaheedHaque - if you think this was satisfactorily answered would you please mark the answer as accepted?