starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Hardware Software SLA Warrenty for Devices/VM's #11206

New Issue
Closed
opened 2025-12-29 21:41:56 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:41:56 +01:00
Owner
Copy Link

Originally created by @basdscho23 on GitHub (May 21, 2025).

NetBox version

v4.2.6

Feature type

New functionality

Proposed functionality

We currently maintain our hardware maintenance and software maintenance via custom fields as this is very undynamic, we wanted to ask if it could be integrated into the Netbox by default.
Our current custom fields are:

  • Delivery/Installation date
  • Name of warrantor for the hardware (Dell, Lenovo)
  • Hardware warranty SLA (24x7x4, 24x7x2, 24x7x8, 24x7xNBD, 8x5x4, 9x5x4, 8x5xNBD, None, Administratively out of maintenace)
  • Hardware warranty expiration (it would be best if you could define from date to date)
  • Optional: 1st software support contract for/by
  • Optional: 1st software contract SLA (same times to choose from as hardware SLA)
  • Optional: 1st software support contract expiration
  • Optional: 1st software responsibility contact

Image

It would be best to define multiple maintenance for software

Use case

This function would have the advantage of being able to maintain both the hardware and the software installed on the systems with more options than a custom field provides. The fields take up a lot of space and the list of custom fields is getting longer and longer. This would also make it clearer from a usability point of view. Perhaps a separate tab would be sufficient for this, but this would mean that the obligation of fields is no longer given.

Database changes

Only new fields would be added to the database for devices and VMs. If it were to be a separate tab, probably a separate model class that refers to the device or VM as a ForeignKey

External dependencies

A new Python package or similar would not be necessary

Originally created by @basdscho23 on GitHub (May 21, 2025). ### NetBox version v4.2.6 ### Feature type New functionality ### Proposed functionality We currently maintain our hardware maintenance and software maintenance via custom fields as this is very undynamic, we wanted to ask if it could be integrated into the Netbox by default. Our current custom fields are: - Delivery/Installation date - Name of warrantor for the hardware (Dell, Lenovo) - Hardware warranty SLA (24x7x4, 24x7x2, 24x7x8, 24x7xNBD, 8x5x4, 9x5x4, 8x5xNBD, None, Administratively out of maintenace) - Hardware warranty expiration (it would be best if you could define from date to date) - Optional: 1st software support contract for/by - Optional: 1st software contract SLA (same times to choose from as hardware SLA) - Optional: 1st software support contract expiration - Optional: 1st software responsibility contact ![Image](https://github.com/user-attachments/assets/4df3e204-e145-4fd2-9eaf-11fe9b2d0538) It would be best to define multiple maintenance for software ### Use case This function would have the advantage of being able to maintain both the hardware and the software installed on the systems with more options than a custom field provides. The fields take up a lot of space and the list of custom fields is getting longer and longer. This would also make it clearer from a usability point of view. Perhaps a separate tab would be sufficient for this, but this would mean that the obligation of fields is no longer given. ### Database changes Only new fields would be added to the database for devices and VMs. If it were to be a separate tab, probably a separate model class that refers to the device or VM as a ForeignKey ### External dependencies A new Python package or similar would not be necessary
adam added the netbox label 2025-12-29 21:41:56 +01:00
adam closed this issue 2025-12-29 21:41:57 +01:00
adam commented 2025-12-29 21:41:57 +01:00
Author
Owner
Copy Link

@mr1716 commented on GitHub (May 22, 2025):

It may be more intuitive to change the field “Hardware warranty expiration” to either rename the field to something like “Hardware warranty period” to reflect the date range of when the warranty is active or have that be 1 date to reflect the end date.

That said, there are probably other improvements that could be made to the wording. Moreover, why not create a custom plugin for warranty information rather than adding the fields as model values?

@mr1716 commented on GitHub (May 22, 2025): It may be more intuitive to change the field “Hardware warranty expiration” to either rename the field to something like “Hardware warranty period” to reflect the date range of when the warranty is active or have that be 1 date to reflect the end date. That said, there are probably other improvements that could be made to the wording. Moreover, why not create a custom plugin for warranty information rather than adding the fields as model values?
adam commented 2025-12-29 21:41:57 +01:00
Author
Owner
Copy Link

@basdscho23 commented on GitHub (May 22, 2025):

Hi @mr1716,
I agree with your point that it could be more intuitive. My previous custom fields should only serve as an example.

of course you can build your own plugin for this, but it would make sense to be able to store the whole guarnte hardware or software by default. In addition, it would also be simpler for the user in terms of obligations and the mandatory fields would already have to be filled in when creating a device/vms, as is the case now via Custom Fields.

@basdscho23 commented on GitHub (May 22, 2025): Hi @mr1716, I agree with your point that it could be more intuitive. My previous custom fields should only serve as an example. of course you can build your own plugin for this, but it would make sense to be able to store the whole guarnte hardware or software by default. In addition, it would also be simpler for the user in terms of obligations and the mandatory fields would already have to be filled in when creating a device/vms, as is the case now via Custom Fields.
adam commented 2025-12-29 21:41:57 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (May 22, 2025):

@basdscho23 , this is outside the scope of what core NetBox can or should include. In fact, there is already a plugin for this purpose, netbox-lifecycle.

If your needs exceed that and the maintainer isn't interested in expanding the scope, then I think this is best solved by building your own custom plugin for this functionality.

@jnovinger commented on GitHub (May 22, 2025): @basdscho23 , this is outside the scope of what core NetBox can or should include. In fact, there is already a plugin for this purpose, [netbox-lifecycle](https://github.com/DanSheps/netbox-lifecycle). If your needs exceed that and the maintainer isn't interested in expanding the scope, then I think this is best solved by building your own custom plugin for this functionality.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label netbox
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11206
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?