jinja based custom field type #5870

New Issue

adam · 2025-12-29T19:33:39+01:00

adam commented

2025-12-29 19:33:39 +01:00

Originally created by @ryanmerolle on GitHub (Jan 4, 2022).

NetBox version

v3.1.4

Feature type

New functionality

Proposed functionality

Similar to export templates usage of jinja and object relationships, it would be nice to have a custom field type that is generated solely based on jinja.

Use case

A basic use case would be to auto generate interface descriptions based on the remote peer (interface & device name) or even the circuit ID & carrier name if connected to a circuit.

Database changes

No response

External dependencies

No response

Originally created by @ryanmerolle on GitHub (Jan 4, 2022). ### NetBox version v3.1.4 ### Feature type New functionality ### Proposed functionality Similar to export templates usage of jinja and object relationships, it would be nice to have a custom field type that is generated solely based on jinja. ### Use case A basic use case would be to auto generate interface descriptions based on the remote peer (interface & device name) or even the circuit ID & carrier name if connected to a circuit. ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature pending closure status: under review labels 2025-12-29 19:33:39 +01:00

adam closed this issue

2025-12-29 19:33:39 +01:00

adam commented

2025-12-29 19:33:39 +01:00

@jeremystretch commented on GitHub (Jan 4, 2022):

A basic use case would be to auto generate interface descriptions based on the remote peer (interface & device name) or even the circuit ID & carrier name if connected to a circuit.

I'm not sure I understand the use case for this. Why wouldn't this be done on the client side? Off the bat, I can see several issues:

The overhead imposed by rendering these fields occurs every time, regardless of whether the value is actually needed by the client.
Accessing data beyond what's provided in the model being queried greatly complicates database querying, and can easily lead to performance issues.
Any changes to the field's template can potentially effect a breaking API change, which is not communicated to the client.

@jeremystretch commented on GitHub (Jan 4, 2022): > A basic use case would be to auto generate interface descriptions based on the remote peer (interface & device name) or even the circuit ID & carrier name if connected to a circuit. I'm not sure I understand the use case for this. Why wouldn't this be done on the client side? Off the bat, I can see several issues: * The overhead imposed by rendering these fields occurs every time, regardless of whether the value is actually needed by the client. * Accessing data beyond what's provided in the model being queried greatly complicates database querying, and can easily lead to performance issues. * Any changes to the field's template can potentially effect a breaking API change, which is not communicated to the client.

adam commented

2025-12-29 19:33:40 +01:00

@ryanmerolle commented on GitHub (Jan 4, 2022):

I think most people (including myself) do this on the client side currently. It would be nice to have it viewable in the UI and stored in NetBox. To your point its not a must.
Fair point on overhead. Other DCIM solutions handle this on the server & the custom links model does something similar. I figured I would ask since I have seen users ask about a similar feature. If something we are not doing, its good to have an issue so people can see why.
The API impact is not something I thought of. Most people would be ok with that because they likely interface with the API as opposed to outside resources. But this is a good point.

@ryanmerolle commented on GitHub (Jan 4, 2022): 1. I think most people (including myself) do this on the client side currently. It would be nice to have it viewable in the UI and stored in NetBox. To your point its not a must. 2. Fair point on overhead. Other DCIM solutions handle this on the server & the custom links model does something similar. I figured I would ask since I have seen users ask about a similar feature. If something we are not doing, its good to have an issue so people can see why. 3. The API impact is not something I thought of. Most people would be ok with that because they likely interface with the API as opposed to outside resources. But this is a good point.

adam commented

2025-12-29 19:33:40 +01:00

@sdktr commented on GitHub (Jan 5, 2022):

It should only render in the api response if explicitely requested by the client. Like a regular custom field the format can indeed change over time, this is inheritely to the self defined field imo.

The big advantage is the fields are defined once, instead of multiple places like multiple export templates, script and within the external clients.

+1 vote from me🙂

@sdktr commented on GitHub (Jan 5, 2022): It should only render in the api response if explicitely requested by the client. Like a regular custom field the format can indeed change over time, this is inheritely to the self defined field imo. The big advantage is the fields are defined once, instead of multiple places like multiple export templates, script and within the external clients. +1 vote from me🙂

adam commented

2025-12-29 19:33:40 +01:00

@jeremystretch commented on GitHub (Jan 5, 2022):

It should only render in the api response if explicitely requested by the client.

This is not how a REST API is intended to function, and should be considered an anti-pattern to be avoided. The only place we currently allow toggling a specific field is device/VM config contexts (and I'd prefer to eliminate that).

Like a regular custom field the format can indeed change over time

This is not typical for a custom field. Once you've defined, for example, an integer custom field, it is unlikely that you'll later change it to e.g. a string type. But if you do, at least the new type is conveyed in the custom field's type field. Not so with a rendered template, which is completely arbitrary.

@jeremystretch commented on GitHub (Jan 5, 2022): > It should only render in the api response if explicitely requested by the client. This is not how a REST API is intended to function, and should be considered an anti-pattern to be avoided. The only place we currently allow toggling a specific field is device/VM config contexts (and I'd prefer to eliminate that). > Like a regular custom field the format can indeed change over time This is not typical for a custom field. Once you've defined, for example, an integer custom field, it is unlikely that you'll later change it to e.g. a string type. But if you do, at least the new type is conveyed in the custom field's `type` field. Not so with a rendered template, which is completely arbitrary.

adam commented

2025-12-29 19:33:41 +01:00

@jeremystretch commented on GitHub (Jan 5, 2022):

Also consider this scenario: The owner of an API client (client A) introduces a template-based custom field for its client use. Then, the owner of a separate client (client B) discovers this field and begins to use it as well. After some time, the owner of client A determines that a change is necessary, and modifies the template to change the format of its output. This breaks client B.

The owner of client B then complains (or worse, reverses the change unilaterally, breaking client A). Now we have a disagreement with one side arguing that the other needs to update their client to accept the new format, and the other rebutting that the API should not have been changed in the first place. It is easy to imagine such a scenario arising very frequently with such an implementation. And the entire problem could have been avoided if both clients had merely invested some small effort to consume the data that is already available to them in a well-defined format.

@jeremystretch commented on GitHub (Jan 5, 2022): Also consider this scenario: The owner of an API client (client A) introduces a template-based custom field for its client use. Then, the owner of a separate client (client B) discovers this field and begins to use it as well. After some time, the owner of client A determines that a change is necessary, and modifies the template to change the format of its output. This breaks client B. The owner of client B then complains (or worse, reverses the change unilaterally, breaking client A). Now we have a disagreement with one side arguing that the other needs to update their client to accept the new format, and the other rebutting that the API should not have been changed in the first place. It is easy to imagine such a scenario arising very frequently with such an implementation. And the entire problem could have been avoided if both clients had merely invested some small effort to consume the data that is already available to them in a well-defined format.

adam commented

2025-12-29 19:33:41 +01:00

@ryanmerolle commented on GitHub (Jan 5, 2022):

I think your scenarios are fair, but not super common. Would not the same scenario be possible for any custom field that a client references and is changed on the fly by an admin. IE the name of the field, the data type, or just the value someone might be keying on in their scrip/app.

I have invested time on the logic on the client side. I may even invest in logic for NetBox scripts to auto update the interface descriptions if this feature was not to be taken up. It would not be that hard to do given I have the logic already defined on the client side. Frankly, this would allow for native interface description data stored in a core NetBox interface attribute. I recognize that others may not have my exact interface description use case, but I'm sure there are some other use cases where an existing NetBox attribute won't do. I also think people in their effort to test and iterate their automation tooling have this duplicated logic in many duplicate place. Solving this would be to move it to a single source, thus many people think NetBox, but maybe its another layer between NetBox and all their tooling.

Nautobot has something similar, and I'm not sure how utilized the feature is. What I think this comes down to, as with all other features is ROI. The ROI to implement and maintain long-term just may not be feasible at this time or at all. I just figured I bubble this feature up since I have heard some people ask about it recently.

@ryanmerolle commented on GitHub (Jan 5, 2022): I think your scenarios are fair, but not super common. Would not the same scenario be possible for any custom field that a client references and is changed on the fly by an admin. IE the name of the field, the data type, or just the value someone might be keying on in their scrip/app. I have invested time on the logic on the client side. I may even invest in logic for NetBox scripts to auto update the interface descriptions if this feature was not to be taken up. It would not be that hard to do given I have the logic already defined on the client side. Frankly, this would allow for native interface description data stored in a core NetBox interface attribute. I recognize that others may not have my exact interface description use case, but I'm sure there are some other use cases where an existing NetBox attribute won't do. I also think people in their effort to test and iterate their automation tooling have this duplicated logic in many duplicate place. Solving this would be to move it to a single source, thus many people think NetBox, but maybe its another layer between NetBox and all their tooling. Nautobot has something similar, and I'm not sure how utilized the feature is. What I think this comes down to, as with all other features is ROI. The ROI to implement and maintain long-term just may not be feasible at this time or at all. I just figured I bubble this feature up since I have heard some people ask about it recently.

adam commented

2025-12-29 19:33:41 +01:00

@cameronw1996 commented on GitHub (Jan 8, 2022):

1 vote for me. I could see a use case where we can show specific custom fields dependant on what is entered into other fields for example device types. I.e if the device is a wireless access points then custom fields SSID and password would show.

@cameronw1996 commented on GitHub (Jan 8, 2022): + 1 vote for me. I could see a use case where we can show specific custom fields dependant on what is entered into other fields for example device types. I.e if the device is a wireless access points then custom fields SSID and password would show.

adam commented

2025-12-29 19:33:42 +01:00

@jeremystretch commented on GitHub (Jan 9, 2022):

I could see a use case where we can show specific custom fields dependant on what is entered into other fields for example device types.

@cameronw1996 I don't believe that's what's being proposed here. This FR pertains to generating a specific value within a single custom field. All custom fields assigned to a model will always be displayed, and that's not something we would want to change (for several reasons).

@jeremystretch commented on GitHub (Jan 9, 2022): > I could see a use case where we can show specific custom fields dependant on what is entered into other fields for example device types. @cameronw1996 I don't believe that's what's being proposed here. This FR pertains to generating a specific value within a single custom field. All custom fields assigned to a model will always be displayed, and that's not something we would want to change (for several reasons).

adam commented

2025-12-29 19:33:42 +01:00

@jeremystretch commented on GitHub (Jan 9, 2022):

Would not the same scenario be possible for any custom field that a client references and is changed on the fly by an admin. IE the name of the field, the data type, or just the value someone might be keying on in their scrip/app.

Yes, but these changes can be inferred from the custom field itself, allowing the client to adapt if necessary. Not so with an arbitrary template.

@jeremystretch commented on GitHub (Jan 9, 2022): > Would not the same scenario be possible for any custom field that a client references and is changed on the fly by an admin. IE the name of the field, the data type, or just the value someone might be keying on in their scrip/app. Yes, but these changes can be inferred from the custom field itself, allowing the client to adapt if necessary. Not so with an arbitrary template.

adam commented

2025-12-29 19:33:42 +01:00

@github-actions[bot] commented on GitHub (Mar 11, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Mar 11, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 19:33:42 +01:00

@ITJamie commented on GitHub (Apr 9, 2022):

I would also like to see this feature. similar to the custom-link setup.

A few usecases.

Getting data from other models eg prefixes and displaying it on an ip page
Calculating information about an object and displaying it (eg subnet mask or gateways for an ip)

It could also be used as a workaround to displaying relationships to foreignkey plugin models.
eg for prefixes on the access-lists demo plugin you could have a custom field that looks for related access list rules and return an array of id's

@ITJamie commented on GitHub (Apr 9, 2022): I would also like to see this feature. similar to the custom-link setup. A few usecases. - Getting data from other models eg prefixes and displaying it on an ip page - Calculating information about an object and displaying it (eg subnet mask or gateways for an ip) It could also be used as a workaround to displaying relationships to foreignkey plugin models. eg for prefixes on the access-lists demo plugin you could have a custom field that looks for related access list rules and return an array of id's

adam commented

2025-12-29 19:33:42 +01:00

@ryanmerolle commented on GitHub (Apr 9, 2022):

It could also be used as a workaround to displaying relationships to foreignkey plugin models.
eg for prefixes on the access-lists demo plugin you could have a custom field that looks for related access list rules and return an array of id's.

Custom foreign keys sound like #7006 which was just released in 3.2.0

@ryanmerolle commented on GitHub (Apr 9, 2022): > It could also be used as a workaround to displaying relationships to foreignkey plugin models. eg for prefixes on the access-lists demo plugin you could have a custom field that looks for related access list rules and return an array of id's. Custom foreign keys sound like #7006 which was just released in 3.2.0

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#5870