Allow setting Virtual Chassis fields from Device create/update forms #6504

New Issue

adam · 2025-12-29T19:41:38+01:00

adam commented

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

Originally created by @sleepinggenius2 on GitHub (May 20, 2022).

Originally assigned to: @cpund on GitHub.

NetBox version

v3.2.3

Feature type

New functionality

Proposed functionality

It would be really nice to be able set the vc* fields directly on the Device forms. As they are already part of the Device model, this should just require creating the 3 fields (Virtual Chassis, Position, Priority) in the corresponding forms. With the way that things are currently modeled, I'm not sure why this isn't already an option, so maybe there's some other technical limitation that I'm missing.

Optionally, using any Site, Location, or Rack fields that are set to filter the list of Virtual Chassis to choose from, kind of like how the Add Member form works, might be nice.

If possible, adding a field to allow setting the device as master would also be helpful. I understand if this might cause validation issues by the device not being a member of the Virtual Chassis first.

Use case

When adding a switch to a stack, today you have to add the Device, then go to the Virtual Chassis, add a new member, then search for the switch before it can be added. This would greatly simplify that process and I think could also help to resolve #8648.

You could put something like {member} in the Module Bay Position field of a Device Type or in an Interface Name, which would then be replaced by the Position within the selected Virtual Chassis, just like is done for Modules today. That way, the Module Bay Position could become something like 1/1 instead of just 1 and you could replace the Module templates with something like Gi{module}/1 instead of Gi1/{module}/1. Or, if you want to keep it as 1, then your template could be Gi{member}/{module}/1. I'm assuming that would get around the issue of components being created before Virtual Chassis assignment.

Database changes

None

External dependencies

None

Originally created by @sleepinggenius2 on GitHub (May 20, 2022). Originally assigned to: @cpund on GitHub. ### NetBox version v3.2.3 ### Feature type New functionality ### Proposed functionality It would be really nice to be able set the *vc\** fields directly on the Device forms. As they are already part of the Device model, this should just require creating the 3 fields (Virtual Chassis, Position, Priority) in the corresponding forms. With the way that things are currently modeled, I'm not sure why this isn't already an option, so maybe there's some other technical limitation that I'm missing. Optionally, using any Site, Location, or Rack fields that are set to filter the list of Virtual Chassis to choose from, kind of like how the *Add Member* form works, might be nice. If possible, adding a field to allow setting the device as master would also be helpful. I understand if this might cause validation issues by the device not being a member of the Virtual Chassis first. ### Use case When adding a switch to a stack, today you have to add the Device, then go to the Virtual Chassis, add a new member, then search for the switch before it can be added. This would greatly simplify that process and I think could also help to resolve #8648. You could put something like `{member}` in the Module Bay Position field of a Device Type or in an Interface Name, which would then be replaced by the Position within the selected Virtual Chassis, just like is done for Modules today. That way, the Module Bay Position could become something like `1/1` instead of just `1` and you could replace the Module templates with something like `Gi{module}/1` instead of `Gi1/{module}/1`. Or, if you want to keep it as `1`, then your template could be `Gi{member}/{module}/1`. I'm assuming that would get around the issue of components being created before Virtual Chassis assignment. ### Database changes None ### External dependencies None

adam added the status: accepted type: feature labels 2025-12-29 19:41:39 +01:00

adam closed this issue

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

adam commented

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

@cpund commented on GitHub (Jun 10, 2022):

The API already permits this - all that would be needed, I think, would be to extend the GUI to include the selection of a virtual chassis and if selected, require the user to enter in a vc_position, and if desired, a vc_priority as well. I'd be willing to try and implement this on the GUI side if approved.

@cpund commented on GitHub (Jun 10, 2022): The API already permits this - all that would be needed, I think, would be to extend the GUI to include the selection of a virtual chassis and if selected, require the user to enter in a vc_position, and if desired, a vc_priority as well. I'd be willing to try and implement this on the GUI side if approved.

adam commented

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

@cpund commented on GitHub (Jun 13, 2022):

After playing around with things, just to get a better understanding of Django and the Netbox codebase, I believe I've got a minimum tweak to add this functionality.

Unfortunately, from my understanding of how the disabled-indicator functions (based on whether a field is populated, and not the value of the field), as well as in the interest of avoid vendor or device specific constraints (some Cisco have a max of 8 members, others 9, and that's not counting other manufacturers), I wasn't able to make a fancy drop-down for vc_position. The user will be required to cross-compare with a switch stack to know which members are open.

Regardless, the back-end API should handle invalid vc_position and vc_priority numbers, and spits back an error message to the user when it fails, giving them the option to change it.

@cpund commented on GitHub (Jun 13, 2022): After playing around with things, just to get a better understanding of Django and the Netbox codebase, I believe I've got a minimum tweak to add this functionality. Unfortunately, from my understanding of how the disabled-indicator functions (based on whether a field is populated, and not the value of the field), as well as in the interest of avoid vendor or device specific constraints (some Cisco have a max of 8 members, others 9, and that's not counting other manufacturers), I wasn't able to make a fancy drop-down for vc_position. The user will be required to cross-compare with a switch stack to know which members are open. Regardless, the back-end API should handle invalid vc_position and vc_priority numbers, and spits back an error message to the user when it fails, giving them the option to change it.

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