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

Expose Custom Fields via API #4217

New Issue
Closed
opened 2025-12-29 18:33:55 +01:00 by adam · 5 comments
adam commented 2025-12-29 18:33:55 +01:00
Owner
Copy Link

Originally created by @adamwoolhether on GitHub (Oct 27, 2020).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.6.8
  • NetBox version: 2.9.7

Proposed Functionality

Currently, Custom Fields can only be added/modified through the Admin console. A Custom Fields plugin cannot be implemented for Netbox's Ansible modules until Custom fields are exposed via API (see: https://github.com/netbox-community/ansible_modules/issues/335)

We use a lot of custom modules to keep track of an individual machine's internal hardware for inventory tracking, Exposing custom modules via API would allow more efficient management of custom fields.

Use Case

Configure, create, and manage custom fields without having to login to Netbox's web UI Admin console would further increase the ability to manage the environment through Ansible.

I work for a large HW manufacturer, and rather than managing a single Netbox env, we potentially deploy different Netbox environments for a specific isolated department, team, or different customers. We utilize anywhere from 10-15 different custom fields for each, and input the values with information extracted from the machine itself(ex: CPU type, amt, Interface MAC, GPU etc).

We automatically install, setup, and conduct initial data-population via ansible playbooks. Each time, however, requires manual intervention between steps 2 & 3, to create the custom fields from within the Netbox UI.

Database Changes

Forgive me, this is not my area of expertise and I can't offer any relevant information...

External Dependencies

No new external dependencies should be required.

Originally created by @adamwoolhether on GitHub (Oct 27, 2020). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.6.8 * NetBox version: 2.9.7 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Currently, Custom Fields can only be added/modified through the Admin console. A Custom Fields plugin cannot be implemented for Netbox's Ansible modules until Custom fields are exposed via API (see: https://github.com/netbox-community/ansible_modules/issues/335) We use a lot of custom modules to keep track of an individual machine's internal hardware for inventory tracking, Exposing custom modules via API would allow more efficient management of custom fields. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case Configure, create, and manage custom fields without having to login to Netbox's web UI Admin console would further increase the ability to manage the environment through Ansible. I work for a large HW manufacturer, and rather than managing a single Netbox env, we potentially deploy different Netbox environments for a specific isolated department, team, or different customers. We utilize anywhere from 10-15 different custom fields for each, and input the values with information extracted from the machine itself(ex: CPU type, amt, Interface MAC, GPU etc). We automatically install, setup, and conduct initial data-population via ansible playbooks. Each time, however, requires manual intervention between steps 2 & 3, to create the custom fields from within the Netbox UI. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes Forgive me, this is not my area of expertise and I can't offer any relevant information... <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies No new external dependencies should be required.
adam added the status: acceptedtype: feature labels 2025-12-29 18:33:55 +01:00
adam closed this issue 2025-12-29 18:33:55 +01:00
adam commented 2025-12-29 18:33:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 27, 2020):

Configure, create, and manage custom fields without having to login to Netbox's web UI Admin console would further increase the ability to manage the environment through Ansible.

You've described the functionality being proposed, but could you expand on your specific use case? Custom fields are intended to serve as long-term attributes used to extend select models in a specific way: They don't typically change much beyond initial creation, and it's difficult to imagine a case where creating new fields using a tool such as Ansible makes sense.

@jeremystretch commented on GitHub (Oct 27, 2020): > Configure, create, and manage custom fields without having to login to Netbox's web UI Admin console would further increase the ability to manage the environment through Ansible. You've described the functionality being proposed, but could you expand on your specific use case? Custom fields are intended to serve as long-term attributes used to extend select models in a specific way: They don't typically change much beyond initial creation, and it's difficult to imagine a case where creating new fields using a tool such as Ansible makes sense.
adam commented 2025-12-29 18:33:55 +01:00
Author
Owner
Copy Link

@arjenvri commented on GitHub (Oct 31, 2020):

I am having the same need, in our case the use case is running Netbox in a CI/CD environment where all Netbox configuration is managed by code and redeployed frequently.

@arjenvri commented on GitHub (Oct 31, 2020): I am having the same need, in our case the use case is running Netbox in a CI/CD environment where all Netbox configuration is managed by code and redeployed frequently.
adam commented 2025-12-29 18:33:55 +01:00
Author
Owner
Copy Link

@adamwoolhether commented on GitHub (Nov 2, 2020):

Configure, create, and manage custom fields without having to login to Netbox's web UI Admin console would further increase the ability to manage the environment through Ansible.

You've described the functionality being proposed, but could you expand on your specific use case? Custom fields are intended to serve as long-term attributes used to extend select models in a specific way: They don't typically change much beyond initial creation, and it's difficult to imagine a case where creating new fields using a tool such as Ansible makes sense.

Hi @jeremystretch . Definitely. I work for a large HW manufacturer, and rather than managing a single Netbox env, we potentially deploy different Netbox environments for a specific isolated department, team, or different customers. We utilize anywhere from 10-15 different custom fields for each, and input the values with information extracted from the machine itself(ex: CPU type, amt, Interface MAC, GPU etc).

We automatically install, setup, and conduct initial data-population via ansible playbooks. Each time, however, requires manual intervention between steps 2 & 3, to create the custom fields from within the Netbox UI.

You're correct, they don't change much beyond creation, but creating many different environments with 10+ custom fields greatly impacts the deployment speed.

@adamwoolhether commented on GitHub (Nov 2, 2020): > > Configure, create, and manage custom fields without having to login to Netbox's web UI Admin console would further increase the ability to manage the environment through Ansible. > > You've described the functionality being proposed, but could you expand on your specific use case? Custom fields are intended to serve as long-term attributes used to extend select models in a specific way: They don't typically change much beyond initial creation, and it's difficult to imagine a case where creating new fields using a tool such as Ansible makes sense. Hi @jeremystretch . Definitely. I work for a large HW manufacturer, and rather than managing a single Netbox env, we potentially deploy different Netbox environments for a specific isolated department, team, or different customers. We utilize anywhere from 10-15 different custom fields for each, and input the values with information extracted from the machine itself(ex: CPU type, amt, Interface MAC, GPU etc). We automatically install, setup, and conduct initial data-population via ansible playbooks. Each time, however, requires manual intervention between steps 2 & 3, to create the custom fields from within the Netbox UI. You're correct, they don't change much beyond creation, but creating many different environments with 10+ custom fields greatly impacts the deployment speed.
adam commented 2025-12-29 18:33:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 23, 2020):

We might actually have to push this up to v2.10. As part of the overhaul under #4878, the current /api/extras/_custom_field_choices/ REST API endpoint was removed. While we could reproduce its output under the new model, doing so certainly feels like a kludge given that all choices are now stored within CustomField instances. It's probably best just to push forward with adding REST API support for custom fields to avoid losing any functionality.

I don't yet have a good idea how much work this will entail or by how long it might delay the final v2.10 release.

@jeremystretch commented on GitHub (Nov 23, 2020): We might actually have to push this up to v2.10. As part of the overhaul under #4878, the current `/api/extras/_custom_field_choices/` REST API endpoint was removed. While we _could_ reproduce its output under the new model, doing so certainly feels like a kludge given that all choices are now stored within CustomField instances. It's probably best just to push forward with adding REST API support for custom fields to avoid losing any functionality. I don't yet have a good idea how much work this will entail or by how long it might delay the final v2.10 release.
adam commented 2025-12-29 18:33:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 23, 2020):

Went ahead with this in the current develop-2.10 branch. Might push out a second 2.10 beta to capture it for further testing soon.

@jeremystretch commented on GitHub (Nov 23, 2020): Went ahead with this in the current `develop-2.10` branch. Might push out a second 2.10 beta to capture it for further testing soon.
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 status: accepted 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#4217
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?