Editing an unterminated cable throws exception

[dutchman80]

NetBox version

v3.4.0

Python version

3.9

Steps to Reproduce

1. Create Device-A with Interface
2. Create Device-B with Interface
3. Connect Device-A to Device-B via their interfaces. Cable-1 is automatically created
4. Delete Device-A
5. Navigate to view for Cable-1 and hit the "Edit" button

Expected Behavior

The "Edit" view for the cable is displayed

Observed Behavior

<class 'AttributeError'>

'str' object has no attribute 'label'

[jeremystretch]

The error occurs during form rendering because we're unable to determine the type of the A side connection when no A side terminations exist. I'm not sure there's any particularly clever solution to this, however it may be rendered moot depending on what changes (if any) we decide to make with respect to #10769. I'm going to mark this as blocked for now pending the outcome of that issue.

[DanSheps]

So, I keep hitting this, and I am wondering if it wouldn't be worth it to turn every "interface" into a polymorphic object (yes, I am bringing up polymorphism again. :D)

The advantage, is we could likely do-away with multiple forms for connecting interfaces, front/rear ports, etc and just point to a "Connection Point" base class, which would hold the PK for whatever it morphs into (FrontPort). This would allow us to simplifiy the cable create form by consolidating the form creation logic into a single DynamicModelChoiceField.

We then wouldn't need to "determine" what type of connection we are making, we just need to allow you to connect to perhaps a base connection type (power only to power). Just a thought.

The only problem is it looks like django-polymorphic is abandoned right now.

[jeremystretch]

Just noting that this remains an active bug and has not been resolved by #13337.

[DanSheps]

I can take a look at this tomorrow or during the week if no one gets to it.

I think it has to do with the way the dynamic forms are created but not 100% sure. It is something I have been meaning to dive into.

[AravindhStanley]

Can we atleast make the terminations on both sides as mandatory input fields? I have few users that update one side of the cable and not the other. Maybe it can atleast help with such scenarios?

[DanSheps]

I might play around with the cable termination form (and by extension HTMX) to see if I can get this working to an acceptable level.

I believe that might be the only way forward for this one, as it is hard to determine the type of cable when it doesn't exist at all.
😄

[jschewebbn]

I will say that I like the idea of some of polymorphism or inheritance that allows one to reference anything that can be a cable termination without needing to know the specific type of termination. It would be nice if one could just ask an object "what are the things you have that can be a cable termination" instead of needing to specify which specific type of cable termination, at least as long as it's a network termination.

[Th3Bard]

Running in to this issue. Swapping out line cards while using the same fibers...

I currently have to:

1. create a temp module bay
2. create new module
3. update all cable terminations to the new module
4. delete old module
5. slot new module in the correct module bay
6. update interface names (as the interfaces adopted the temp module bay in their naming convention)
7. delete temp module bay

This is very unfortunate right now as I work for an ISP that is upgrading GPON line cards to XGS capable cards (hundreds of them). Each line card has 8 fibers that get pulled from old card and terminated into the new card.