when deleteing an object in webui. list the related objects that would also be deleted #8576

@ITJamie commented on GitHub (Sep 5, 2023):

another option to consider - the delete modal popup could require typing the “name” of the object to enable the delete button on the modal. (I’m personally not a fan of that method, but it is a fairly standard way of helping to stop erroneous deletions in webapps)

@ITJamie commented on GitHub (Sep 5, 2023): another option to consider - the delete modal popup could require typing the “name” of the object to enable the delete button on the modal. (I’m personally not a fan of that method, but it is a fairly standard way of helping to stop erroneous deletions in webapps)

adam commented

@sleepinggenius2 commented on GitHub (Sep 5, 2023):

It looks like something similar was proposed in #8551, but never got an owner. I see this as also related to #6015, which is still a problem in our organization, as the current behavior is unexpected for our engineers.

@sleepinggenius2 commented on GitHub (Sep 5, 2023): It looks like something similar was proposed in #8551, but never got an owner. I see this as also related to #6015, which is still a problem in our organization, as the current behavior is unexpected for our engineers.

adam commented

@pv2b commented on GitHub (Sep 7, 2023):

another option to consider - the delete modal popup could require typing the “name” of the object to enable the delete button on the modal. (I’m personally not a fan of that method, but it is a fairly standard way of helping to stop erroneous deletions in webapps)

I don't like it because it doesn't address the core problem, which is making sure a user understands that deleting a device will also potentially delete all related interfaces and cables.

However, one thing that occurrs to me, instead of implementing this in core NetBox, could a similar effect be acheived with a custom validator? The custom validator could for example reject any deletions of any devices that have cables connected to them, requiring the user to disconnect all cables in NetBox before deleting the object. This is similar to how some network vendors set up their equipment, making it impossible to delete configuration object that have other dependent objects.

@pv2b commented on GitHub (Sep 7, 2023): > another option to consider - the delete modal popup could require typing the “name” of the object to enable the delete button on the modal. (I’m personally not a fan of that method, but it is a fairly standard way of helping to stop erroneous deletions in webapps) I don't like it because it doesn't address the core problem, which is making sure a user understands that deleting a device will also potentially delete all related interfaces and cables. However, one thing that occurrs to me, instead of implementing this in core NetBox, could a similar effect be acheived with a custom validator? The custom validator could for example reject any deletions of any devices that have cables connected to them, requiring the user to disconnect all cables in NetBox before deleting the object. This is similar to how some network vendors set up their equipment, making it impossible to delete configuration object that have other dependent objects.

adam commented

@pv2b commented on GitHub (Sep 7, 2023):

instead of implementing this in core NetBox, could a similar effect be acheived with a custom validator?

I just checked and no, unfortunately the custom validator only triggers when editing an object, it doesn't trigger on object deletion.

Maybe an alternative way to implement this could be to extend the concept of custom validators to also call a method on them prior to deletion?

@pv2b commented on GitHub (Sep 7, 2023): > instead of implementing this in core NetBox, could a similar effect be acheived with a custom validator? I just checked and no, unfortunately the custom validator only triggers when editing an object, it doesn't trigger on object deletion. Maybe an alternative way to implement this could be to extend the concept of custom validators to also call a method on them prior to deletion?

adam commented

@ITJamie commented on GitHub (Sep 8, 2023):

If this was to be accepted I have put together a quick example of how this could be achieved here

obviously it could use some work styling wise, maybe some links to the objects..., but for a POC it seems to be working

@ITJamie commented on GitHub (Sep 8, 2023): If this was to be accepted I have put together a quick example of how this could be achieved [here](https://github.com/netbox-community/netbox/compare/develop...ITJamie:netbox:show-what-extra-objects-would-be-deleted) <img width="1171" alt="Screenshot 2023-09-08 at 00 19 37" src="https://github.com/netbox-community/netbox/assets/1613241/2a025712-1daf-4d44-893d-ecdb78f02217"> <img width="1168" alt="Screenshot 2023-09-08 at 00 22 11" src="https://github.com/netbox-community/netbox/assets/1613241/9ef90915-a824-4d1d-a769-b3bfe1ded84f"> obviously it could use some work styling wise, maybe some links to the objects..., but for a POC it seems to be working

adam commented

@pv2b commented on GitHub (Sep 8, 2023):

If this was to be accepted I have put together a quick example of how this could be achieved here

obviously it could use some work styling wise, maybe some links to the objects..., but for a POC it seems to be working

I think we'd need to talk a little about what's a useful scope. In your example you're listing all related objects. The problem with that is that it's not really a surprise to anyone that if they delete a switch, they'll also be deleting its interfaces, front ports, as well records of related IP addresses etc. With the UI implemented the way you're showing, you'll end up with a long list of related objects for every single device deletion. This will likely cause Alert Fatigue, and you'll end up with users ignoring those warning lists because they're normal and expected.

I think a much more useful scope is limiting yourself to the case where a device is cabled to many other devices or circuits. Something like:

Confirm deletion

Are you sure you want to delete device Super-Important-Distribution-Switch-42? This will remove 27 cables.

[ ] Yes, please delete 27 cables along with the device.

[Cancel] [Submit]

@pv2b commented on GitHub (Sep 8, 2023): > If this was to be accepted I have put together a quick example of how this could be achieved [here](https://github.com/netbox-community/netbox/compare/develop...ITJamie:netbox:show-what-extra-objects-would-be-deleted) > <img alt="Screenshot 2023-09-08 at 00 19 37" width="1171" src="https://user-images.githubusercontent.com/1613241/266462663-2a025712-1daf-4d44-893d-ecdb78f02217.png"> <img alt="Screenshot 2023-09-08 at 00 22 11" width="1168" src="https://user-images.githubusercontent.com/1613241/266462776-9ef90915-a824-4d1d-a769-b3bfe1ded84f.png"> > > obviously it could use some work styling wise, maybe some links to the objects..., but for a POC it seems to be working I think we'd need to talk a little about what's a useful scope. In your example you're listing all related objects. The problem with that is that it's not really a surprise to anyone that if they delete a switch, they'll also be deleting its interfaces, front ports, as well records of related IP addresses etc. With the UI implemented the way you're showing, you'll end up with a long list of related objects for every single device deletion. This will likely cause Alert Fatigue, and you'll end up with users ignoring those warning lists because they're normal and expected. I think a much more useful scope is limiting yourself to the case where a device is cabled to many other devices or circuits. Something like: > # Confirm deletion > > Are you sure you want to **delete** device Super-Important-Distribution-Switch-42? This will remove 27 cables. > > [ ] Yes, please **delete** 27 cables along with the device. > > [Cancel] [Submit]

adam commented

@pv2b commented on GitHub (Sep 8, 2023):

I would also like that after sleeping on it, I think personally I prefer an approach where the users have to manually disconnect all cables from a device before it can be deleted, because that automatically makes their deletion intentional. However, I really doubt that's a UX change that NetBox would want to make for everyone. That said I think there's room for a pre-delete hook in the custom validators feature, but that's a seperate FR. That I'm actually going to ahead and write up as a seperate feature to this.

@pv2b commented on GitHub (Sep 8, 2023): I would also like that after sleeping on it, I think *personally* I prefer an approach where the users have to manually disconnect all cables from a device before it can be deleted, because that automatically makes their deletion intentional. However, I really doubt that's a UX change that NetBox would want to make for everyone. That said I think there's room for a pre-delete hook in the custom validators feature, but that's a seperate FR. That I'm actually going to ahead and write up as a seperate feature to this.

adam commented

@ITJamie commented on GitHub (Sep 8, 2023):

If this was to be accepted I have put together a quick example of how this could be achieved here

obviously it could use some work styling wise, maybe some links to the objects..., but for a POC it seems to be working

I think we'd need to talk a little about what's a useful scope. In your example you're listing all related objects. The problem with that is that it's not really a surprise to anyone that if they delete a switch, they'll also be deleting its interfaces, front ports, as well records of related IP addresses etc. With the UI implemented the way you're showing, you'll end up with a long list of related objects for every single device deletion. This will likely cause Alert Fatigue, and you'll end up with users ignoring those warning lists because they're normal and expected.

I think a much more useful scope is limiting yourself to the case where a device is cabled to many other devices or circuits. Something like:

Confirm deletion

Are you sure you want to delete device Super-Important-Distribution-Switch-42? This will remove 27 cables.

[ ] Yes, please delete 27 cables along with the device.

[Cancel] [Submit]

My view is that this is generic across all models and plugins. Validators would need to be written per model and new additions could be missed.

Showing everything thats going to be deleted is also better for new users to understand the relationships that exist.

@ITJamie commented on GitHub (Sep 8, 2023): > > If this was to be accepted I have put together a quick example of how this could be achieved [here](https://github.com/netbox-community/netbox/compare/develop...ITJamie:netbox:show-what-extra-objects-would-be-deleted) > > > <img alt="Screenshot 2023-09-08 at 00 19 37" width="1171" src="https://user-images.githubusercontent.com/1613241/266462663-2a025712-1daf-4d44-893d-ecdb78f02217.png"> <img alt="Screenshot 2023-09-08 at 00 22 11" width="1168" src="https://user-images.githubusercontent.com/1613241/266462776-9ef90915-a824-4d1d-a769-b3bfe1ded84f.png"> > > > > > > obviously it could use some work styling wise, maybe some links to the objects..., but for a POC it seems to be working > > > > I think we'd need to talk a little about what's a useful scope. In your example you're listing all related objects. The problem with that is that it's not really a surprise to anyone that if they delete a switch, they'll also be deleting its interfaces, front ports, as well records of related IP addresses etc. With the UI implemented the way you're showing, you'll end up with a long list of related objects for every single device deletion. This will likely cause Alert Fatigue, and you'll end up with users ignoring those warning lists because they're normal and expected. > > > > I think a much more useful scope is limiting yourself to the case where a device is cabled to many other devices or circuits. Something like: > > > > > # Confirm deletion > > > > > > Are you sure you want to **delete** device Super-Important-Distribution-Switch-42? This will remove 27 cables. > > > > > > [ ] Yes, please **delete** 27 cables along with the device. > > > > > > [Cancel] [Submit] My view is that this is generic across all models and plugins. Validators would need to be written per model and new additions could be missed. Showing everything thats going to be deleted is also better for new users to understand the relationships that exist.

adam commented

@pv2b commented on GitHub (Sep 8, 2023):

My view is that this is generic across all models and plugins. Validators would need to be written per model and new additions could be missed.

This is true, but having some more thought put into validation as opposed to warning about everything isn't a bad thing, if your goal is to get your users to actually care about the warnings.

Showing everything thats going to be deleted is also better for new users to understand the relationships that exist.

That is a good point!

I would also like to clarify that I still like the feature being proposed here, it provides useful feedback and information for the user, but I don't think that it'll be effective at one of the stated goals, which is providing safety against accidental deletions, and nothing's stopping both these features from being implemented. (Except possibly limited dev time.) They complement each other.

@pv2b commented on GitHub (Sep 8, 2023): > My view is that this is generic across all models and plugins. Validators would need to be written per model and new additions could be missed. This is true, but having some more thought put into validation as opposed to warning about everything isn't a bad thing, if your goal is to get your users to actually care about the warnings. > Showing everything thats going to be deleted is also better for new users to understand the relationships that exist. That is a good point! I would also like to clarify that I still like the feature being proposed here, it provides useful feedback and information for the user, but I don't think that it'll be effective at one of the stated goals, which is providing safety against accidental deletions, and nothing's stopping both these features from being implemented. (Except possibly limited dev time.) They complement each other.

adam commented

@ITJamie commented on GitHub (Sep 8, 2023):

I agree that we shouldn't allow devices to be deleted with cables connected. So im 100% for that change! Doing this also made me notice that we delete primary and oob ips when deleting a debice which is a bit odd...

I still hope we add this visual to the delete dialog though.

@ITJamie commented on GitHub (Sep 8, 2023): I agree that we shouldn't allow devices to be deleted with cables connected. So im 100% for that change! Doing this also made me notice that we delete primary and oob ips when deleting a debice which is a bit odd... I still hope we add this visual to the delete dialog though.

adam commented

@pv2b commented on GitHub (Sep 8, 2023):

I agree that we shouldn't allow devices to be deleted with cables connected. So im 100% for that change! Doing this also made me notice that we delete primary and oob ips which is a bit odd...

I still hope we add this visual to the delete dialog though.

Getting a little off topic in this particular thread here, but my other FR isn't proposing that exactly, it's proposing a mechanism to allow an administrator to extend NetBox to prevent object deletion under specific criteria. It could be used, for example, to enforce that all cables must be deleted before object deletion, but it won't do that unless the user customizes NetBox to do so.

If there were a hypothetical FR to change NetBox to require deleting cables before deleting an object, I'd support it as the right choice, but I can see that being controversial.

@pv2b commented on GitHub (Sep 8, 2023): > I agree that we shouldn't allow devices to be deleted with cables connected. So im 100% for that change! Doing this also made me notice that we delete primary and oob ips which is a bit odd... > > I still hope we add this visual to the delete dialog though. Getting a little off topic in this particular thread here, but my other FR isn't proposing that exactly, it's proposing a mechanism to allow an administrator to extend NetBox to prevent object deletion under specific criteria. It could be used, for example, to enforce that all cables must be deleted before object deletion, but it won't do that unless the user customizes NetBox to do so. If there were a hypothetical FR to change NetBox to require deleting cables before deleting an object, I'd support it as the right choice, but I can see that being controversial.

adam commented

@jeremystretch commented on GitHub (Oct 19, 2023):

Tagging this for v3.7 as it looks doable. @ITJamie would you like to own this one?

@jeremystretch commented on GitHub (Oct 19, 2023): Tagging this for v3.7 as it looks doable. @ITJamie would you like to own this one?

adam commented