Empty cable objects after deleting last termination

[kr3ator]

NetBox version

v3.3.5

Python version

3.10

Steps to Reproduce

1. Create two devices with interfaces.
2. Create a cable between the devices.
3. Delete device A.
4. Either delete device B or the interface of device B that was used in the Cable.

Expected Behavior

The Cable object should be deleted after deleting the last termination.

Observed Behavior

The Cable object is not deleted and has no terminations in it.

[fggec]

Same here.

[jeremystretch]

The Cable object should be deleted after deleting the last termination.

I think our current sticking point is deciding whether or not the above assertion is true. I don't have a strong opinion either way, but the current implementation permits cables to exist with no terminations at either end. Whether this was by design or by accident I can't recall. 😆

[CADbloke]

It is physically possible for a cable to exist without terminations so it should probably be possible too in the documentation for that cable. imho.

[fggec]

Yes but then you have to reference it somewhere in the Doku. I see 3 possible solutions for this:

1. cables can exist without a termination. -> Reference in Doku
2. cables cannot exist without a termination. -> should be deleted.
3. let the users choose if 1 or 2. this could be a separate checkbox or separate window. When you delete a device the user can select every cable that should be deleted or not with checkboxes maybe. Also for single cable if it's disconnected and has only one termination on one device left.

I would prefer the third way

[jeremystretch]

We discussed this in today's maintainers meeting, and the consensus was to delete a cable upon the deletion of its last termination. In the UI, this will first prompt the user to confirm the cable's deletion.

[CADbloke]

We discussed this in today's maintainers meeting, and the consensus was to delete a cable upon the deletion of its last termination. In the UI, this will first prompt the user to confirm the cable's deletion.

What will the default behaviour for the API be? Alternatively, can we specify they behaviour in the API call?

[arthanson]

Thinking for the API case it should probably maintain default of not deleting the cable, but provide an option "delete_if_unterminated" or something on the termination delete API.

Also there is the bulk-disconnect case, not sure if it makes sense to put a cable deletion confirmation on that as well.. would need to filter the cables that have no terminations and present a list of all of them.

[PaulWestphal]

I'm getting an AtributeError when trying to edit a cable after deleting all terminations on one side:

<class 'AttributeError'>

'str' object has no attribute 'label'

Python version: 3.10.6
NetBox version: 3.4.6

[serge-deiss-obt]

@PaulWestphal :
I do get the same Error if i try to edit them, however it is still possible to delete them.
In the GUI there is currently to my knowledge no way to filter for these now orphaned Cables specifically to delete them in Bulk.

<class 'AttributeError'>

'str' object has no attribute 'label'

Python version: 3.10.6
NetBox version: 3.4.8

[sedyvlk]

If it is possible to have cable without one termination end, we should also allow cables to be created without one termination end. Consider the following scenario: The device fails and needs to be replaced ( like for like) and all cables new to be moved from failed device to the new device. Since cables can't be re-assigned they need to be deleted and re-created. I can't create a cable without connecting to A and B, yet having a cable with only one termination end is allowed

[kkthxbye-code]

Since cables can't be re-assigned they need to be deleted and re-created.

This is not true, you can re-assign the ends of cables.

yet having a cable with only one termination end is allowed

It's not really by design though, so I'm not sure it should be used as an argument.

[fggec]

This is not completely false. You can re-assign cables to same type of destination. You can't re-assign them to another type. If you want to change the destination from Interface to front-port there is currently no possibility to do it without recreating.

[kkthxbye-code]

His scenario was from two devices of the same type - a replacement of a broken device. Regardless, it seems unlikely that supporting changing the termination type will be supported by the fix to this issue. It was also suggested recently in a seperate issue:

#13278

[sedyvlk]

I interpret the following

We discussed this in today's maintainers meeting, and the consensus was to delete a cable upon the deletion of its last termination. In the UI, this will first prompt the user to confirm the cable's deletion.

as: what's currently a bug will no longer be a bug. My point is that if I can get to this state by deleting one side, I should able be able to get to this state by simply creating the cable.

[arthanson]

After talking to Jeremy:
For the API case we will leave the cable
For the bulk delete case will present the list of empty cables on the bulk confirmation screen noting that they will be deleted automatically.

[arthanson]

After digging into this I'm not sure the proposed solution for confirmation to delete the cable if remove all terminations is the correct solution.

I've created a separate FR #13972 This solution allows filtering of cables if they have a_terminations and/or b_terminations - so the user can filter if not a an b terminations and find any unterminated cables and just manually remove them if needed.

There are several issues with the confirm on delete solution:

• In the API case there is no way to give confirmation, so the unterminated cables are still left.
• If implement the confirmation - the current confirm delete is a common modal (htmx) so this would require a new non-modal confirmation that is completely different then all other delete confirmation modals. If did go down this route I think the change in Allow admins to request text input confirmation when deleting certain objects #13954 (comment) would be more general case more more specifically Enhance delete message #8551.
• This also ignores the unterminated on one-side case (dangling cable)

IMHO: Probably most companies would have a procedure for either always keeping or deleting the cable and therefore it probably makes more sense as a config setting (AUTO_DELETE_UNTERMINATED_CABLES) that is used to automatically delete or not-delete cables when the last termination is deleted - this can then be used in both the UI and API case.

[gormur]

What is so bad about just keeping the now half or disconnected cable? They are entities like any other in the data model. They have their own page (Connection/Cables). If one could sort by A or B termination in that page, one would easily find them. They could potentially, in real life, be hanging out of a device on the move. Or be laying around ready for re-use. They could be labeled with some asset barcode and have a length and color. They don't just vanish in thin air if one just happens to disconnect it.
True, one might be needing some easier way in the UI to find and connect them again, but that is no different from, say, assigning a "loose" ip address to an interface.

[arthanson]

@gormur actually that is what I was proposing, #13972 now allows cables to be filtered for unterminated cables and therefore they can be cleaned up manually. I'm not sure if this is needed anymore.

[jeremystretch]

We've gone back and forth on this a bit, but I agree that leaving the cable in place after all its terminations have been deleted is the most and consistent and therefor least surprising choice, and best accommodates programmatic logic. As @arthanson mentions, now that we've introduced the ability to easily filter for cables with no terminations, this should no longer be needed, so I'm going to close it out.