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

possibility to GET Custom_fields from API #1514

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

Originally created by @ZdenekPesek on GitHub (Jan 26, 2018).

Issue type

[ x] Feature request
[ ] Bug report
[ ] Documentation

Environment

Python 2.7.12
Netbox 2.2.8

Description

As there is possible to define a lot of IPAM Custom_Fields, it would be useful to have also possibility to GET all those key/value/label back from API, same as static_choice.

Use case:
I have YAML file which can POST new IP records in batch, i need to define the Custom_Fields for every record. But i am not able to define which value corresponds with which label, therefore i would like to make a GET call for it before and then i can see which value is what label and can complete YAML file with proper Custom_Fields values.

Originally created by @ZdenekPesek on GitHub (Jan 26, 2018). ## Issue type [ x] Feature request [ ] Bug report [ ] Documentation ### Environment Python 2.7.12 Netbox 2.2.8 ### Description As there is possible to define a lot of IPAM Custom_Fields, it would be useful to have also possibility to GET all those key/value/label back from API, same as static_choice. **Use case:** I have YAML file which can POST new IP records in batch, i need to define the Custom_Fields for every record. But i am not able to define which value corresponds with which label, therefore i would like to make a GET call for it before and then i can see which value is what label and can complete YAML file with proper Custom_Fields values.
adam added the type: featurestatus: duplicate labels 2025-12-29 16:32:35 +01:00
adam closed this issue 2025-12-29 16:32:35 +01:00
adam commented 2025-12-29 16:32:36 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Jan 26, 2018):

To add to this, the idea is that custom fields with a type of Selection should have their preset choices available in the API. This functionality would be similar to the _choices API endpoints already present today.

I do not believe this should introduce any other API functionality surrounding custom fields.

@lampwins commented on GitHub (Jan 26, 2018): To add to this, the idea is that custom fields with a type of `Selection` should have their preset choices available in the API. This functionality would be similar to the `_choices` API endpoints already present today. I do not believe this should introduce any other API functionality surrounding custom fields.
adam commented 2025-12-29 16:32:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 26, 2018):

@PacketBucket Could you please provide an example API request and response illustrating the functionality being proposed?

@jeremystretch commented on GitHub (Jan 26, 2018): @PacketBucket Could you please provide an example API request and response illustrating the functionality being proposed?
adam commented 2025-12-29 16:32:36 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (Jan 29, 2018):

I asked for this as well in https://github.com/digitalocean/netbox/issues/1792.

As a concrete proposal I could imagine an endpoint https://netbox/api/ipam/ip-addresses/_choices/, which would return all the possible values with their respective key in a format similar to https://netbox/api/ipam/_choices/.

@cimnine commented on GitHub (Jan 29, 2018): I asked for this as well in https://github.com/digitalocean/netbox/issues/1792. As a concrete proposal I could imagine an endpoint https://netbox/api/ipam/ip-addresses/_choices/, which would return all the possible values with their respective key in a format similar to https://netbox/api/ipam/_choices/.
adam commented 2025-12-29 16:32:36 +01:00
Author
Owner
Copy Link

@ZdenekPesek commented on GitHub (Jan 29, 2018):

Maybe i would have two proposals and we can agree on what is more suitable for us.

As custom fields are defined on one place https://netbox/admin/extras/customfield/
I would imagine to GET all those info from https://netbox/api/extras/customfield/

This is approximate model what I would imagine as output, it is yaml just for better reading
(other types as URL should use same model, I'm not familiar with defining it yet) and should return all custom fields which have been defined, as for example:

---
hostname:
  required: true
  type: Text
  values:
  models:
    - ipaddress
status_scan:
  required: false
  type: Boolean
  values:
  models:
    - ipaddress
    - prefix 
owner:
  required: true
  type: Selection
  values:
    - value: ICT
      label: 12
    - value: Finance
      label: 31
  models:
    - prefix
    - ipaddress
    - vlan
anything:
  required: false
  type: Text
  values:
  models:
    - ipaddress
    - device

Second thought is more the same as _choice in every API item or how to say... (circuit, dcim, extras, ..., virtualization), every such an item would have its own /customfield/ and output would give us all custom fields according models defined in objects for each custom field in /admin/extras/customfield/.
If I take two custom fields from above that would mean:

Custom Field "owner"
Objects:
ipam > prefix
ipam > ipaddress
ipam > vlan

Custom Field "anything"
Objects:
ipam > ipaddress
dcim > device

using GET from https://netbox/api/ipam/customfield/ would return both custom fields above as both have objects ipam in it,

---
owner:
  required: true
  type: Selection
  values:
    - value: ICT
      label: 12
    - value: Finance
      label: 31
  models:
    - prefix
    - ipaddress
    - vlan
anything:
  required: false
  type: Text
  values:
  models:
    - ipaddress
    - device

on other hand https://netbox/api/dcim/customfield/ would return just "anything" custom field

---
anything:
  required: false
  type: Text
  values:
  models:
    - ipaddress
    - device

as i now got all those info together, i think first proposal does make me more sense, and that just from one reason, to have all fields available from one url.
I thing its better to have one request and GET all of the data, than iterate over bunch of URLs with the more less same output.

Just let me know your thoughts, ideas.

@ZdenekPesek commented on GitHub (Jan 29, 2018): Maybe i would have two proposals and we can agree on what is more suitable for us. 1) As custom fields are defined on one place https://netbox/admin/extras/customfield/ I would imagine to GET all those info from https://netbox/api/extras/customfield/ This is approximate model what I would imagine as output, it is yaml just for better reading (other types as URL should use same model, I'm not familiar with defining it yet) and should return all custom fields which have been defined, as for example: ```yaml --- hostname: required: true type: Text values: models: - ipaddress status_scan: required: false type: Boolean values: models: - ipaddress - prefix owner: required: true type: Selection values: - value: ICT label: 12 - value: Finance label: 31 models: - prefix - ipaddress - vlan anything: required: false type: Text values: models: - ipaddress - device ``` 2) Second thought is more the same as _choice in every API item or how to say... (circuit, dcim, extras, ..., virtualization), every such an item would have its own /customfield/ and output would give us all custom fields according models defined in objects for each custom field in /admin/extras/customfield/. If I take two custom fields from above that would mean: Custom Field "owner" Objects: ipam > prefix ipam > ipaddress ipam > vlan Custom Field "anything" Objects: ipam > ipaddress dcim > device using GET from https://netbox/api/ipam/customfield/ would return both custom fields above as both have objects ipam in it, ```yaml --- owner: required: true type: Selection values: - value: ICT label: 12 - value: Finance label: 31 models: - prefix - ipaddress - vlan anything: required: false type: Text values: models: - ipaddress - device ``` on other hand https://netbox/api/dcim/customfield/ would return just "anything" custom field ```yaml --- anything: required: false type: Text values: models: - ipaddress - device ``` as i now got all those info together, i think first proposal does make me more sense, and that just from one reason, to have all fields available from one url. I thing its better to have one request and GET all of the data, than iterate over bunch of URLs with the more less same output. Just let me know your thoughts, ideas.
adam commented 2025-12-29 16:32:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 30, 2018):

I agree with @cimnine, this looks like it mostly overlaps with #1792 so I'm going to mark it as a duplicate. It will be linked from the other issue though, so thank you for providing the example cases.

@jeremystretch commented on GitHub (Jan 30, 2018): I agree with @cimnine, this looks like it mostly overlaps with #1792 so I'm going to mark it as a duplicate. It will be linked from the other issue though, so thank you for providing the example cases.
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: duplicate 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#1514
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?