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

[candlerb]

In that case, another option is instead of deleting the device, you can just "de-rack" it in Netbox (i.e. change its rack association and position to Null)

If it's moved to a storage facility, then change its Site to that storage facility. Delete it only when you have confirmation that it has been destroyed or sold.

The other issue with hiding rather than deleting an item - which applies with this suggestion too - is any database-enforced uniqueness constraints will still be active.

[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.

[PieterL75]

@jeremystretch
Little of topic, but the outcome is important for me.
I understand that you select FR based on the time you and your team can spend on implementing it.

What about FR where the requestor does the implementation? Do you handle different (less strict) rules for those?

I could create a fork for the customizations I like, but it is better for the community to keep them public.

What is your view on this?

P

[esoubihe]

Allowing resources to be archived is important for infrastructure for the above reasons. It's bad practice to delete something as if it never existed, especially considering we're often talking about physical objects.

Archiving an object assumes all dependent relations no longer exist, so when you refer to a device's rack position, we should delete the relation and create a changelog entry moving previous relations to empty fields.

[ITJamie]

another option would be an undelete function using changelog data.
it was previously proposed here: #2714

the function could pre-check to make sure there are no conflicts when a user wants to restore data.
if there were to be conflicts it could list them and not allow undeletion until the user removes any conflicts?

[kaise123]

Digging up an old topic here, but I can certainly agree with the points that have been made about wanting to be able to retain information about deleted devices. The changelog doesn't quite cut it for quickly locating this information in my experience.

Our use case is basically that if something is removed from a rack (And is also physically removed from the rack) but is later required again, we would like to be able to see a "Snapshot" of what the particular rack was like on certain dates (IE, 'view' the rack 12 months ago and compare the changes).

The advantage to this is being able to easily track down an item that was removed, and who removed it - to be able to go and dig it out of storage, or ask the person responsible what happened to the device.

This could be achieved by essentially retaining a record of changes and being able to 'reconstruct' a previous state. It would be fine to drop all other references to the device, as long as it could be accessed independently from the rack view.

Anyway... just my 2 cents!