'soft' delete of items

[PieterL75]

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

[kkthxbye-code]

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?

[jeremystretch]

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.

[PieterL75]

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.

[jeremystretch]

@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?

[PieterL75]

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.

[jeremystretch]

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?"

[PieterL75]

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

[cybarox]

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.

[kkthxbye-code]

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?

[PieterL75]

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 🙃 )

[maximumG]

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.

[jeremystretch]

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