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

Add type yaml for custom fields #11306

New Issue
Open
opened 2025-12-29 21:43:20 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:43:20 +01:00
Owner
Copy Link

Originally created by @kikoshiro on GitHub (Jun 22, 2025).

NetBox version

v4.3.2

Feature type

Other

Proposed functionality

Hello,
when i create a new custom field, i have to select a "Type" and i can select JSON. Thats very nice but in fact, as i am a human, YAML would be much easy to write for me.

Is it possible to offer YAML too in the "Type" field?

Thank you so much in advance. NetBox is such a great Tool.

Cheers

Use case

Human Read/Write-Ability

Database changes

i dont konw

External dependencies

Not that i know

Originally created by @kikoshiro on GitHub (Jun 22, 2025). ### NetBox version v4.3.2 ### Feature type Other ### Proposed functionality Hello, when i create a new custom field, i have to select a "**Type**" and i can select **JSON**. Thats very nice but in fact, as i am a human, YAML would be much easy to write for me. Is it possible to offer YAML too in the "**Type**" field? Thank you so much in advance. NetBox is such a great Tool. Cheers ### Use case Human Read/Write-Ability ### Database changes i dont konw ### External dependencies Not that i know
adam added the type: featurecomplexity: mediumnetboxstatus: backlog labels 2025-12-29 21:43:20 +01:00
adam commented 2025-12-29 21:43:21 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Jun 25, 2025):

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

I know this is a bit of a form reply, but as is, we can't really do anything with this feature request without more details. Adding a YAML custom field type could introduce added complexity and some tricky challenges, including conflicting with the JSON custom field type's backing store (JSON in the DB) and converting to/from for display and edits.

@jnovinger commented on GitHub (Jun 25, 2025): Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed. I know this is a bit of a form reply, but as is, we can't really do anything with this feature request without more details. Adding a YAML custom field type could introduce added complexity and some tricky challenges, including conflicting with the JSON custom field type's backing store (JSON in the DB) and converting to/from for display and edits.
adam commented 2025-12-29 21:43:22 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 3, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Jul 3, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:43:22 +01:00
Author
Owner
Copy Link

@kikoshiro commented on GitHub (Jul 8, 2025):

Hello thanks for your detailed reply, i tried the following to meet your requirements, how about this:

Proposed functionality

Introduce support for a YAML custom field type alongside the existing JSON type. This would allow users to input and view structured data in YAML format, which is often more human-readable and writable than JSON.

The YAML field would:

  • Accept YAML input in the UI.
  • Convert YAML to JSON for storage in the database (to maintain compatibility with the existing JSON backend).
  • Convert JSON back to YAML for display and editing in the UI.
  • This would be similar to how some configuration tools (e.g., Ansible, Kubernetes manifests) allow YAML input but operate on JSON internally.

Use case

Many users find YAML easier to read and write than JSON, especially for nested structures. For example, defining a list of dictionaries or hierarchical configuration is more concise and readable in YAML.

This feature would:

  • Improve the user experience for non-developers or those less familiar with JSON syntax.
  • Reduce syntax errors (e.g., missing commas or brackets).
  • Align with tools and workflows that already use YAML.

Database changes

  • No changes to the database schema are required. The YAML field would be stored as JSON in the database, just like the current JSON field type. The conversion between YAML and JSON would happen at the application layer.

External dependencies

  • PyYAML or similar library for YAML parsing and validation.
  • Optional: A YAML syntax highlighter for the UI (e.g., CodeMirror or Monaco editor with YAML support).

best regards

kiko

@kikoshiro commented on GitHub (Jul 8, 2025): Hello thanks for your detailed reply, i tried the following to meet your requirements, how about this: *** ### Proposed functionality Introduce support for a YAML custom field type alongside the existing JSON type. This would allow users to input and view structured data in YAML format, which is often more human-readable and writable than JSON. **The YAML field would:** - Accept YAML input in the UI. - Convert YAML to JSON for storage in the database (to maintain compatibility with the existing JSON backend). - Convert JSON back to YAML for display and editing in the UI. - This would be similar to how some configuration tools (e.g., Ansible, Kubernetes manifests) allow YAML input but operate on JSON internally. ### Use case Many users find YAML easier to read and write than JSON, especially for nested structures. For example, defining a list of dictionaries or hierarchical configuration is more concise and readable in YAML. **This feature would:** - Improve the user experience for non-developers or those less familiar with JSON syntax. - Reduce syntax errors (e.g., missing commas or brackets). - Align with tools and workflows that already use YAML. ### Database changes - No changes to the database schema are required. The YAML field would be stored as JSON in the database, just like the current JSON field type. The conversion between YAML and JSON would happen at the application layer. ### External dependencies - PyYAML or similar library for YAML parsing and validation. - Optional: A YAML syntax highlighter for the UI (e.g., CodeMirror or Monaco editor with YAML support). *** best regards kiko
adam commented 2025-12-29 21:43:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 10, 2025):

Introduce support for a YAML custom field type alongside the existing JSON type.

Introducing a new type of custom field solely to effect a change in formatting would be unwarranted (not to mention technically infeasible). I suspect what you want instead is the option to read and write data to a JSON custom field in YAML format. Presumably this would be limited to changes within the web UI to support YAML data entry and formatting. We could leverage the existing "data format" user preference to default to either JSON or YAML. Does that sound right?

@jeremystretch commented on GitHub (Jul 10, 2025): > Introduce support for a YAML custom field type alongside the existing JSON type. Introducing a new type of custom field solely to effect a change in formatting would be unwarranted (not to mention technically infeasible). I suspect what you want instead is the option to read and write data to a JSON custom field in YAML format. Presumably this would be limited to changes within the web UI to support YAML data entry and formatting. We could leverage the existing "data format" user preference to default to either JSON or YAML. Does that sound right?
adam commented 2025-12-29 21:43:22 +01:00
Author
Owner
Copy Link

@kikoshiro commented on GitHub (Jul 14, 2025):

Yes, that sounds Great to me — thank you!

Anything else i need to do here from now?

Best Regards

@kikoshiro commented on GitHub (Jul 14, 2025): Yes, that sounds Great to me — thank you! Anything else i need to do here from now? Best Regards
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 complexity: medium netbox status: backlog 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#11306
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?