Empty cable objects after deleting last termination #7170

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

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

@jeremystretch commented on GitHub (Jan 11, 2023): > 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. :laughing:

adam commented

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

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.

@CADbloke commented on GitHub (Jan 11, 2023): 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.

adam commented

@fggec commented on GitHub (Jan 12, 2023):

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

cables can exist without a termination. -> Reference in Doku
cables cannot exist without a termination. -> should be deleted.
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

@fggec commented on GitHub (Jan 12, 2023): 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

adam commented

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

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.

@jeremystretch commented on GitHub (Jan 12, 2023): 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.

adam commented

@CADbloke commented on GitHub (Jan 16, 2023):

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?

@CADbloke commented on GitHub (Jan 16, 2023): > 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?

adam commented

@arthanson commented on GitHub (Mar 23, 2023):

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.

@arthanson commented on GitHub (Mar 23, 2023): 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.

adam commented

@PaulWestphal commented on GitHub (Mar 28, 2023):

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

@PaulWestphal commented on GitHub (Mar 28, 2023): 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 ```

adam commented

@serge-deiss-obt commented on GitHub (Apr 21, 2023):

@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

@serge-deiss-obt commented on GitHub (Apr 21, 2023): @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 ```

adam commented

@sedyvlk commented on GitHub (Aug 9, 2023):

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

@sedyvlk commented on GitHub (Aug 9, 2023): 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

adam commented

@kkthxbye-code commented on GitHub (Aug 9, 2023):

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.

@kkthxbye-code commented on GitHub (Aug 9, 2023): > 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.

adam commented

@fggec commented on GitHub (Aug 9, 2023):

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.

@fggec commented on GitHub (Aug 9, 2023): 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.

adam commented

https://github.com/netbox-community/netbox/issues/13278

@kkthxbye-code commented on GitHub (Aug 9, 2023):

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:

@kkthxbye-code commented on GitHub (Aug 9, 2023): 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: https://github.com/netbox-community/netbox/issues/13278

adam commented

@sedyvlk commented on GitHub (Aug 9, 2023):

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.

@sedyvlk commented on GitHub (Aug 9, 2023): 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.

adam commented

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

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 commented on GitHub (Sep 26, 2023): 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.

adam commented

@arthanson commented on GitHub (Oct 4, 2023):

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 https://github.com/netbox-community/netbox/issues/13954#issuecomment-1746750545 would be more general case more more specifically https://github.com/netbox-community/netbox/issues/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.

@arthanson commented on GitHub (Oct 4, 2023): 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 https://github.com/netbox-community/netbox/issues/13954#issuecomment-1746750545 would be more general case more more specifically https://github.com/netbox-community/netbox/issues/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.

adam commented

@gormur commented on GitHub (Nov 21, 2023):

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.

@gormur commented on GitHub (Nov 21, 2023): 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.

adam commented