Cached properties in CableTermination not updated

[mzbroch]

NetBox version

v3.3-beta

Python version

3.8

Steps to Reproduce

1. Populate NetBox with the data mandatory for adding two different Devices: Manufacturer, Device Type, Site (site1), ...
2. Create two devices ("device1", "device2"), each having set of interfaces ("intf[1-5]") - assign devices to site1.
3. Connect intf1 of device1 to intf1 of device2
4. Navigate to cable list view (connections), check out the assigned site - expected site1
5. Create a new site (site2)
6. Edit device1 and device2 - change site to site2
7. Navigate to cable list view (connections), check out the assigned site - expected site2

Expected Behavior

Respective cable between intf1 and intf1 (in a cables list view (connections)) shows site2 as it replaced site1

Observed Behavior

Respective cable between intf1 and intf1 (in a cables list view (connections)) shows cached (invalid) site site1

[jeremystretch]

Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.

[mzbroch]

Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior.

Updated the report.

[jeremystretch]

This looks like a typical denormalization issue, where we just need the cached values up to date. We could handle this with dedicated signal receivers as we do elsehwere in NetBox, but it's probably worth investigating more robust solutions.