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

Custom Fields Per Device Type #563

New Issue
Closed
opened 2025-12-29 16:23:14 +01:00 by adam · 14 comments
adam commented 2025-12-29 16:23:14 +01:00
Owner
Copy Link

Originally created by @techymike on GitHub (Dec 5, 2016).

Hi,

I'm not sure if this is already available or If I've simply missed something, but would it be possible to apply a custom field per device type ?

I can only seem to create custom fields on each actual device, It would be nice to say have a user manual field per every type of server/switch etc at the type level as opposed to every single device.

Apologies if this is already possible

Originally created by @techymike on GitHub (Dec 5, 2016). Hi, I'm not sure if this is already available or If I've simply missed something, but would it be possible to apply a custom field per device type ? I can only seem to create custom fields on each actual device, It would be nice to say have a user manual field per every type of server/switch etc at the type level as opposed to every single device. Apologies if this is already possible
adam added the type: feature label 2025-12-29 16:23:14 +01:00
adam closed this issue 2025-12-29 16:23:14 +01:00
adam commented 2025-12-29 16:23:14 +01:00
Author
Owner
Copy Link

@NetBod commented on GitHub (Dec 5, 2016):

Beat me to it, I was looking for the same thing last night.....

@NetBod commented on GitHub (Dec 5, 2016): Beat me to it, I was looking for the same thing last night.....
adam commented 2025-12-29 16:23:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 5, 2016):

Can you provide some examples of what you would use this for?

@jeremystretch commented on GitHub (Dec 5, 2016): Can you provide some examples of what you would use this for?
adam commented 2025-12-29 16:23:14 +01:00
Author
Owner
Copy Link

@NetBod commented on GitHub (Dec 5, 2016):

I was going to use it for End of life/End of Service date for the bit of hardware or software I have configured for the device type, would save having to add the same info many times under the device as a custom field

@NetBod commented on GitHub (Dec 5, 2016): I was going to use it for End of life/End of Service date for the bit of hardware or software I have configured for the device type, would save having to add the same info many times under the device as a custom field
adam commented 2025-12-29 16:23:15 +01:00
Author
Owner
Copy Link

@techymike commented on GitHub (Dec 6, 2016):

Hi Jeremy,

Certainly, BTW I love netbox, it's a fantastic tool great job !

In our DC's we have many of the same type of kit, servers, cisco network kit etc. For asset managment and documentation purposes I have a requirement to keep specification/data sheets etc for each piece of kit.
I'm basically adding custom fields containing hyperlinks to the data sheets which point to somewhere on a document server.

At the moment I have to manually enter each field per device, even though potentially scores of devices use the same "data".

It would be nice to say define a custom field for a device type (eg HP Proliant DL380e Gen7 Manual ) and have it applied at the device type level so I don't have to manually add the same field for every server I have.

I'm sure there are probably many other cases where a custom field on the device type level would be of benefit for others. (EOL/EOS date field as NetBod above mentioned is also something that it would be useful for )

Cheers !

@techymike commented on GitHub (Dec 6, 2016): Hi Jeremy, Certainly, BTW I love netbox, it's a fantastic tool great job ! In our DC's we have many of the same type of kit, servers, cisco network kit etc. For asset managment and documentation purposes I have a requirement to keep specification/data sheets etc for each piece of kit. I'm basically adding custom fields containing hyperlinks to the data sheets which point to somewhere on a document server. At the moment I have to manually enter each field per device, even though potentially scores of devices use the same "data". It would be nice to say define a custom field for a device type (eg HP Proliant DL380e Gen7 Manual ) and have it applied at the device type level so I don't have to manually add the same field for every server I have. I'm sure there are probably many other cases where a custom field on the device type level would be of benefit for others. (EOL/EOS date field as NetBod above mentioned is also something that it would be useful for ) Cheers !
adam commented 2025-12-29 16:23:15 +01:00
Author
Owner
Copy Link

@Tigger2014 commented on GitHub (Dec 6, 2016):

This would also be useful for adding device specific notes which apply globally.

@Tigger2014 commented on GitHub (Dec 6, 2016): This would also be useful for adding device specific notes which apply globally.
adam commented 2025-12-29 16:23:15 +01:00
Author
Owner
Copy Link

@Kevgudge commented on GitHub (Dec 8, 2016):

We would like to use custom filed for same purpose, warranty contract expiry

@Kevgudge commented on GitHub (Dec 8, 2016): We would like to use custom filed for same purpose, warranty contract expiry
adam commented 2025-12-29 16:23:15 +01:00
Author
Owner
Copy Link

@mryauch commented on GitHub (Dec 14, 2016):

Some of these comments made me drool at the possibilities. I could add links to internal Wiki articles pertaining to specific device models.

@mryauch commented on GitHub (Dec 14, 2016): Some of these comments made me drool at the possibilities. I could add links to internal Wiki articles pertaining to specific device models.
adam commented 2025-12-29 16:23:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 14, 2016):

I think there's potential for confusing two ideas here:

  1. Add support for custom fields to device types. This could be used to track EOS/EOL info, for example. This would be trivial to implement.
  2. Display custom fields on individual devices based on their type. So for example, you could say "all Juniper QFX10K switches will have an is_broken custom field." This would be much more difficult to implement.

If all we're talking about is the first one, I'm happy to mark this as an enhancement and work on adding it. Otherwise, lots more discussion is likely needed.

@jeremystretch commented on GitHub (Dec 14, 2016): I think there's potential for confusing two ideas here: 1. Add support for custom fields to device types. This could be used to track EOS/EOL info, for example. This would be trivial to implement. 2. Display custom fields on individual devices based on their type. So for example, you could say "all Juniper QFX10K switches will have an `is_broken` custom field." This would be much more difficult to implement. If all we're talking about is the first one, I'm happy to mark this as an enhancement and work on adding it. Otherwise, lots more discussion is likely needed.
adam commented 2025-12-29 16:23:16 +01:00
Author
Owner
Copy Link

@NetBod commented on GitHub (Dec 14, 2016):

number 1 from my point of view.
Thanks

@NetBod commented on GitHub (Dec 14, 2016): number 1 from my point of view. Thanks
adam commented 2025-12-29 16:23:16 +01:00
Author
Owner
Copy Link

@xxiii23 commented on GitHub (Dec 18, 2018):

[...]
2. Display custom fields on individual devices based on their type. [...]

If all we're talking about is the first one, I'm happy to mark this as an enhancement and work on adding it. Otherwise, lots more discussion is likely needed.

In our case, we have wireless devices that we need to record information such as the tilt, azimuth, and beamwidth, the transmit power, the frequency and bandwidth, what modulation modes this device supports, whether or not to show it on maps (in other systems that interface to netbox), what kind/gain of antenna or antennas are attached to this device, FCC callsign, and so on.

We've added a bunch of custom fields to "Device" to support this information, but its irrelevant for almost every other device we track in netbox. (for instance, I don't care what direction my routers are facing, or what the EIRP of my PDUs is, my switches don't have an FCC callsign, etc). meanwhile, we have another class of device that needs a different set of custom fields that external systems need to be able to query/reference.

Maybe we could encode this information in the comments field, but that seems awkward, and i'm not sure how easy it would be for our other systems to utilize the information via that path. Currently our programming team has chosen to just add a bunch of custom fields to "device" and we just ignore them when they are not applicable. At the very least, it would be nice if custom fields could at least specify which device_types they should be visible for (hidden from the rest).

@xxiii23 commented on GitHub (Dec 18, 2018): > [...] > 2. Display custom fields on individual devices based on their type. [...] > > If all we're talking about is the first one, I'm happy to mark this as an enhancement and work on adding it. Otherwise, lots more discussion is likely needed. In our case, we have wireless devices that we need to record information such as the tilt, azimuth, and beamwidth, the transmit power, the frequency and bandwidth, what modulation modes this device supports, whether or not to show it on maps (in other systems that interface to netbox), what kind/gain of antenna or antennas are attached to this device, FCC callsign, and so on. We've added a bunch of custom fields to "Device" to support this information, but its irrelevant for almost every other device we track in netbox. (for instance, I don't care what direction my routers are facing, or what the EIRP of my PDUs is, my switches don't have an FCC callsign, etc). meanwhile, we have another class of device that needs a different set of custom fields that external systems need to be able to query/reference. Maybe we could encode this information in the comments field, but that seems awkward, and i'm not sure how easy it would be for our other systems to utilize the information via that path. Currently our programming team has chosen to just add a bunch of custom fields to "device" and we just ignore them when they are not applicable. At the very least, it would be nice if custom fields could at least specify which device_types they should be visible for (hidden from the rest).
adam commented 2025-12-29 16:23:16 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 18, 2018):

You might want to look at config contexts.

@DanSheps commented on GitHub (Dec 18, 2018): You might want to look at config contexts.
adam commented 2025-12-29 16:23:16 +01:00
Author
Owner
Copy Link

@xxiii23 commented on GitHub (Dec 19, 2018):

This seems a bit awkward as we're expecting humans to fill out a form to define a new device, and the form in question just shows a big empty white box for local config context (and a note that its in JSON format), and doesn't even show any applicable outer config contexts for reference.

The custom fields on the other hand show up as fields, with a definite value type and name, and its obvious whats expected.

Perhaps if there was some sort of "front-end" over config contexts that would display them as additional fields and automatically create (or modify) a local context if the user changes the values for any particular device. (basically making them appear as custom fields on whatever the context applies to, while actually storing them as contexts at whatever level is appropriate behind the scenes). This would also do away with the "how come some things are fields, and other things are this programming code thingie" that some of our users might ask/wonder about.

So, we're either left with explaining JSON, and sticky notes with examples on them (and all the potential for errors), or explaining that they just need to ignore the non-applicable fields when working on a device for which they do not apply.

(I see though that config contexts are the answer to my musing about encoding information in the comments field, though my related concerns still seem applicable).

In short, config contexts are not user-friendly from a data-entry point of view.

@xxiii23 commented on GitHub (Dec 19, 2018): This seems a bit awkward as we're expecting humans to fill out a form to define a new device, and the form in question just shows a big empty white box for local config context (and a note that its in JSON format), and doesn't even show any applicable outer config contexts for reference. The custom fields on the other hand show up as fields, with a definite value type and name, and its obvious whats expected. Perhaps if there was some sort of "front-end" over config contexts that would display them as additional fields and automatically create (or modify) a local context if the user changes the values for any particular device. (basically making them appear as custom fields on whatever the context applies to, while actually storing them as contexts at whatever level is appropriate behind the scenes). This would also do away with the "how come some things are fields, and other things are this programming code thingie" that some of our users might ask/wonder about. So, we're either left with explaining JSON, and sticky notes with examples on them (and all the potential for errors), or explaining that they just need to ignore the non-applicable fields when working on a device for which they do not apply. (I see though that config contexts are the answer to my musing about encoding information in the comments field, though my related concerns still seem applicable). In short, config contexts are not user-friendly from a data-entry point of view.
adam commented 2025-12-29 16:23:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 19, 2018):

In our case, we have wireless devices that we need to record information such as the tilt, azimuth, and beamwidth, the transmit power, the frequency and bandwidth, what modulation modes this device supports, whether or not to show it on maps (in other systems that interface to netbox), what kind/gain of antenna or antennas are attached to this device, FCC callsign, and so on.

NetBox is an IPAM/DCIM application, and its scheme is necessarily restricted to holding data directly pertinent to those functions. Custom fields are provided to allow users to define reasonable additional fields, but these are intended for convenience only and should be use sparingly. Alternatively, config contexts are provided for storing large amounts of hierarchically distributed contextual data. If neither of these features suits your need, NetBox is probably not the product you're looking for.

@jeremystretch commented on GitHub (Dec 19, 2018): > In our case, we have wireless devices that we need to record information such as the tilt, azimuth, and beamwidth, the transmit power, the frequency and bandwidth, what modulation modes this device supports, whether or not to show it on maps (in other systems that interface to netbox), what kind/gain of antenna or antennas are attached to this device, FCC callsign, and so on. NetBox is an IPAM/DCIM application, and its scheme is necessarily restricted to holding data directly pertinent to those functions. Custom fields are provided to allow users to define reasonable additional fields, but these are intended for convenience only and should be use sparingly. Alternatively, config contexts are provided for storing large amounts of hierarchically distributed contextual data. If neither of these features suits your need, NetBox is probably not the product you're looking for.
adam commented 2025-12-29 16:23:17 +01:00
Author
Owner
Copy Link

@xxiii23 commented on GitHub (Dec 20, 2018):

Custom fields do suit the need, but it would be nice if they could be applied by device type, instead of all devices, this seems like an obvious extension mechanism to handle those cases that aren't built-in, since the facility for device types already exists.

For that matter, config contexts also fit, (and perhaps better since they can already be limited to what they apply to) other than being difficult and error prone for users.

If we use config contexts we will have to write our own user interface on top of it (treating netbox as an IPAM/DCIM database). I suspect as the path of least resistance though, we'll just live with the custom fields being visible for all devices.

I notice you have PDU devices (which we are using), which allow you to add power outlets. and yet when I add a router device, I can't add power outlets. So it seems you already recognize that not every datacenter device is the same. I'm simply asking that the custom field facility also recognize this; or alternatively:

If a local context exists, or an applicable non-local context exists:

Additional fields a presented, modeled on this context (appearing the way custom fields currently do, but really being the custom context underneath):

If a user alters one or more fields, the underlying local context is either altered, or generated as necessary.

In short, for individual devices, the JSON (or whatever the JSON really turns into) is handled behind the scenes, and users see a friendly, consistent interface when adding/editing a device. (there could be a mechanism provided for advanced/allowed users to still edit the JSON directly).

Someone (in our case, our staff maintaining netbox) will still have to hand-craft the custom context in the device-type (or wherever) that gets used to generate the end result for individual instances. (just like people currently have to create sites/device types/whatever) before handing it over for day to day operations.

If it worked this way, custom fields could probably be done away with entirely, as device contexts would be able to do anything they could do (with the caveat that I am not yet familiar with the Netbox API, so I don't know what the differences there might be).

I offer this as a suggestion for what I think would benefit and make Netbox a more useful and friendly product.

And finally, I'd like to emphasize that we are using this for IPAM/DCIM purposes. For example, we connect our datacenters together with Microwave links, and also with fiber links. We consider recording information relevant to those devices very pertinent to our data center infrastructure and our ability to manage it, but our fiber devices do not need to know where they are aimed or what kind of antenna they have, or what their legal operation parameters are; and our microwave devices don't need to know if they are single-mode or multi-mode, or BIDI, or which fiber strands of a 12 pair bundle are the applicable ones.

@xxiii23 commented on GitHub (Dec 20, 2018): Custom fields do suit the need, but it would be nice if they could be applied by device type, instead of all devices, this seems like an obvious extension mechanism to handle those cases that aren't built-in, since the facility for device types already exists. For that matter, config contexts also fit, (and perhaps better since they can already be limited to what they apply to) other than being difficult and error prone for users. If we use config contexts we will have to write our own user interface on top of it (treating netbox as an IPAM/DCIM database). I suspect as the path of least resistance though, we'll just live with the custom fields being visible for all devices. I notice you have PDU devices (which we are using), which allow you to add power outlets. and yet when I add a router device, I can't add power outlets. So it seems you already recognize that not every datacenter device is the same. I'm simply asking that the custom field facility also recognize this; or alternatively: If a local context exists, or an applicable non-local context exists: Additional fields a presented, modeled on this context (appearing the way custom fields currently do, but really being the custom context underneath): If a user alters one or more fields, the underlying local context is either altered, or generated as necessary. In short, for individual devices, the JSON (or whatever the JSON really turns into) is handled behind the scenes, and users see a friendly, consistent interface when adding/editing a device. (there could be a mechanism provided for advanced/allowed users to still edit the JSON directly). Someone (in our case, our staff maintaining netbox) will still have to hand-craft the custom context in the device-type (or wherever) that gets used to generate the end result for individual instances. (just like people currently have to create sites/device types/whatever) before handing it over for day to day operations. If it worked this way, custom fields could probably be done away with entirely, as device contexts would be able to do anything they could do (with the caveat that I am not yet familiar with the Netbox API, so I don't know what the differences there might be). I offer this as a suggestion for what I think would benefit and make Netbox a more useful and friendly product. And finally, I'd like to emphasize that we are using this for IPAM/DCIM purposes. For example, we connect our datacenters together with Microwave links, and also with fiber links. We consider recording information relevant to those devices very pertinent to our data center infrastructure and our ability to manage it, but our fiber devices do not need to know where they are aimed or what kind of antenna they have, or what their legal operation parameters are; and our microwave devices don't need to know if they are single-mode or multi-mode, or BIDI, or which fiber strands of a 12 pair bundle are the applicable ones.
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 type: feature
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#563
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?