New model additional_device_data #5489

New Issue

adam · 2025-12-29T19:28:37+01:00

adam commented

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

Originally created by @cybarox on GitHub (Oct 7, 2021).

NetBox version

v3.0.6

Feature type

Data model extension

Proposed functionality

Introduction of a new model type to store additional information about a device. Unlike a custom field (which is applied to the whole object type), sometimes information is needed that is only required by a specific device type. The fields could be defined similar to interfaces in the device type template and would then be inherited by the device. This gives more flexibility to store and filter the data and is a bit less complex than storing data in config_context. In addition, the new model may offer the possibility to restrict permissions via the tenent.

Use case

Example of possible uses:

purpose
login banner
motd
company internal information about the device
edge cases

Database changes

Extending object views
Establish new model

External dependencies

no new dependencies

Originally created by @cybarox on GitHub (Oct 7, 2021). ### NetBox version v3.0.6 ### Feature type Data model extension ### Proposed functionality Introduction of a new model type to store additional information about a device. Unlike a custom field (which is applied to the whole object type), sometimes information is needed that is only required by a specific device type. The fields could be defined similar to interfaces in the device type template and would then be inherited by the device. This gives more flexibility to store and filter the data and is a bit less complex than storing data in config_context. In addition, the new model may offer the possibility to restrict permissions via the tenent. ### Use case Example of possible uses: - purpose - login banner - motd - company internal information about the device - edge cases ### Database changes - Extending object views - Establish new model ### External dependencies no new dependencies

adam added the type: feature label 2025-12-29 19:28:37 +01:00

adam closed this issue

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

adam commented

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

@jeremystretch commented on GitHub (Oct 7, 2021):

This sounds like the exact use case for config contexts. Why do config contexts not work for your use cases?

@jeremystretch commented on GitHub (Oct 7, 2021): This sounds like the exact use case for config contexts. Why do config contexts not work for your use cases?

adam commented

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

@cybarox commented on GitHub (Oct 7, 2021):

Config contexts limit us in some use cases. For example: there is no way to filter the data in the config context on the server side, so we need additional logic on the client side to read or update individual fields. Also, we need to rewrite the entire context if we want to update only a specific field. The change history for individual fields is another issue. Furthermore, there is no way to set the fields in config context as mandatory.

@cybarox commented on GitHub (Oct 7, 2021): Config contexts limit us in some use cases. For example: there is no way to filter the data in the config context on the server side, so we need additional logic on the client side to read or update individual fields. Also, we need to rewrite the entire context if we want to update only a specific field. The change history for individual fields is another issue. Furthermore, there is no way to set the fields in config context as mandatory.

adam commented

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

@jeremystretch commented on GitHub (Oct 7, 2021):

Maybe it would help to share an example of what you're trying to do.

@jeremystretch commented on GitHub (Oct 7, 2021): Maybe it would help to share an example of what you're trying to do.

adam commented

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

@cybarox commented on GitHub (Oct 7, 2021):

In our branch offices we have quite a lot of automation technology. These are primarily devices which, funnily enough, are called Netboxes. We use these devices to control our access rights for doors for employees, craftsmen and customers. The boxes are logically only one device which is controlled via IP. On this box are e.g. one or more card readers which are addressed via a modbus and the doors whose closer is controlled via a relay. Now we need several information per automation box for our middleware which controls the automation.

These are e.g.

use/purpose (Door, SlidingDoor, Locker, Barrier, Turnstile)
the destination (entry, exit, entry_exit, lock_unlock)
the rights group of the door (employee, customer, etc.)
the switching time of the relay (for the door opening)
the card readers and with which modbus address they are addressed
and other data which could be relevant for our backend team

Currently we have stored this data in the config context. But if we want to change the authorization of the door or the switching time, we have to rewrite the whole context. We also cannot search for specific permissions of a "door" aka "netbox".

Of course we can create custom fields for this. But we need this information only for the automation devices, not e.g. for our routers or switches.

I know NetBox was developed mainly for use in data centers and our use case is quite specific. But I also think there are more and more IoT devices in data centers, for example, sensors or controllers that serve a specific purpose. So we would welcome if NetBox provides a more granular way to store such data than it is possible with a config context, without having to provide all device objects with custom fields.

@cybarox commented on GitHub (Oct 7, 2021): In our branch offices we have quite a lot of automation technology. These are primarily devices which, funnily enough, are called Netboxes. We use these devices to control our access rights for doors for employees, craftsmen and customers. The boxes are logically only one device which is controlled via IP. On this box are e.g. one or more card readers which are addressed via a modbus and the doors whose closer is controlled via a relay. Now we need several information per automation box for our middleware which controls the automation. These are e.g. - use/purpose (Door, SlidingDoor, Locker, Barrier, Turnstile) - the destination (entry, exit, entry_exit, lock_unlock) - the rights group of the door (employee, customer, etc.) - the switching time of the relay (for the door opening) - the card readers and with which modbus address they are addressed - and other data which could be relevant for our backend team Currently we have stored this data in the config context. But if we want to change the authorization of the door or the switching time, we have to rewrite the whole context. We also cannot search for specific permissions of a "door" aka "netbox". Of course we can create custom fields for this. But we need this information only for the automation devices, not e.g. for our routers or switches. I know NetBox was developed mainly for use in data centers and our use case is quite specific. But I also think there are more and more IoT devices in data centers, for example, sensors or controllers that serve a specific purpose. So we would welcome if NetBox provides a more granular way to store such data than it is possible with a config context, without having to provide all device objects with custom fields.

adam commented

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

@PieterL75 commented on GitHub (Oct 8, 2021):

I had a similar problem.
We are storing IPAccounting data in our prefixes in a custom field as a json blob. That became pretty fast a huge amount of data, and slowed down Netbox considerably. Apparently the CF data was read from the database in cases we don't even needed the CF data.
My solution was to develop my own plugin. https://netbox.readthedocs.io/en/stable/plugins/development/
The plugin has its own database-model (https://netbox.readthedocs.io/en/stable/plugins/development/#database-models) and stores the data in the netbox mysql independant of the prefixes.
Now, the IPAccounting data is only read when the plugin kicks in and wants to display or update the data.

It is quite some work (as a beginner python programmer) to make this work, but it is worth the effort. I see a world of new options and features that can be added to Netbox that are very specific to our needs,

@PieterL75 commented on GitHub (Oct 8, 2021): I had a similar problem. We are storing IPAccounting data in our prefixes in a custom field as a json blob. That became pretty fast a huge amount of data, and slowed down Netbox considerably. Apparently the CF data was read from the database in cases we don't even needed the CF data. My solution was to develop my own plugin. https://netbox.readthedocs.io/en/stable/plugins/development/ The plugin has its own database-model (https://netbox.readthedocs.io/en/stable/plugins/development/#database-models) and stores the data in the netbox mysql independant of the prefixes. Now, the IPAccounting data is only read when the plugin kicks in and wants to display or update the data. It is quite some work (as a beginner python programmer) to make this work, but it is worth the effort. I see a world of new options and features that can be added to Netbox that are very specific to our needs,

adam commented

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

@cybarox commented on GitHub (Oct 8, 2021):

Developing a plugin would be my less preferred solution. I think that other NetBox users could also benefit from this additional data model. Maybe it also makes sense to extend this to more models than just devices.

Maybe another solution would be to define the scope of custom fields in more detail.

@cybarox commented on GitHub (Oct 8, 2021): Developing a plugin would be my less preferred solution. I think that other NetBox users could also benefit from this additional data model. Maybe it also makes sense to extend this to more models than just devices. Maybe another solution would be to define the scope of custom fields in more detail.

adam commented

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

@geor-g commented on GitHub (Oct 8, 2021):

I had a similar problem. We are storing IPAccounting data in our prefixes in a custom field as a json blob. That became pretty fast a huge amount of data, and slowed down Netbox considerably. Apparently the CF data was read from the database in cases we don't even needed the CF data. My solution was to develop my own plugin. https://netbox.readthedocs.io/en/stable/plugins/development/ The plugin has its own database-model (https://netbox.readthedocs.io/en/stable/plugins/development/#database-models) and stores the data in the netbox mysql independant of the prefixes. Now, the IPAccounting data is only read when the plugin kicks in and wants to display or update the data.

It is quite some work (as a beginner python programmer) to make this work, but it is worth the effort. I see a world of new options and features that can be added to Netbox that are very specific to our needs,

Any chance you could open-source your plugin?

@geor-g commented on GitHub (Oct 8, 2021): > I had a similar problem. We are storing IPAccounting data in our prefixes in a custom field as a json blob. That became pretty fast a huge amount of data, and slowed down Netbox considerably. Apparently the CF data was read from the database in cases we don't even needed the CF data. My solution was to develop my own plugin. https://netbox.readthedocs.io/en/stable/plugins/development/ The plugin has its own database-model (https://netbox.readthedocs.io/en/stable/plugins/development/#database-models) and stores the data in the netbox mysql independant of the prefixes. Now, the IPAccounting data is only read when the plugin kicks in and wants to display or update the data. > > It is quite some work (as a beginner python programmer) to make this work, but it is worth the effort. I see a world of new options and features that can be added to Netbox that are very specific to our needs, Any chance you could open-source your plugin?

adam commented

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

@jeremystretch commented on GitHub (Nov 11, 2021):

I think that other NetBox users could also benefit from this additional data model.

Most probably will not, which is why no one else has proposed this extension. However those that would are sure to be interested in such a plugin.

I'm going to close this out as it's pretty much a textbook use case for a plugin.

@jeremystretch commented on GitHub (Nov 11, 2021): > I think that other NetBox users could also benefit from this additional data model. Most probably will not, which is why no one else has proposed this extension. However those that would are sure to be interested in such a plugin. I'm going to close this out as it's pretty much a textbook use case for a plugin.

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