Allow Custom Validators to prevent object deletion #8591

New Issue

adam · 2025-12-29T20:38:33+01:00

adam commented

2025-12-29 20:38:33 +01:00

Originally created by @pv2b on GitHub (Sep 8, 2023).

NetBox version

v3.6.1

Feature type

New functionality

Proposed functionality

I propose an extension of the Custom Validators functionality to allow a NetBox administrator to prevent object deletion under certain criteria.

An example of how this would look would be the below pseudocode. (The example probably won't work exactly as listed, I'm just making up the way to count connected cables, and if it's right it's just an accident, but this is to show the idea.)

class PreventDeletingCabledDevicesValidator(CustomValidator):
    def validate_delete(self, instance):
        cable_count = len(instance.cables)
        if cable_count > 0:
            self.fail(f"Device still has {cable_count} cables connected to it!")

The example would prevent deleting devices that are cabled.

Implementation wise, this would happen though an overridable validate_delete() method added to the CustomValidator class which would be called prior to object deletion. Any spots in the code that perform deletion of objects would have to be identified and this hook added, hopefully there's some good chokepoint to add it to.

Use case

Deleting an object can have wide-ranging consequences in NetBox and can easilly happen accidentally. That accidental deletion is a concern is evidenced by previous Feature Request #13690. I have personally accidentally deleted an important object and caused myself an hour and a half of pain in re-creating that deleted object along with all its cable connections.

Additionally, business rules might be in place to prevent the deletion of objects under certain criteria. For example, a business rule might be that circuits or devices may not be deleted from a system if they're still active. The Permissions system might be able to do something similar (I haven't really checked) but that doesn't allow superuser actions to be validated, and that doesn't allow for custom code anyway. Or some organizations might not want to allow device deletion at all in order to keep a permanent record of scrapped devices. Anyway, you see, there's a lot of things you could do that would be for the administrator to decide.

In my opinion the inclusion of a hook like this into NetBox is a fairly small and unopinionated change that lets administrators set their own policy regarding object deletions in NetBox. It's also a natural extension of the Custom Validators functionality, covering a gap in its current functionality.

Database changes

No database changes are required. Custom validators live in configuration and code only.

External dependencies

No external dependencies are required.

Originally created by @pv2b on GitHub (Sep 8, 2023). ### NetBox version v3.6.1 ### Feature type New functionality ### Proposed functionality I propose an extension of the Custom Validators functionality to allow a NetBox administrator to prevent object deletion under certain criteria. An example of how this would look would be the below pseudocode. (The example probably won't work exactly as listed, I'm just making up the way to count connected cables, and if it's right it's just an accident, but this is to show the idea.) ```python class PreventDeletingCabledDevicesValidator(CustomValidator): def validate_delete(self, instance): cable_count = len(instance.cables) if cable_count > 0: self.fail(f"Device still has {cable_count} cables connected to it!") ``` The example would prevent deleting devices that are cabled. Implementation wise, this would happen though an overridable `validate_delete()` method added to the `CustomValidator` class which would be called prior to object deletion. Any spots in the code that perform deletion of objects would have to be identified and this hook added, hopefully there's some good chokepoint to add it to. ### Use case Deleting an object can have wide-ranging consequences in NetBox and can easilly happen accidentally. That accidental deletion is a concern is evidenced by previous Feature Request #13690. I have personally accidentally deleted an important object and caused myself an hour and a half of pain in re-creating that deleted object along with all its cable connections. Additionally, business rules might be in place to prevent the deletion of objects under certain criteria. For example, a business rule might be that circuits or devices may not be deleted from a system if they're still active. The Permissions system might be able to do something similar (I haven't really checked) but that doesn't allow superuser actions to be validated, and that doesn't allow for custom code anyway. Or some organizations might not want to allow device deletion at all in order to keep a permanent record of scrapped devices. Anyway, you see, there's a lot of things you could do that would be for the administrator to decide. In my opinion the inclusion of a hook like this into NetBox is a fairly small and unopinionated change that lets administrators set their own policy regarding object deletions in NetBox. It's also a natural extension of the Custom Validators functionality, covering a gap in its current functionality. ### Database changes No database changes are required. Custom validators live in configuration and code only. ### External dependencies No external dependencies are required.

adam added the type: feature label 2025-12-29 20:38:33 +01:00

adam closed this issue

2025-12-29 20:38:34 +01:00

adam commented

2025-12-29 20:38:34 +01:00

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

This seems like a duplicate of #10244.

@jeremystretch commented on GitHub (Sep 8, 2023): This seems like a duplicate of #10244.

adam commented

2025-12-29 20:38:34 +01:00

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

This seems like a duplicate of #10244.

Yeah, I agree, it's looks like a dupe. I didn't find it when doing a quick search. Since the other FR is close enough to what I wanted to do, I'll close this one for now.

@pv2b commented on GitHub (Sep 8, 2023): > This seems like a duplicate of #10244. Yeah, I agree, it's looks like a dupe. I didn't find it when doing a quick search. Since the other FR is close enough to what I wanted to do, I'll close this one for now.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#8591