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 hierarchical assignment of modules #10945

New Issue
Closed
opened 2025-12-29 21:38:10 +01:00 by adam · 2 comments
adam commented 2025-12-29 21:38:10 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Mar 25, 2025).

NetBox version

v4.2.6

Feature type

New functionality

Proposed functionality

Employ a recursive hierarchy (i.e. MPTT) to represent the nested relationships of modules to their parents. Currently, the assignment of child modules to their parents is recorded solely through intermediate relationships in the form of module bays:

flowchart TD
    Device --> Bay1(Module Bay 1)
    Device --> Bay2(Module Bay 2)

    Bay1 --> Module1[Module 1]
    Bay2 --> Module2[Module 2]

    Module1 --> Bay11(Module Bay 1)
    Module1 --> Bay12(Module Bay 2)
  
    Bay11 --> Module11[Module 1]
    Bay12 --> Module12[Module 2]

    Module11 --> Bay111(Module Bay 1)
    Module11 --> Bay112(Module Bay 2)
  
    Bay111 --> Module111[Module 1]
    Bay112 --> Module112[Module 2]

With a recursive hierarchy in place on the Module model, the tree can be compressed so that module bay assignment becomes incidental to the arrangement of modules:

flowchart TD
    Device -->|Module Bay 1| Module1[Module 1]
    Device -->|Module Bay 2| Module2[Module 2]
  
    Module1 -->|Module Bay 1| Module11[Module 1]
    Module1 -->|Module Bay 2| Module12[Module 2]
  
    Module11 -->|Module Bay 1| Module111[Module 1]
    Module11 -->|Module Bay 2| Module112[Module 2]

This can be achieved by adding a TreeForeignKey named parent to the Module model, similar to what exists on InventoryItem today. We'll need to keep the existing module_bay foreign key on Module in place to retain the parallel relationship to the specific bay in which a module is installed. (The parent and module_bay fields must set together or must both be null.)

Use case

Condensing the hierarchy in this manner will enable us to efficiently render the complete module tree for a given device. Additionally, this work will complement the functionality proposed in FR #19002 to model FRU items as modules.

Database changes

  • Add a parent TreeForeignKey on Module
  • Apply validation to ensure module bay assignment is consistent with the module hierarchy

External dependencies

N/A

Originally created by @jeremystretch on GitHub (Mar 25, 2025). ### NetBox version v4.2.6 ### Feature type New functionality ### Proposed functionality Employ a recursive hierarchy (i.e. MPTT) to represent the nested relationships of modules to their parents. Currently, the assignment of child modules to their parents is recorded solely through intermediate relationships in the form of module bays: ```mermaid flowchart TD Device --> Bay1(Module Bay 1) Device --> Bay2(Module Bay 2) Bay1 --> Module1[Module 1] Bay2 --> Module2[Module 2] Module1 --> Bay11(Module Bay 1) Module1 --> Bay12(Module Bay 2) Bay11 --> Module11[Module 1] Bay12 --> Module12[Module 2] Module11 --> Bay111(Module Bay 1) Module11 --> Bay112(Module Bay 2) Bay111 --> Module111[Module 1] Bay112 --> Module112[Module 2] ``` With a recursive hierarchy in place on the Module model, the tree can be compressed so that module bay assignment becomes incidental to the arrangement of modules: ```mermaid flowchart TD Device -->|Module Bay 1| Module1[Module 1] Device -->|Module Bay 2| Module2[Module 2] Module1 -->|Module Bay 1| Module11[Module 1] Module1 -->|Module Bay 2| Module12[Module 2] Module11 -->|Module Bay 1| Module111[Module 1] Module11 -->|Module Bay 2| Module112[Module 2] ``` This can be achieved by adding a TreeForeignKey named `parent` to the Module model, similar to what exists on InventoryItem today. We'll need to keep the existing `module_bay` foreign key on Module in place to retain the parallel relationship to the specific bay in which a module is installed. (The `parent` and `module_bay` fields must set together or must both be null.) ### Use case Condensing the hierarchy in this manner will enable us to efficiently render the complete module tree for a given device. Additionally, this work will complement the functionality proposed in FR #19002 to model FRU items as modules. ### Database changes - Add a `parent` TreeForeignKey on Module - Apply validation to ensure module bay assignment is consistent with the module hierarchy ### External dependencies N/A
adam added the type: feature label 2025-12-29 21:38:10 +01:00
adam closed this issue 2025-12-29 21:38:11 +01:00
adam commented 2025-12-29 21:38:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 25, 2025):

Digging into this further, it might not actually be needed, as we already use MPTT for the module bays. This wasn't a consideration when I was whiteboarding earlier. I think we can void enabling MPTT for modules, provided the module bay relationship is retained.

@jeremystretch commented on GitHub (Mar 25, 2025): Digging into this further, it might not actually be needed, as we already use MPTT for the module bays. This wasn't a consideration when I was whiteboarding earlier. I think we can void enabling MPTT for modules, provided the module bay relationship is retained.
adam commented 2025-12-29 21:38:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 27, 2025):

Further testing confirms that this should not be needed. The existing MPTT shared by module bays is sufficient.

@jeremystretch commented on GitHub (Mar 27, 2025): Further testing confirms that this should not be needed. The existing MPTT shared by module bays is sufficient.
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 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#10945
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?