'soft' delete of items #6606

New Issue

adam · 2025-12-29T19:43:00+01:00

adam commented

2025-12-29 19:43:00 +01:00

Originally created by @PieterL75 on GitHub (Jun 28, 2022).

NetBox version

v3.2.5

Feature type

Change to existing functionality

Proposed functionality

Hide models from standard views, based on the status.
Keep Changelog for the devices in that state

Use case

Currently, the only way to remove items from Netbox, is by really deleting them. By doing this, you loose all historical information on that item.
It would make sense to 'hide' items that have a certain state from the standard list view.
In our case, we would hide all 'Out of Production (OOP)' items. If historical data is need, then you could set the 'status' filter to 'OOP' and see those items.

This is a pretty standard way of removing items from a CMDB.

It would also benefit to keep the changelog of that device, to know who changed the status. (Or as in FR #9160 suggests, to keep a separate entry for state changes)

The states that shoud be 'default hidden' could be set in the configuration.py, or as an extra field on the status itself.

Database changes

None

External dependencies

No response

Originally created by @PieterL75 on GitHub (Jun 28, 2022). ### NetBox version v3.2.5 ### Feature type Change to existing functionality ### Proposed functionality Hide models from standard views, based on the status. Keep Changelog for the devices in that state ### Use case Currently, the only way to remove items from Netbox, is by really deleting them. By doing this, you loose all historical information on that item. It would make sense to 'hide' items that have a certain state from the standard list view. In our case, we would hide all 'Out of Production (OOP)' items. If historical data is need, then you could set the 'status' filter to 'OOP' and see those items. This is a pretty standard way of removing items from a CMDB. It would also benefit to keep the changelog of that device, to know who changed the status. (Or as in FR #9160 suggests, to keep a separate entry for state changes) The states that shoud be 'default hidden' could be set in the configuration.py, or as an extra field on the status itself. ### Database changes None ### External dependencies _No response_

adam closed this issue

2025-12-29 19:43:00 +01:00

adam commented

2025-12-29 19:43:00 +01:00

@kkthxbye-code commented on GitHub (Jun 28, 2022):

Currently, the only way to remove items from Netbox, is by really deleting them. By doing this, you loose all historical information on that item.

The changelog stays, or am I misunderstanding you?

@kkthxbye-code commented on GitHub (Jun 28, 2022): > Currently, the only way to remove items from Netbox, is by really deleting them. By doing this, **you loose all historical information on that item**. The changelog stays, or am I misunderstanding you?

adam commented

2025-12-29 19:43:01 +01:00

@jeremystretch commented on GitHub (Jun 28, 2022):

The problem with such an approach is that it ignores the complex inter-object relationships across the application. Let's consider a simple example: I install device A in rack 1 position 10. I then delete it and install device B in that same rack and position. What happens when I decide to un-delete device A? Or should I not have been allowed to install device B?

As @kkthxbye-code points out, the global changelog retains history of objects after they've been deleted, which is generally sufficient to restore an object by hand if need be.

@jeremystretch commented on GitHub (Jun 28, 2022): The problem with such an approach is that it ignores the complex inter-object relationships across the application. Let's consider a simple example: I install device A in rack 1 position 10. I then delete it and install device B in that same rack and position. What happens when I decide to un-delete device A? Or should I not have been allowed to install device B? As @kkthxbye-code points out, the global changelog retains history of objects after they've been deleted, which is generally sufficient to restore an object by hand if need be.

adam commented

2025-12-29 19:43:01 +01:00

@PieterL75 commented on GitHub (Jun 28, 2022):

Setting custom validations, one could limit the conditions a device can be set to be ' hidden '
In our case, you can't go to oop when a device still is racked and has IP addresses.
But that should be left to the admin to decide what conditions need to be met.
But we still want the device and it's other properties to be retained, but hidden.

@PieterL75 commented on GitHub (Jun 28, 2022): Setting custom validations, one could limit the conditions a device can be set to be ' hidden ' In our case, you can't go to oop when a device still is racked and has IP addresses. But that should be left to the admin to decide what conditions need to be met. But we still want the device and it's other properties to be retained, but hidden.

adam commented

2025-12-29 19:43:01 +01:00

@jeremystretch commented on GitHub (Jun 28, 2022):

@PieterL75 I'm afraid that doesn't address my point. What behavior do you propose in the event that un-deleting an object would breach data integrity?

@jeremystretch commented on GitHub (Jun 28, 2022): @PieterL75 I'm afraid that doesn't address my point. What behavior do you propose in the event that un-deleting an object would breach data integrity?

adam commented

2025-12-29 19:43:01 +01:00

@PieterL75 commented on GitHub (Jun 29, 2022):

There is no difference in how such a hidden item works compared to a visible one. Anything assigned to that item stays assigned.
The only difference is, that the item will not be shown in regular searches, but only if you explicitly allow that state to be shown.
So there's is no data integrity issue.

@PieterL75 commented on GitHub (Jun 29, 2022): There is no difference in how such a hidden item works compared to a visible one. Anything assigned to that item stays assigned. The only difference is, that the item will not be shown in regular searches, but only if you explicitly allow that state to be shown. So there's is no data integrity issue.

adam commented

2025-12-29 19:43:01 +01:00

@jeremystretch commented on GitHub (Jun 29, 2022):

So you're saying that I wouldn't be able to install device B in the unit previously occupied by device A, even though device A has been "deleted?"

@jeremystretch commented on GitHub (Jun 29, 2022): So you're saying that I wouldn't be able to install device B in the unit previously occupied by device A, even though device A has been "deleted?"

adam commented

2025-12-29 19:43:02 +01:00

@PieterL75 commented on GitHub (Jun 29, 2022):

That's where the custom validation comes in play.
That could limit the minimum state a device has to be in (not racked, no ip addresses) before it can go to that state.

We could come up with some hard-coded requirements (no child resources like rack location, ip addresses, ...)
and yes, it could be possible that a hidden device still takes that rackplace.
The idea is, that a certain state hides the device from a normal search. but if you check a rack, then you could still see that 'hidden, out of production' device, if one forgot to unrack it in netbox.
It should still be part of all validations and 'is this free' checks

@PieterL75 commented on GitHub (Jun 29, 2022): That's where the custom validation comes in play. That could limit the minimum state a device has to be in (not racked, no ip addresses) before it can go to that state. We could come up with some hard-coded requirements (no child resources like rack location, ip addresses, ...) and yes, it could be possible that a hidden device still takes that rackplace. The idea is, that a certain state hides the device from a normal search. but if you check a rack, then you could still see that 'hidden, out of production' device, if one forgot to unrack it in netbox. It should still be part of all validations and 'is this free' checks

adam commented

2025-12-29 19:43:02 +01:00

@cybarox commented on GitHub (Jun 29, 2022):

My thoughts on this:

Maybe there should be rather an option to archive NetBox objects.

Said objects could be provided with an archive flag. The filled fields of the object could be stored in their last state and converted to strings.

This way the archived objects would no longer have any relation to existing obects. The stored information in the fields would then be preserved.

@cybarox commented on GitHub (Jun 29, 2022): My thoughts on this: Maybe there should be rather an option to archive NetBox objects. Said objects could be provided with an archive flag. The filled fields of the object could be stored in their last state and converted to strings. This way the archived objects would no longer have any relation to existing obects. The stored information in the fields would then be preserved.

adam commented

2025-12-29 19:43:02 +01:00

@kkthxbye-code commented on GitHub (Jun 29, 2022):

But that's basically the changelog.

I'm still not sure what is the actual usecase is here and the proposal seems like it needs a lot work. Maybe a discussion would be better suited to work out what you actually want before creating a FR?

@kkthxbye-code commented on GitHub (Jun 29, 2022): But that's basically the changelog. I'm still not sure what is the actual usecase is here and the proposal seems like it needs a lot work. Maybe a discussion would be better suited to work out what you actually want before creating a FR?

adam commented

2025-12-29 19:43:02 +01:00

@PieterL75 commented on GitHub (Jun 29, 2022):

From time to time, we find hardware in our racks, where someone removed it from the cmdb, but did not order a de-rack.
If this happens with netbox, then we cannot find the device and it's history anymore.
If the device basic info is still in netbox (name, serial, comments, tenants, ....) but it is hidden, then it is much easier to track those orphaned devices...
I'm sure this is not a corner case, but unfortunate real-life situations. (Some people don't understand the difference between a virtual and a physical device 🙃 )

@PieterL75 commented on GitHub (Jun 29, 2022): From time to time, we find hardware in our racks, where someone removed it from the cmdb, but did not order a de-rack. If this happens with netbox, then we cannot find the device and it's history anymore. If the device basic info is still in netbox (name, serial, comments, tenants, ....) but it is hidden, then it is much easier to track those orphaned devices... I'm sure this is not a corner case, but unfortunate real-life situations. (Some people don't understand the difference between a virtual and a physical device 🙃 )

adam commented

2025-12-29 19:43:02 +01:00

@maximumG commented on GitHub (Jun 29, 2022):

Internally, we also expressed the need of being able to archive old physical devices in netbox. Those archived devices were only meant for some kind of historical reference in case someone wants to get basic information about this old device (name, SN, device type, platform, role & some Custom fields)

On our side we are thinking about creating a dedicated netbox plugin to handle such situation. When a device is deleted from netbox, the idea is to have its archived copy inside the plugin. Using a dedicated plugin with its own database models allows to deleteentirely the device from Netbox (data integrity that @jeremystretch is talking about) while keeping a "trace" of device inside the plugin.

@maximumG commented on GitHub (Jun 29, 2022): Internally, we also expressed the need of being able to archive old physical devices in netbox. Those archived devices were only meant for some kind of historical reference in case someone wants to get basic information about this old device (name, SN, device type, platform, role & some Custom fields) On our side we are thinking about creating a dedicated netbox plugin to handle such situation. When a device is deleted from netbox, the idea is to have its archived copy inside the plugin. Using a dedicated plugin with its own database models allows to deleteentirely the device from Netbox (data integrity that @jeremystretch is talking about) while keeping a "trace" of device inside the plugin.

adam commented

2025-12-29 19:43:03 +01:00

@jeremystretch commented on GitHub (Jul 7, 2022):

I'm going to move this to a discussion, as no actual implementation has been proposed.

@jeremystretch commented on GitHub (Jul 7, 2022): I'm going to move this to a discussion, as no actual implementation has been proposed.

adam referenced this issue

2025-12-29 20:20:11 +01:00

Add a way of determining prefix percent utilization to the API #7175

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#6606