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

Enable the association of inventory items with device components #5666

New Issue
Closed
opened 2025-12-29 19:30:53 +01:00 by adam · 16 comments
adam commented 2025-12-29 19:30:53 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Nov 16, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.0.10

Feature type

New functionality

Proposed functionality

Enable users to associate an inventory item with a particular device component installed within the same parent device. This would be done by adding a GenericForeignKey relationship to the InventoryItem model.

Use case

This would allow users to better model the installation of items such as transceivers or antennas, conveying a relationship to a specific component for each.

Database changes

Add a GenericForeignKey field to the InventoryItem and InventoryItemTemplate models, allowing the associating with device components or component templates respectively.

External dependencies

No response

Originally created by @jeremystretch on GitHub (Nov 16, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.0.10 ### Feature type New functionality ### Proposed functionality Enable users to associate an inventory item with a particular device component installed within the same parent device. This would be done by adding a GenericForeignKey relationship to the InventoryItem model. ### Use case This would allow users to better model the installation of items such as transceivers or antennas, conveying a relationship to a specific component for each. ### Database changes Add a GenericForeignKey field to the InventoryItem and InventoryItemTemplate models, allowing the associating with device components or component templates respectively. ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:30:53 +01:00
adam closed this issue 2025-12-29 19:30:53 +01:00
adam commented 2025-12-29 19:30:53 +01:00
Author
Owner
Copy Link

@hiddenman commented on GitHub (Nov 17, 2021):

That would be really useful and closes most of the cases, thank you.

@hiddenman commented on GitHub (Nov 17, 2021): That would be really useful and closes most of the cases, thank you.
adam commented 2025-12-29 19:30:54 +01:00
Author
Owner
Copy Link

@hiddenman commented on GitHub (Nov 18, 2021):

@jeremystretch Btw, what does "a particular device component installed within the same parent device." mean?
What are components in this case? Any class from device_components.py including Interfaces/Ports?

@hiddenman commented on GitHub (Nov 18, 2021): @jeremystretch Btw, what does "a particular device component installed within the same parent device." mean? What are components in this case? Any class from device_components.py including Interfaces/Ports?
adam commented 2025-12-29 19:30:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 21, 2021):

@hiddenman yes, any of the device component models (except device/module bays).

Taking another look at this, I'm not sure what to do about the current nested hierarchy: The recursive parent field on the InventoryItem module allows for self-nesting using MPTT. We could replace this with a GenericForeignKey pointing to any supported component model, but that would 1) introduce a breaking change and 2) remove the ability to efficiently render a hierarchy of inventory items (similar to what you would see from e.g. show chassis hardware on JunOS).

I'll give this some more thought. Interested to see what others think.

@jeremystretch commented on GitHub (Dec 21, 2021): @hiddenman yes, any of the device component models (except device/module bays). Taking another look at this, I'm not sure what to do about the current nested hierarchy: The recursive `parent` field on the InventoryItem module allows for self-nesting using MPTT. We could replace this with a GenericForeignKey pointing to any supported component model, but that would 1) introduce a breaking change and 2) remove the ability to efficiently render a hierarchy of inventory items (similar to what you would see from e.g. `show chassis hardware` on JunOS). I'll give this some more thought. Interested to see what others think.
adam commented 2025-12-29 19:30:55 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 21, 2021):

Why do we want to mess with the parent field? Could we not use a different field to denote what component we use?

@DanSheps commented on GitHub (Dec 21, 2021): Why do we want to mess with the parent field? Could we not use a different field to denote what component we use?
adam commented 2025-12-29 19:30:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 21, 2021):

We could, but does that make sense? Can an inventory item be a child of both a device component and another inventory item? And if so, would users want to model it as such?

@jeremystretch commented on GitHub (Dec 21, 2021): We could, but does that make sense? Can an inventory item be a child of both a device component and another inventory item? And if so, would users _want_ to model it as such?
adam commented 2025-12-29 19:30:55 +01:00
Author
Owner
Copy Link

@hiddenman commented on GitHub (Dec 24, 2021):

Taking another look at this, I'm not sure what to do about the current nested hierarchy: The recursive parent field on the InventoryItem module allows for self-nesting using MPTT. We could replace this with a GenericForeignKey pointing to any supported component model, but that would 1) introduce a breaking change and 2) remove the ability to efficiently render a hierarchy of inventory items (similar to what you would see from e.g. show chassis hardware on JunOS).

@jeremystretch Actually, i've never used Parent/Child for InventoryItem just because didn't understand the logic behind them.

In our case we just can't easily store information about our SFP-modules and their ports, splitter cables and their ports and so on.
Nowadays we have to add lots of stupid custom fields to cover common cases.

@hiddenman commented on GitHub (Dec 24, 2021): > Taking another look at this, I'm not sure what to do about the current nested hierarchy: The recursive `parent` field on the InventoryItem module allows for self-nesting using MPTT. We could replace this with a GenericForeignKey pointing to any supported component model, but that would 1) introduce a breaking change and 2) remove the ability to efficiently render a hierarchy of inventory items (similar to what you would see from e.g. `show chassis hardware` on JunOS). @jeremystretch Actually, i've never used Parent/Child for InventoryItem just because didn't understand the logic behind them. In our case we just can't easily store information about our SFP-modules and their ports, splitter cables and their ports and so on. Nowadays we have to add lots of stupid custom fields to cover common cases.
adam commented 2025-12-29 19:30:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 27, 2021):

Actually, i've never used Parent/Child for InventoryItem just because didn't understand the logic behind them.

Here's an example hardware inventory from a Juniper switch:

Item             Version  Part number  Serial number     Description
Chassis                                TB3716XXXXXX      Virtual Chassis
Routing Engine 0          BUILTIN      BUILTIN           QFX Routing Engine
Routing Engine 1          BUILTIN      BUILTIN           QFX Routing Engine
FPC 0            REV 31   650-049941   TB3717XXXXXX      QFX5100-24Q-2P
  CPU                     BUILTIN      BUILTIN           FPC CPU
  PIC 0                   BUILTIN      BUILTIN           24x 40G-QSFP
    Xcvr 0                NON-JNPR     34544000XXXX      QSFP+-40G-CU3M
    Xcvr 1                NON-JNPR     33994000XXXX      UNKNOWN
    Xcvr 2                NON-JNPR     33994000XXXX      UNKNOWN
    Xcvr 3                NON-JNPR     33994000XXXX      UNKNOWN
    Xcvr 4                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 5                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 6                NON-JNPR     34668000XXXX      UNKNOWN
    Xcvr 7                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 8                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 9                NON-JNPR     34544000XXXX      UNKNOWN
    Xcvr 10               NON-JNPR     34668000XXXX      UNKNOWN
    Xcvr 18               NON-JNPR     A75P02XXXX        UNKNOWN
    Xcvr 19               NON-JNPR     A75P02XXXX        UNKNOWN
    Xcvr 22               NON-JNPR     1615201XXXX       QSFP+-40G-CU1M
    Xcvr 23               NON-JNPR     1615201XXXX       QSFP+-40G-CU1M
  Power Supply 0 REV 04   740-044332   1GA1650XXXX       JPSU-650W-AC-AFI
  Power Supply 1 REV 04   740-044332   1GA1650XXXX       JPSU-650W-AC-AFI
  Fan Tray 0                                             QFX5100 Fan Tray 0, Back to Front Airflow - AFI
  Fan Tray 1                                             QFX5100 Fan Tray 1, Back to Front Airflow - AFI
  Fan Tray 2                                             QFX5100 Fan Tray 2, Back to Front Airflow - AFI
  Fan Tray 3                                             QFX5100 Fan Tray 3, Back to Front Airflow - AFI
  Fan Tray 4                                             QFX5100 Fan Tray 4, Back to Front Airflow - AFI

You can see that the CPU, PIC, power supplies, and fans are all children of the FPC item, and the transceivers are all children of the PIC. The parent field in NetBox is used to track these associations.

@jeremystretch commented on GitHub (Dec 27, 2021): > Actually, i've never used Parent/Child for InventoryItem just because didn't understand the logic behind them. Here's an example hardware inventory from a Juniper switch: ``` Item Version Part number Serial number Description Chassis TB3716XXXXXX Virtual Chassis Routing Engine 0 BUILTIN BUILTIN QFX Routing Engine Routing Engine 1 BUILTIN BUILTIN QFX Routing Engine FPC 0 REV 31 650-049941 TB3717XXXXXX QFX5100-24Q-2P CPU BUILTIN BUILTIN FPC CPU PIC 0 BUILTIN BUILTIN 24x 40G-QSFP Xcvr 0 NON-JNPR 34544000XXXX QSFP+-40G-CU3M Xcvr 1 NON-JNPR 33994000XXXX UNKNOWN Xcvr 2 NON-JNPR 33994000XXXX UNKNOWN Xcvr 3 NON-JNPR 33994000XXXX UNKNOWN Xcvr 4 NON-JNPR 34544000XXXX UNKNOWN Xcvr 5 NON-JNPR 34544000XXXX UNKNOWN Xcvr 6 NON-JNPR 34668000XXXX UNKNOWN Xcvr 7 NON-JNPR 34544000XXXX UNKNOWN Xcvr 8 NON-JNPR 34544000XXXX UNKNOWN Xcvr 9 NON-JNPR 34544000XXXX UNKNOWN Xcvr 10 NON-JNPR 34668000XXXX UNKNOWN Xcvr 18 NON-JNPR A75P02XXXX UNKNOWN Xcvr 19 NON-JNPR A75P02XXXX UNKNOWN Xcvr 22 NON-JNPR 1615201XXXX QSFP+-40G-CU1M Xcvr 23 NON-JNPR 1615201XXXX QSFP+-40G-CU1M Power Supply 0 REV 04 740-044332 1GA1650XXXX JPSU-650W-AC-AFI Power Supply 1 REV 04 740-044332 1GA1650XXXX JPSU-650W-AC-AFI Fan Tray 0 QFX5100 Fan Tray 0, Back to Front Airflow - AFI Fan Tray 1 QFX5100 Fan Tray 1, Back to Front Airflow - AFI Fan Tray 2 QFX5100 Fan Tray 2, Back to Front Airflow - AFI Fan Tray 3 QFX5100 Fan Tray 3, Back to Front Airflow - AFI Fan Tray 4 QFX5100 Fan Tray 4, Back to Front Airflow - AFI ``` You can see that the CPU, PIC, power supplies, and fans are all children of the FPC item, and the transceivers are all children of the PIC. The `parent` field in NetBox is used to track these associations.
adam commented 2025-12-29 19:30:59 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Dec 30, 2021):

@jeremystretch:

Taking another look at this, I'm not sure what to do about the current nested hierarchy: The recursive parent field on the InventoryItem module allows for self-nesting using MPTT. We could replace this with a GenericForeignKey pointing to any supported component model, but that would 1) introduce a breaking change and 2) remove the ability to efficiently render a hierarchy of inventory items (similar to what you would see from e.g. show chassis hardware on JunOS).

I'll give this some more thought. Interested to see what others think.

I'm a bit late to the party here: but I observe that if you're allowing an inventory item to be associated to an existing device component using a generic FK, then you could also allow it to be associated to a (parent) inventory item using the same generic FK relation.

Values in the existing "parent" field can be auto-migrated. In fact, you could still call the association "parent" if you want.

Looking at the merged change, it has added component_type and component_id fields, in addition to retaining "parent". Therefore I'd suggest either:

  1. Remove the "parent" field. As part of migration, for any object which currently has "parent" set, copy the parent ID to component_id, and set the component_type to "Inventory Item". Or:
  2. Rename "component_type" and "component_id" to "parent_type" and "parent_id", together with the migration described in (1)

The nested inventory item hierarchy will now be modelled as a standard parent-child rather than a nested tree, but I don't really see any problem with that - the hierarchy is never going to be more than 2 or 3 levels deep in practice.

@candlerb commented on GitHub (Dec 30, 2021): @jeremystretch: > Taking another look at this, I'm not sure what to do about the current nested hierarchy: The recursive parent field on the InventoryItem module allows for self-nesting using MPTT. We could replace this with a GenericForeignKey pointing to any supported component model, but that would 1) introduce a breaking change and 2) remove the ability to efficiently render a hierarchy of inventory items (similar to what you would see from e.g. show chassis hardware on JunOS). > > I'll give this some more thought. Interested to see what others think. I'm a bit late to the party here: but I observe that if you're allowing an inventory item to be associated to an existing device component using a generic FK, then you could also allow it to be associated to a (parent) inventory item using the same generic FK relation. Values in the existing "parent" field can be auto-migrated. In fact, you could still call the association "parent" if you want. Looking at the merged change, it has added `component_type` and `component_id` fields, in addition to retaining "parent". Therefore I'd suggest either: 1. Remove the "parent" field. As part of migration, for any object which currently has "parent" set, copy the parent ID to component_id, and set the component_type to "Inventory Item". Or: 2. Rename "component_type" and "component_id" to "parent_type" and "parent_id", together with the migration described in (1) The nested inventory item hierarchy will now be modelled as a standard parent-child rather than a nested tree, but I don't really see any problem with that - the hierarchy is never going to be more than 2 or 3 levels deep in practice.
adam commented 2025-12-29 19:31:00 +01:00
Author
Owner
Copy Link

@BrunoBlanes commented on GitHub (Jan 19, 2022):

Hi there, quick question, would this feature allow me to add an inventory item to a physical interface? We have a very common use case of SFP+ interfaces and transceivers. We don't want them as devices and wouldn't make sense to have them loose on the device. We need it to be part of an interface.

@BrunoBlanes commented on GitHub (Jan 19, 2022): Hi there, quick question, would this feature allow me to add an inventory item to a physical interface? We have a very common use case of SFP+ interfaces and transceivers. We don't want them as devices and wouldn't make sense to have them loose on the device. We need it to be part of an interface.
adam commented 2025-12-29 19:31:01 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 19, 2022):

Yes, a "device component" means an interface, front port, rear port, power port etc.

@candlerb commented on GitHub (Jan 19, 2022): Yes, a "device component" means an interface, front port, rear port, power port etc.
adam commented 2025-12-29 19:31:01 +01:00
Author
Owner
Copy Link

@BrunoBlanes commented on GitHub (Jan 19, 2022):

Awesome, to get an early preview of this the only way is to compile the feature branch?

@BrunoBlanes commented on GitHub (Jan 19, 2022): Awesome, to get an early preview of this the only way is to compile the feature branch?
adam commented 2025-12-29 19:31:01 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 19, 2022):

I don't think you should need to "compile" anything; I believe just git checkout origin/feature and then install as usual (./upgrade.sh) but haven't tested it myself.

Whatever you do, don't do this on your production system or database. Make a copy of your database into a separate machine or VM, and do it there. You will have to throw it away before migrating to the final 3.2 release.

@candlerb commented on GitHub (Jan 19, 2022): I don't think you should need to "compile" anything; I believe just `git checkout origin/feature` and then install as usual (`./upgrade.sh`) but haven't tested it myself. Whatever you do, *don't* do this on your production system or database. Make a copy of your database into a separate machine or VM, and do it there. You will have to throw it away before migrating to the final 3.2 release.
adam commented 2025-12-29 19:31:01 +01:00
Author
Owner
Copy Link

@BrunoBlanes commented on GitHub (Jan 19, 2022):

We're starting fresh with NetBox, so there's no loss of data, thanks!

@BrunoBlanes commented on GitHub (Jan 19, 2022): We're starting fresh with NetBox, so there's no loss of data, thanks!
adam commented 2025-12-29 19:31:02 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 19, 2022):

OK, but remember that any data you put into this instance will also be lost. There is no upgrade path from feature branch or any beta release to a production release.

@candlerb commented on GitHub (Jan 19, 2022): OK, but remember that any data you *put* into this instance will also be lost. There is no upgrade path from `feature` branch or any beta release to a production release.
adam commented 2025-12-29 19:31:02 +01:00
Author
Owner
Copy Link

@BrunoBlanes commented on GitHub (Jan 19, 2022):

Oh, okay. Thanks for the heads-up.

@BrunoBlanes commented on GitHub (Jan 19, 2022): Oh, okay. Thanks for the heads-up.
adam commented 2025-12-29 19:31:02 +01:00
Author
Owner
Copy Link

@drmsoffall commented on GitHub (Apr 8, 2022):

I sincerely apologize if this is "just me" but I really struggled to understand how to use this feature. The docs don't clarify the following:

  • Associating an inventory item with a component requires navigating to the component table and using the '+' icon to add a new inventory item
  • There is no way to associate an existing inventory item with a component

It's possible I'm not fully grasping the interface yet. In any case, maybe adding some clarifications to the docs would help? Thanks!

@drmsoffall commented on GitHub (Apr 8, 2022): I sincerely apologize if this is "just me" but I really struggled to understand how to use this feature. The docs don't clarify the following: - Associating an inventory item with a component requires navigating to the component table and using the '+' icon to add a new inventory item - There is no way to associate an existing inventory item with a component It's possible I'm not fully grasping the interface yet. In any case, maybe adding some clarifications to the docs would help? Thanks!
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: accepted 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#5666
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?