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

change 'module bay' sorting to be alphabetical when installing module #11885

New Issue
Open
opened 2025-12-29 21:51:13 +01:00 by adam · 2 comments
adam commented 2025-12-29 21:51:13 +01:00
Owner
Copy Link

Originally created by @rconkor on GitHub (Dec 2, 2025).

NetBox version

v4.4.7

Feature type

Change to existing functionality

Proposed functionality

Currently when installing a module, the sorting in the 'module bay' dropdown appears to be by module id.
Can we get this changed to be alphabetical?

Use case

When installing a module, let's suppose you created 3 modules called "fan1", "fan2", "fan3". Then you create 2 modules called "psu1", and "psu2".

Now let's say you did an oopsie and actually need 4 fan modules. So you go back and add 1 more fan module "fan4".

Now when you go to install modules, the drop down selector for "module bay" has "fan4" at the bottom of the list. Rather than having fan1, fan2, fan3, fan4, psu1, psu2 ... it actually is listed as fan1, fan2, fan3, psu1, psu2, fan4.

For devices with lots of modules, it can be confusing for users.

Image

I'll add, that this seems to only be an issue if you manually create modules on a device after the device has been created from a device type.
It seems during the device creation process, modules are created in alphabetical order, so they would naturally be alphabetical in the dropdown. But if you create modules after the fact, the alphabetical sorting is disrupted.

So now you end up with instances where maybe on some devices it IS alphabetical (by nature of device id's having been created that way), and other devices where it ISN'T, causing even further confusion.

Database changes

none

External dependencies

none

Originally created by @rconkor on GitHub (Dec 2, 2025). ### NetBox version v4.4.7 ### Feature type Change to existing functionality ### Proposed functionality Currently when installing a module, the sorting in the 'module bay' dropdown appears to be by module id. Can we get this changed to be alphabetical? ### Use case When installing a module, let's suppose you created 3 modules called "fan1", "fan2", "fan3". Then you create 2 modules called "psu1", and "psu2". Now let's say you did an oopsie and actually need 4 fan modules. So you go back and add 1 more fan module "fan4". Now when you go to install modules, the drop down selector for "module bay" has "fan4" at the bottom of the list. Rather than having fan1, fan2, fan3, fan4, psu1, psu2 ... it actually is listed as fan1, fan2, fan3, psu1, psu2, fan4. For devices with lots of modules, it can be confusing for users. <img width="1167" height="578" alt="Image" src="https://github.com/user-attachments/assets/f77b3bc6-ac72-4fd0-898e-e9f6c0f7cb2f" /> I'll add, that this seems to only be an issue if you manually create modules on a device after the device has been created from a device type. It seems during the device creation process, modules are created in alphabetical order, so they would naturally be alphabetical in the dropdown. But if you create modules after the fact, the alphabetical sorting is disrupted. So now you end up with instances where maybe on some devices it IS alphabetical (by nature of device id's having been created that way), and other devices where it ISN'T, causing even further confusion. ### Database changes none ### External dependencies none
adam added the type: bugstatus: needs ownernetboxseverity: low labels 2025-12-29 21:51:13 +01:00
adam commented 2025-12-29 21:51:14 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Dec 3, 2025):

Honestly, I would consider this to be a bug, because it used to sort alphabetically before nested modules were introduced. Just as a note for anyone trying to fix this, making the below change helps by allowing a rebuild to work properly, but is not fully sufficient to correct the issue, as a number of operations still seem to put the tree in an inconsistent state. One of the most frustrating is a bulk rename. There is also a related bug when adopting components while adding a module where module bays are bulk updated and thus end up in an inconsistent state due to their save() method not being called.

 class ModuleBay(ModularComponentModel, TrackingModelMixin, MPTTModel):
     ...
     class MPTTMeta:
-        order_insertion_by = ('module',)
+        order_insertion_by = ('module', 'name')

Whatever can be done to cut down on the number of manual MPTT rebuilds would be fantastic.

@sleepinggenius2 commented on GitHub (Dec 3, 2025): Honestly, I would consider this to be a bug, because it used to sort alphabetically before nested modules were introduced. Just as a note for anyone trying to fix this, making the below change helps by allowing a rebuild to work properly, but is not fully sufficient to correct the issue, as a number of operations still seem to put the tree in an inconsistent state. One of the most frustrating is a bulk rename. There is also a related bug when adopting components while adding a module where module bays are bulk updated and thus end up in an inconsistent state due to their `save()` method not being called. ```diff class ModuleBay(ModularComponentModel, TrackingModelMixin, MPTTModel): ... class MPTTMeta: - order_insertion_by = ('module',) + order_insertion_by = ('module', 'name') ``` Whatever can be done to cut down on the number of manual MPTT rebuilds would be fantastic.
adam commented 2025-12-29 21:51:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 4, 2025):

Agree that this is more of a bug, as the presented ordering of available bays does not match reasonable expectations.

@jeremystretch commented on GitHub (Dec 4, 2025): Agree that this is more of a bug, as the presented ordering of available bays does not match reasonable expectations.
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 netbox severity: low status: needs owner type: bug
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#11885
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?