Add support for populating Custom Fields on Component Templates #6415

New Issue

adam · 2025-12-29T19:40:26+01:00

adam commented

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

Originally created by @sleepinggenius2 on GitHub (Apr 27, 2022).

NetBox version

v3.2.1

Feature type

New functionality

Proposed functionality

When component templates are instantiated today for Device/Model types, the fields within the component templates are populated within the concrete component objects associated with the parent object that has been created. This proposal is to extend support within the component templates to allow for pre-populating custom fields as well. My thought is that any custom fields on the DCIM > interface model, for example, should be available when creating an interface template. Same with all of the other component template options. I believe this could be implemented by extending the template data models to include a column for custom fields, just like the concrete models have. When the templates are instantiated, the value of the custom field column could essentially be copied over to the concrete object. The Required attribute would need to be ignored for template custom fields, but I'm not sure how that might affect how templates are being instantiated today.

Use case

We have some custom fields defined on Device/Model components that should always be the same for a given type. Today, a user needs to go through after a Device/Model is created to update the custom fields on the components with their appropriate values. Unfortunately, a number of these are unique values and thus cannot be updated in bulk and the user has to remember this step as well as what the values are supposed to be. We have been able to semi-automate some of this through the use of custom scripts, but have found it tedious and requires a server-side change when new types are added, instead of just being able to make the changes within the UI. Having this feature would be really helpful from a UX perspective.

Database changes

Add a column for custom fields to the component template models.

External dependencies

None

Originally created by @sleepinggenius2 on GitHub (Apr 27, 2022). ### NetBox version v3.2.1 ### Feature type New functionality ### Proposed functionality When component templates are instantiated today for Device/Model types, the fields within the component templates are populated within the concrete component objects associated with the parent object that has been created. This proposal is to extend support within the component templates to allow for pre-populating custom fields as well. My thought is that any custom fields on the *DCIM > interface* model, for example, should be available when creating an interface template. Same with all of the other component template options. I believe this could be implemented by extending the template data models to include a column for custom fields, just like the concrete models have. When the templates are instantiated, the value of the custom field column could essentially be copied over to the concrete object. The *Required* attribute would need to be ignored for template custom fields, but I'm not sure how that might affect how templates are being instantiated today. ### Use case We have some custom fields defined on Device/Model components that should always be the same for a given type. Today, a user needs to go through after a Device/Model is created to update the custom fields on the components with their appropriate values. Unfortunately, a number of these are unique values and thus cannot be updated in bulk and the user has to remember this step as well as what the values are supposed to be. We have been able to semi-automate some of this through the use of custom scripts, but have found it tedious and requires a server-side change when new types are added, instead of just being able to make the changes within the UI. Having this feature would be really helpful from a UX perspective. ### Database changes Add a column for custom fields to the component template models. ### External dependencies None

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

adam closed this issue

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

adam commented

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

@github-actions[bot] commented on GitHub (Jun 27, 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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 27, 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. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

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

@github-actions[bot] commented on GitHub (Jul 27, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jul 27, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

adam commented

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

@kkthxbye-code commented on GitHub (Oct 28, 2022):

I'm gonna accept this and look at it if I get time. If you @sleepinggenius2 or anyone else would like to own it, please let me know and I'll assign it to you.

I'm not sure how involved the implementation is going to be, haven't really touched the custom field implementation at all.

@kkthxbye-code commented on GitHub (Oct 28, 2022): I'm gonna accept this and look at it if I get time. If you @sleepinggenius2 or anyone else would like to own it, please let me know and I'll assign it to you. I'm not sure how involved the implementation is going to be, haven't really touched the custom field implementation at all.

adam commented

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

@dpotter-intoto commented on GitHub (Oct 31, 2022):

As the author of related Issue #10754 I just want to voice support for this feature request, which is so powerful & enabling... it provides a direct tie between device types and their instantiation as objects.

In our facility, this will allow us to specify custom interface configurations based on the device type. It is particularly important for our use case that JSON field types are supported.

We intend to use this feature to include interface-specific network requirements within the device type interface templates, when those requirements are associated with the device-type. Example:

{ 
  "device_net_reqs": [ 
   "pim ipv4 sparse-mode",
   "ptp enable",
   "ptp sync-message interval -3",
   "ptp announce interval 0",
   "ptp delay-req interval -3",
   "ptp role master",
   "mtu 9214",
   "speed forced 10000full",
   "error-correction encoding reed-solomon"
   ]
}

@dpotter-intoto commented on GitHub (Oct 31, 2022): As the author of related Issue #10754 I just want to voice support for this feature request, which is so powerful & enabling... it provides a direct tie between device types and their instantiation as objects. In our facility, this will allow us to specify custom interface configurations based on the device type. It is particularly important for our use case that JSON field types are supported. We intend to use this feature to include interface-specific network requirements within the device type interface templates, when those requirements are associated with the device-type. Example: ``` { "device_net_reqs": [ "pim ipv4 sparse-mode", "ptp enable", "ptp sync-message interval -3", "ptp announce interval 0", "ptp delay-req interval -3", "ptp role master", "mtu 9214", "speed forced 10000full", "error-correction encoding reed-solomon" ] } ```

adam commented

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

@ghost commented on GitHub (Dec 8, 2022):

Another vote for this feature.
Our use case:

Proposed functionality
Currently, when you create a custom field it will only appear after a device has already been created. You are unable to add the custom field to the device type or module type.

Please add the ability for custom fields to also show up on device type and module type's.

Steps to reproduce.
Create a custom field called 'btu' using model DCIM > power port.
When you edit a power port on a device or module you see the custom field.
When you create a device type or module type and add a power port to them, the custom field does not appear.

Use case
In the above example, if you want to model the BTU thermal load of a power supply it will always be the same BTU load assuming the power supply is the same inside a module or a device.
Currently, to input the BTU value you would have to get all the way to the end of the device creation process and then edit the device or module and add the BTU value to the power port.

If the custom field appeared on the device type or module type power port, then you could input the value there once, and that value would carry over to each device or module that you create. (Similar to how maximum draw and allocated draw work now)

@ghost commented on GitHub (Dec 8, 2022): Another vote for this feature. Our use case: Proposed functionality Currently, when you create a custom field it will only appear after a device has already been created. You are unable to add the custom field to the device type or module type. Please add the ability for custom fields to also show up on device type and module type's. Steps to reproduce. Create a custom field called 'btu' using model DCIM > power port. When you edit a power port on a device or module you see the custom field. When you create a device type or module type and add a power port to them, the custom field does not appear. Use case In the above example, if you want to model the BTU thermal load of a power supply it will always be the same BTU load assuming the power supply is the same inside a module or a device. Currently, to input the BTU value you would have to get all the way to the end of the device creation process and then edit the device or module and add the BTU value to the power port. If the custom field appeared on the device type or module type power port, then you could input the value there once, and that value would carry over to each device or module that you create. (Similar to how maximum draw and allocated draw work now)

adam commented

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

@github-actions[bot] commented on GitHub (Feb 7, 2023):

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Feb 7, 2023): 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. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

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

@ghost commented on GitHub (Feb 8, 2023):

Another vote for this feature. We find it a pain to manually add custom field values on devices that should really be held on the device type level.

@ghost commented on GitHub (Feb 8, 2023): Another vote for this feature. We find it a pain to manually add custom field values on devices that should really be held on the device type level.

adam commented

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

@jeremystretch commented on GitHub (May 2, 2023):

Closing this as stale

@jeremystretch commented on GitHub (May 2, 2023): Closing this as stale

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#6415