Polymorphic multi-object through tables aren't copied into branches, so branch changes write to main #839

Plugin Version

v0.7.0

NetBox Version

v4.7.3

Python Version

3.12

Steps to Reproduce

With netbox-branching 1.2.2 installed:

1. In main, create a Custom Object Type with a polymorphic multi-object field targets whose related object types include dcim.Site.
2. Create two sites and one custom object, and assign both sites to targets.
3. Create and provision a branch.
4. Activate the branch, remove one site from the custom object's targets, and leave the branch.
5. Check the custom object's targets in main.

Then repeat steps 1 to 3, delete the targets field inside the branch, and read the field in main.

Expected Behavior

The branch has its own copy of the field's through table, so changes made in the branch stay in the branch until it's merged.

Observed Behavior

The through table (custom_objects_<id>_targets) is never created in the branch schema, so branch-side changes go to main's table instead.

After step 4, main has lost the removed site (2 rows before, 1 after) without a merge.

Deleting the field inside the branch drops main's table. Main still has the field, but any access fails:

ProgrammingError: relation "custom_objects_68_targets" does not exist

Non-polymorphic multi-object fields are not affected: their through table is copied into the branch, and a branch-side field delete drops only the branch copy.

Suspected Cause

netbox-branching copies a branchable model's table plus the through tables of its _meta.local_many_to_many (get_tables_to_replicate(), netbox_branching/utilities.py:295-315). A polymorphic multi-object field isn't an M2M field on _meta, so its through table is skipped. The branch connection uses search_path=<branch>,public (utilities.py:111), so every query against that table, including the DROP TABLE in drop_polymorphic_m2m_table() (field_types.py:2082), resolves to main's table.

netboxlabs/netbox-branching#683 is the same fall-through to main from a different trigger. #838 is a separate problem with branch-side field deletes.

Proposed Fix

No response