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

Nested custom fields/Hierarchical custom fields #8279

New Issue
Closed
opened 2025-12-29 20:34:39 +01:00 by adam · 3 comments
adam commented 2025-12-29 20:34:39 +01:00
Owner
Copy Link

Originally created by @roadracer96 on GitHub (Jul 3, 2023).

NetBox version

v3.3.5

Feature type

Data model extension

Proposed functionality

Currently, custom fields can get assigned to any data model within Netbox. However, custom fields themselves only have a "depth" of one element (Except in the case of JSON types). This is limiting if you need to apply independent meta to each data associated with Custom fields. This can currently be done using JSON field types but is only really functional external to the GUI.

I would propose permitting a custom field to be a CHILD of another custom field. By permitting this, custom fields become multi-dimensional and the value of the data provided by them would scale much better.

Use case

This is only a generic example but I could think of countless uses for it. Potentially eliminating the need for some plugins.

Custom field "tenant_relationship" is a custom field of type multiple-objects assigned to the tenant model. The purpose is to create relationship from 1 to many tenants. To facilitate instance specific functionality in the relationships, We could create a Multiple Select field "tenant_relationship_action1" with a list of actions and an Integer field "tenant_relationship_weight".

Example API output:

"id": 1,
"name": "tenant1",
"custom_fields": {
    "tenant_relationship": [
        {
            "id": 2,
            "name": "tenant2",
            "custom_fields": {
                "tenant_relationship_action1": "SomeAction",
                "tenant_relationship_weight": 100
            }
        },
        {
            "id": 3,
            "name": "tenant3",
            "custom_fields": {
                "tenant_relationship_action1": "SomeOtherAction",
                "tenant_relationship_weight": 200
            }
        },
    ]
},

Previously, this would only be possible in a JSON field type and would not be visible in the GUI (In a user friendly way and with no restrictions or validation of the data entered). It should not be specific to tenants or any other model but a generic function applicable to any model. There may be the need to limit nesting to prevent endless loops. Maybe have a user defined nesting limit?

Database changes

This is beyond my knowledge level :D

External dependencies

I dont see why there would be any.

Originally created by @roadracer96 on GitHub (Jul 3, 2023). ### NetBox version v3.3.5 ### Feature type Data model extension ### Proposed functionality Currently, custom fields can get assigned to any data model within Netbox. However, custom fields themselves only have a "depth" of one element (Except in the case of JSON types). This is limiting if you need to apply independent meta to each data associated with Custom fields. This can currently be done using JSON field types but is only really functional external to the GUI. I would propose permitting a custom field to be a CHILD of another custom field. By permitting this, custom fields become multi-dimensional and the value of the data provided by them would scale much better. ### Use case This is only a generic example but I could think of countless uses for it. Potentially eliminating the need for some plugins. Custom field "tenant_relationship" is a custom field of type multiple-objects assigned to the tenant model. The purpose is to create relationship from 1 to many tenants. To facilitate instance specific functionality in the relationships, We could create a Multiple Select field "tenant_relationship_action1" with a list of actions and an Integer field "tenant_relationship_weight". Example API output: ``` "id": 1, "name": "tenant1", "custom_fields": { "tenant_relationship": [ { "id": 2, "name": "tenant2", "custom_fields": { "tenant_relationship_action1": "SomeAction", "tenant_relationship_weight": 100 } }, { "id": 3, "name": "tenant3", "custom_fields": { "tenant_relationship_action1": "SomeOtherAction", "tenant_relationship_weight": 200 } }, ] }, ``` Previously, this would only be possible in a JSON field type and would not be visible in the GUI (In a user friendly way and with no restrictions or validation of the data entered). It should not be specific to tenants or any other model but a generic function applicable to any model. There may be the need to limit nesting to prevent endless loops. Maybe have a user defined nesting limit? ### Database changes This is beyond my knowledge level :D ### External dependencies I dont see why there would be any.
adam added the type: featurestatus: revisions needed labels 2025-12-29 20:34:39 +01:00
adam closed this issue 2025-12-29 20:34:39 +01:00
adam commented 2025-12-29 20:34:40 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jul 3, 2023):

I'm having a really hard time understanding exactly this is intended to work. Could you give a real-world usecase instead of a made up one, I think that would help explain your idea more clearly.

I think this is specifically where I'm the most confused:

To facilitate instance specific functionality in the relationships, We could create a Multiple Select field "tenant_relationship_action1" with a list of actions and an Integer field "tenant_relationship_weight".

I just don't know what you mean as it's so generic. What is "instance specific functionality" supposed to be?

Also, I can say with a fair bit of certainty, that whatever the intention is, it's unlikely to be accepted as custom fields are not intended for such advanced usecases. The performance of object type custom fields is already abysmal and building more complex logic ontop is ill advised.

@kkthxbye-code commented on GitHub (Jul 3, 2023): I'm having a really hard time understanding exactly this is intended to work. Could you give a real-world usecase instead of a made up one, I think that would help explain your idea more clearly. I think this is specifically where I'm the most confused: > To facilitate instance specific functionality in the relationships, We could create a Multiple Select field "tenant_relationship_action1" with a list of actions and an Integer field "tenant_relationship_weight". I just don't know what you mean as it's so generic. What is "instance specific functionality" supposed to be? Also, I can say with a fair bit of certainty, that whatever the intention is, it's unlikely to be accepted as custom fields are not intended for such advanced usecases. [The performance of object type custom fields is already abysmal](https://github.com/netbox-community/netbox/issues/12917) and building more complex logic ontop is ill advised.
adam commented 2025-12-29 20:34:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 5, 2023):

I would propose permitting a custom field to be a CHILD of another custom field. By permitting this, custom fields become multi-dimensional and the value of the data provided by them would scale much better.

I'm afraid this far exceeds the intended functionality of custom fields and is not tenable. For anything more complex than what is currently provided, you'll need to develop a custom plugin to implement the models and relationships you seek.

@jeremystretch commented on GitHub (Jul 5, 2023): > I would propose permitting a custom field to be a CHILD of another custom field. By permitting this, custom fields become multi-dimensional and the value of the data provided by them would scale much better. I'm afraid this far exceeds the intended functionality of custom fields and is not tenable. For anything more complex than what is currently provided, you'll need to develop a custom plugin to implement the models and relationships you seek.
adam commented 2025-12-29 20:34:40 +01:00
Author
Owner
Copy Link

@roadracer96 commented on GitHub (Jul 5, 2023):

In the case where items are allowed to be selected (Multiple Object, Multiple Selection), I would consider each list item to be an instance of the custom field. Meaning.

My use case is this:

We store our eBGP peers (Customer, Transit, Non-Transit, etc) in Netbox. We assign a custom field to them that tracks the "Peer ID". The Peer ID is used to construct a series of BGP communities that are used for traffic engineering to/from that peer. We assign similar BGP communities tracking the region and site the route was learned from.

All of our eBGP peers are linked to Tenants. Each Tenant has a series of custom fields that describe various aspects relative to BGP. Prefix limits, IRR records, Prefix lists resolved from IRR that are used to build IRR based filters, etc. Prefixes assigned to the Tenant are used to build the peers import policies.

One such field is "BGP Reject To". (Assigned to both prefixes and Tenants). This is a Multiple Object type. The use is to select Tenants (Peers) that you do not want to advertise routes to when learned from the parent.

Where this starts to blow up is if we want to have "BGP Prepend [1,2,4,8]x To". It would be much neater to have a "BGP Action" Custom field where you choose the target tenant, with sub options Action and Action Count. Action would be Reject or Prepend. Action count would be a no-op for Reject or a count of prepends when action is Prepend. The same logic would apply on a per prefix bases.

@roadracer96 commented on GitHub (Jul 5, 2023): In the case where items are allowed to be selected (Multiple Object, Multiple Selection), I would consider each list item to be an instance of the custom field. Meaning. My use case is this: We store our eBGP peers (Customer, Transit, Non-Transit, etc) in Netbox. We assign a custom field to them that tracks the "Peer ID". The Peer ID is used to construct a series of BGP communities that are used for traffic engineering to/from that peer. We assign similar BGP communities tracking the region and site the route was learned from. All of our eBGP peers are linked to Tenants. Each Tenant has a series of custom fields that describe various aspects relative to BGP. Prefix limits, IRR records, Prefix lists resolved from IRR that are used to build IRR based filters, etc. Prefixes assigned to the Tenant are used to build the peers import policies. One such field is "BGP Reject To". (Assigned to both prefixes and Tenants). This is a Multiple Object type. The use is to select Tenants (Peers) that you do not want to advertise routes to when learned from the parent. Where this starts to blow up is if we want to have "BGP Prepend [1,2,4,8]x To". It would be much neater to have a "BGP Action" Custom field where you choose the target tenant, with sub options Action and Action Count. Action would be Reject or Prepend. Action count would be a no-op for Reject or a count of prepends when action is Prepend. The same logic would apply on a per prefix bases.
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: revisions needed 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#8279
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?