starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Editing an unterminated cable throws exception #7489

New Issue
Closed
opened 2025-12-29 20:24:03 +01:00 by adam · 8 comments
adam commented 2025-12-29 20:24:03 +01:00
Owner
Copy Link

Originally created by @dutchman80 on GitHub (Jan 11, 2023).

Originally assigned to: @DanSheps on GitHub.

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'

Originally created by @dutchman80 on GitHub (Jan 11, 2023). Originally assigned to: @DanSheps on GitHub. ### 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'
adam added the type: bugstatus: acceptedtopic: cablingseverity: medium labels 2025-12-29 20:24:03 +01:00
adam closed this issue 2025-12-29 20:24:03 +01:00
adam commented 2025-12-29 20:24:03 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 11, 2023):

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.

@jeremystretch commented on GitHub (Jan 11, 2023): 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.
adam commented 2025-12-29 20:24:04 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jun 19, 2023):

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.

@DanSheps commented on GitHub (Jun 19, 2023): 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.
adam commented 2025-12-29 20:24:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 26, 2023):

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

@jeremystretch commented on GitHub (Sep 26, 2023): Just noting that this remains an active bug and has *not* been resolved by #13337.
adam commented 2025-12-29 20:24:04 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 30, 2023):

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.

@DanSheps commented on GitHub (Sep 30, 2023): 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.
adam commented 2025-12-29 20:24:04 +01:00
Author
Owner
Copy Link

@aravindh-murugesan commented on GitHub (Oct 26, 2023):

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?

@aravindh-murugesan commented on GitHub (Oct 26, 2023): 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?
adam commented 2025-12-29 20:24:04 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 15, 2024):

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.
😄

@DanSheps commented on GitHub (Feb 15, 2024): 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. 😄
adam commented 2025-12-29 20:24:05 +01:00
Author
Owner
Copy Link

@jschewebbn commented on GitHub (Feb 28, 2024):

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.

@jschewebbn commented on GitHub (Feb 28, 2024): 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.
adam commented 2025-12-29 20:24:05 +01:00
Author
Owner
Copy Link

@Th3Bard commented on GitHub (Mar 6, 2024):

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.

@Th3Bard commented on GitHub (Mar 6, 2024): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label severity: medium status: accepted topic: cabling type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#7489
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?