Deleting a connected port, interface or other connection on a device should not be possible if there's a connected cable #4333

New Issue

@jeremystretch commented on GitHub (Dec 4, 2020):

A delete confirmation is displayed and then actioned, which then deletes the cables.

This is the intended behavior. If you'd like to propose changing this behavior, please rewrite or resbumit your issue as a feature request citing your specific use case.

@jeremystretch commented on GitHub (Dec 4, 2020): > A delete confirmation is displayed and then actioned, which then deletes the cables. This is the intended behavior. If you'd like to propose changing this behavior, please rewrite or resbumit your issue as a [feature request](https://github.com/netbox-community/netbox/issues/new?template=feature_request.md) citing your specific use case.

adam commented

@pobk commented on GitHub (Dec 5, 2020):

Revised to feature request.

@pobk commented on GitHub (Dec 5, 2020): Revised to feature request.

adam commented

@Infiniverse commented on GitHub (Dec 5, 2020):

Should this be expanded to, deleting any port or interface should not be possible if there is a cable connected to it?

@Infiniverse commented on GitHub (Dec 5, 2020): Should this be expanded to, deleting any port or interface should not be possible if there is a cable connected to it?

adam commented

@pobk commented on GitHub (Dec 5, 2020):

Should this be expanded to, deleting any port or interface should not be possible if there is a cable connected to it?

Agreed. Have updated FR to include this on any connection made to a device, interface, ports, console, power etc...

@pobk commented on GitHub (Dec 5, 2020): > Should this be expanded to, deleting any port or interface should not be possible if there is a cable connected to it? Agreed. Have updated FR to include this on any connection made to a device, interface, ports, console, power etc...

adam commented

@jeremystretch commented on GitHub (Dec 8, 2020):

This will need to be addressed by the community, as I suspect there's a good number of people who rely on the current behavior.

@jeremystretch commented on GitHub (Dec 8, 2020): This will need to be addressed by the community, as I suspect there's a good number of people who rely on the current behavior.

adam commented

@pobk commented on GitHub (Dec 15, 2020):

I think the sticking point of this issue is that the confirmation page for deleting cables and a connections, look virtually identical.

Delete cable confirmation: https://pasteboard.co/JF3FFNT.png
Delete port confirmation: https://pasteboard.co/JF3G0OW.png

There's nothing immediately obvious in the UI to indicate that deletion of the port will also delete, ports, cables and interfaces and more possibly, in future. It's a lot more destructive.

I suspect the better option would be an alternative delete confirmation page, that way you're not breaking the work-flow, just reformatting it a little bit?

@pobk commented on GitHub (Dec 15, 2020): I think the sticking point of this issue is that the confirmation page for deleting cables and a connections, look virtually identical. Delete cable confirmation: [https://pasteboard.co/JF3FFNT.png](https://pasteboard.co/JF3FFNT.png) Delete port confirmation: [https://pasteboard.co/JF3G0OW.png](https://pasteboard.co/JF3G0OW.png) There's nothing immediately obvious in the UI to indicate that deletion of the port will also delete, ports, cables and interfaces and more possibly, in future. It's a lot more destructive. I suspect the better option would be an alternative delete confirmation page, that way you're not breaking the work-flow, just reformatting it a little bit?

adam commented

@TheTrafficNetwork commented on GitHub (Dec 15, 2020):

From my perspective, removing the cable before removing a port/interface/etc seems logical. If I were wanting to remove a module from a switch, I would in the majority of cases remove all of the cables first. I do not have anything that would break from this change so my views may be different than much more developed power users.

@TheTrafficNetwork commented on GitHub (Dec 15, 2020): From my perspective, removing the cable before removing a port/interface/etc seems logical. If I were wanting to remove a module from a switch, I would in the majority of cases remove all of the cables first. I do not have anything that would break from this change so my views may be different than much more developed power users.

adam commented

@stale[bot] commented on GitHub (Jan 30, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Jan 30, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@pobk commented on GitHub (Feb 9, 2021):

So how does one get more input from the community on this to establish more of a consensus?

@pobk commented on GitHub (Feb 9, 2021): So how does one get more input from the community on this to establish more of a consensus?

adam commented

@pobk commented on GitHub (Mar 17, 2021):

Is there no more appetite for discussion here?

Is it worth putting together a PR for this?

@pobk commented on GitHub (Mar 17, 2021): Is there no more appetite for discussion here? Is it worth putting together a PR for this?

adam commented

@xkilian commented on GitHub (Mar 17, 2021):

I agree with the proposed changes.

As for NOT permitting the deletion of a port, I am more in agreement than disagreement. I think other power users should provide feedback to see if after a warning it should be allowed anyway.
Our current cabling management system REQUIRES that a cable be disconnected before removing a port.. Especially because a "connexion" is not just a single cable but may be formed of a number of cables spanning multiple rooms or sites and care must be taking to decomission paths and/or single connexions depending on the use-case. (Removal, move, reconfiguration, etc.)

@xkilian commented on GitHub (Mar 17, 2021): I agree with the proposed changes. As for NOT permitting the deletion of a port, I am more in agreement than disagreement. I think other power users should provide feedback to see if after a warning it should be allowed anyway. Our current cabling management system REQUIRES that a cable be disconnected before removing a port.. Especially because a "connexion" is not just a single cable but may be formed of a number of cables spanning multiple rooms or sites and care must be taking to decomission paths and/or single connexions depending on the use-case. (Removal, move, reconfiguration, etc.)

adam commented

@xkilian commented on GitHub (Mar 17, 2021):

I think a PR should be prepared for this, are you proposing to do the work? I any case, the current way of doing things is dangerous.
As Netbox matures, it is issues like these that are valuable to improve workflow quality. Small things, but important things.
Same as looking at it from a task based perspective:
Take the TOP THREE tasks someone does in a day in Netbox and evaluate what can be improved:

how is input done
validation of input
number of clicks to do the task
number of panel changes to do a task
complexity of data presented and interpreted to do the task
sources of error
sources of user frustration
intuitiveness of UI
consistancy of UI
performance
overall time mesure to do the task, etc.

Based on the evaluation, improving important use-cases will provide high value for the most users. :-)

@xkilian commented on GitHub (Mar 17, 2021): I think a PR should be prepared for this, are you proposing to do the work? I any case, the current way of doing things is dangerous. As Netbox matures, it is issues like these that are valuable to improve workflow quality. Small things, but important things. Same as looking at it from a task based perspective: Take the TOP THREE tasks someone does in a day in Netbox and evaluate what can be improved: - how is input done - validation of input - number of clicks to do the task - number of panel changes to do a task - complexity of data presented and interpreted to do the task - sources of error - sources of user frustration - intuitiveness of UI - consistancy of UI - performance - overall time mesure to do the task, etc. Based on the evaluation, improving important use-cases will provide high value for the most users. :-)

adam commented

@DanSheps commented on GitHub (Mar 17, 2021):

Here is my take on this:

It might be better to instead of making any sweeping changes to the current functionality, change the delete pages for every device to provide a list of "impacted" additional models. For example, if you are deleting a rear port, it should simply state:

"You are deleting this port. By deleting this port, the following will be deleted as well: <insert list>"

@DanSheps commented on GitHub (Mar 17, 2021): Here is my take on this: It might be better to instead of making any sweeping changes to the current functionality, change the delete pages for every device to provide a list of "impacted" additional models. For example, if you are deleting a rear port, it should simply state: "You are deleting this port. By deleting this port, the following will be deleted as well: \<insert list\>"

adam commented

@jeremystretch commented on GitHub (Mar 17, 2021):

I think a PR should be prepared for this

Per the contributing guide, please don't open a PR for an issue before it has been accepted.

@jeremystretch commented on GitHub (Mar 17, 2021): > I think a PR should be prepared for this Per the contributing guide, please don't open a PR for an issue before it has been accepted.

adam commented

@xkilian commented on GitHub (Mar 17, 2021):

Oups, yes of course, this should be an accepted issue before submitting an PR.

@xkilian commented on GitHub (Mar 17, 2021): Oups, yes of course, this should be an accepted issue before submitting an PR.

adam commented

@pobk commented on GitHub (Apr 21, 2021):

It might be better to instead of making any sweeping changes to the current functionality, change the delete pages for every device to provide a list of "impacted" additional models. For example, if you are deleting a rear port, it should simply state:

"You are deleting this port. By deleting this port, the following will be deleted as well: "

This is the approach I was thinking of taking... Rather than simply looking like every other delete page in NetBox, adjust the delete template to communicate the complexity of the deletion... What else is going to be nuked. The sentiment being: if we communicate the changes to be made is a different way, someone might stop and identify the change as something they don't want to do.

The danger of the current generic approach, is that it looks like every other delete page, and users should strongly be urged to look at what they're deleting when it comes to read-ports, since it deletes more than is immediately obvious.

@pobk commented on GitHub (Apr 21, 2021): > It might be better to instead of making any sweeping changes to the current functionality, change the delete pages for every device to provide a list of "impacted" additional models. For example, if you are deleting a rear port, it should simply state: > > "You are deleting this port. By deleting this port, the following will be deleted as well: <insert list>" This is the approach I was thinking of taking... Rather than simply looking like every other delete page in NetBox, adjust the delete template to communicate the complexity of the deletion... What else is going to be nuked. The sentiment being: if we communicate the changes to be made is a different way, someone might stop and identify the change as something they don't want to do. The danger of the current generic approach, is that it looks like every other delete page, and users should strongly be urged to look at what they're deleting when it comes to read-ports, since it deletes more than is immediately obvious.

adam commented

@pobk commented on GitHub (Apr 21, 2021):

@jeremystretch should I adjust the FR in line with current discussion... Re-define it as a change to templates rather than change to process?

Would that be more palatable?

@pobk commented on GitHub (Apr 21, 2021): @jeremystretch should I adjust the FR in line with current discussion... Re-define it as a change to templates rather than change to process? Would that be more palatable?

adam commented