Unable to select VLANs on Device Interfaces where they are scoped by Cluster or Cluster Groups

[SteveRodrigue]

NetBox version

v4.2.4

Feature type

Change to existing functionality

Proposed functionality

It was suggested in issue #12764 to make it a formal feature request. This was also reported in issue #12690.

Assigning VLANs from a VLAN groups should work in all context in the Netbox UI. At the moment, when using the API or Netbox Scripts we can properly assign VLAN(s) to interface(s) based on specific VLAN Groups, but we can't from dcim/interfaces/.

Here's the workflow:

1. Create a device.
2. Assign the device to a virtualization cluster.
3. Create a VLAN group attached to the cluster.
4. Create VLAN(s) in the VLAN group.
5. Can't assign VLAN(s) from the VLAN group on the device interfaces manually in the GUI.
6. Can assign VLAN(s) using the API or a Netbox Scripts.

When we modify an interface and want to assign a VLAN based on a VLAN group, the "dropdown menu/list" of Untagged VLAN and Tagged VLANs is empty even if VLANs exist in the selected VLAN group.

Use case

We are allowed to create VLANs and VLAN groups, we should be able to assign any of those VLANs in the Netbox Web UI.

Creating VLAN groups is common in virtualization or when we group devices that shares VLANs: VTP domain (people still uses those), any Network Fabric or cluster of devices (or servers).

Database changes

I don't think any database change is required, the API already allows proper assignment of VLANs that are member of a group. This is actually how we work around the issue at the moment: we have created a form with a Netbox Scripts that allows us to add/remove VLANs to an interface manually. We override the UI limitation.

I feel the current limitation, is mainly due to the Web UI vlan lookup logic: when selecting a VLAN group, the list/dropdown is empty (the query may need to be fine tuned).

External dependencies

N/A

[19rwk82]

There was a pull request a few weeks ago which fixes this for us -> #19093
Unfortunately it was closed...

[awerner]

I also ran into this issue. Is there any way to get #19093 updated to reference this issue instead? It should be easy to get this implemented, as the pull request is already there, but was unfortunately closed.

[19rwk82]

This seems to have been implemented with another PR (#19485) which has already been merged... So waiting for 4.3.2 :)