Allow to lock/unlock a device, to prevent accidental changes

[fmluizao]

Hey,

I tried to open a issue requesting a feature, but github is erroring when I tried to create 😕

The idea is to have a locked boolean column on dcim_device table. When set to true, it should prevent changes on any Device fields, via UI and API. We could have a Lock/Unlock button on the device's detail page, or even allowing to change only this field on the form would do the trick. On the device list, we could have a lock icon or something like that to indicate that the device is locked and can't be changed.

The reason I'm requesting this, is to prevent accidental changes. Sometimes, a engineer is working on a device, and a second one makes changes to it, disrupting the work. By locking the device, the second engineer would know that someone is using this device, and it won't disrupt the work.

Saw a similar discussion, but with no replies...

WDYT?

[pheus]

Hey,

Just a heads-up - this might be doable without a new feature by using Custom Validation. With that, it’s possible to restrict changes to a device based on a custom boolean field (e.g., a “locked” flag), or even based on certain status values if that works for your use case.

[fmluizao]

Hi @pheus

We already use a custom validation, using a locked custom field to prevent changes on a device, either by UI or API. But we thought that having this feature natively would also benefit other users. And we could get rid of our custom validator 🙂

[jeremystretch]

Sometimes, a engineer is working on a device, and a second one makes changes to it, disrupting the work. By locking the device, the second engineer would know that someone is using this device, and it won't disrupt the work.

NetBox has a built-in safeguard to prevent this from happening. Whenever an object is edited in the UI, NetBox checks whether the object has been modified since the edit form was rendered. If it has been, a validation error is raised.

However, it seems this isn't currently being enforced for devices specifically (and potentially other models) as the _init_time form field is not included on the HTML template. I've opened bug #19268 to address this.

[fmluizao]

Thanks for your response Jeremy, I was not aware of this, its a kind of optimistic locking, but it's only enforced via UI right? We use the api a lot 🙂