Override multiple fieldsets of base_fieldsets?

[Lorac]

I have a model with extra fields but I would like to show these extra fields inside already existing fieldsets from the form base class.

I was able to do it with something like

def merge_by_key(ts):

    dic = {}
    for i, j in ts:
        dic.setdefault(i,{}).setdefault('fields', ())
        dic[i]['fields'] += tuple(j['fields'])

    return tuple((k, v) for k, v in dic.items())

I can only override one section here because it's based on the extra_fieldset_title

This doesn't control where the fields end up in the fieldsets.

If I use extra_fieldset_title with the same name, well I just get 2 fieldsets with the same names.

For a case like this, should I just fully override base_fieldsets for each subclasses? Which is kind of annoying.

[bckohan]

You don’t need to fully override base_fieldsets per child (and I agree: that’s annoying). The cleaner pattern is:

• keep the base fieldset layout as the “source of truth”
• let each child contribute patches that say which existing fieldset to inject fields into (and optionally where inside that fieldset)
• apply the patches in get_fieldsets() (or wherever polymorphic admin builds them), so ordering is deterministic and you never get duplicate titled fieldsets.

Why your merge-by-title approach hits a wall

• Titles aren’t unique identifiers in Django’s fieldsets (they’re just labels).
• Merging “by key” doesn’t solve placement, only deduping.
• Using the same title creates two separate fieldset entries unless you actively merge them and decide ordering.

A practical “fieldset patch” approach

1) In your base admin, define your canonical fieldsets

class ProductAdmin(PolymorphicParentModelAdmin):
    base_fieldsets = (
        ("Basics", {"fields": ("name", "sku", "price")}),
        ("Inventory", {"fields": ("in_stock", "qty")}),
        ("Meta", {"fields": ("created_at", "updated_at")}),
    )

2) In each child admin, declare injection rules

Use a structure like:

• fieldset_injections = { "<fieldset name>": {"append": (...), "prepend": (...), "after": {"field": (...)} } }

Example:

class PhoneTabletsAdmin(PolymorphicChildModelAdmin):
    fieldset_injections = {
        "Basics": {"after": {"sku": ("screen_size", "ram_storage")}},
        "Inventory": {"append": ("battery_capacity",)},
    }

3) Apply those rules in a helper used by get_fieldsets()

def _as_list(x):
    return list(x) if isinstance(x, (list, tuple)) else [x]

def inject_fields_into_fieldsets(fieldsets, injections):
    """
    fieldsets: iterable of (name, opts) where opts["fields"] is tuple/list
    injections: mapping of name -> directives
    """
    out = []
    for name, opts in fieldsets:
        opts = dict(opts)
        fields = list(opts.get("fields", ()))

        inj = injections.get(name)
        if inj:
            # prepend
            if "prepend" in inj:
                fields = _as_list(inj["prepend"]) + fields

            # insert after a specific field
            after = inj.get("after", {})
            for anchor, new_fields in after.items():
                if anchor in fields:
                    idx = fields.index(anchor) + 1
                    fields[idx:idx] = _as_list(new_fields)
                else:
                    # fallback: append if anchor not present
                    fields.extend(_as_list(new_fields))

            # append
            if "append" in inj:
                fields.extend(_as_list(inj["append"]))

        opts["fields"] = tuple(fields)
        out.append((name, opts))
    return tuple(out)

Then in your child admin (or a shared mixin), do:

class InjectingChildAdmin(PolymorphicChildModelAdmin):
    fieldset_injections = {}

    def get_fieldsets(self, request, obj=None):
        fieldsets = super().get_fieldsets(request, obj=obj)
        return inject_fields_into_fieldsets(fieldsets, self.fieldset_injections)

Now each child only declares what it adds and where, and your base fieldset structure stays centralized.

---

What if the “fieldset name” isn’t stable?

If you’re worried about names being translated or changed, you can instead target by fieldset index (e.g. 0, 1, 2) or by a sentinel field inside the fieldset (find the fieldset that contains "sku" and inject relative to that). That’s often even more robust than titles.

---

So: should you override base_fieldsets per subclass?

Only if the child needs a genuinely different layout. If the layout is shared and you’re just sprinkling extra fields into existing sections, the injection/patch approach is the sweet spot: minimal boilerplate, deterministic placement, and no duplicate titled fieldsets.