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

VLAN search does not return all results #10969

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

Originally created by @1024834 on GitHub (Apr 1, 2025).

Deployment Type

Self-hosted

NetBox Version

v4.2.5

Python Version

3.12

Steps to Reproduce

  1. Go to IPAM/VLANs
  2. Enter a VLAN ID in the quicksearch or filter search field, i.e. 33.

Expected Behavior

I should see every VLAN whose ID starts with 33.

Observed Behavior

I only see very few VLANs. Three out of >100 in my case. I have to enter the full VID to reliably find a VLAN.

When I enter 33 for example, I see 33, 3336 and 3344. But all the other VLANs from 3300 to 3399 are missing.

Originally created by @1024834 on GitHub (Apr 1, 2025). ### Deployment Type Self-hosted ### NetBox Version v4.2.5 ### Python Version 3.12 ### Steps to Reproduce 1. Go to IPAM/VLANs 2. Enter a VLAN ID in the quicksearch or filter search field, i.e. 33. ### Expected Behavior I should see every VLAN whose ID starts with 33. ### Observed Behavior I only see very few VLANs. Three out of >100 in my case. I have to enter the full VID to reliably find a VLAN. When I enter 33 for example, I see 33, 3336 and 3344. But all the other VLANs from 3300 to 3399 are missing.
adam added the type: bug label 2025-12-29 21:38:35 +01:00
adam closed this issue 2025-12-29 21:38:35 +01:00
adam commented 2025-12-29 21:38:36 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Apr 1, 2025):

@1024834 , thank you for opening an issue. However, this should actually be a feature request, since it seeks to change long standing behavior. In this case, this is the same behavior that's been in place since #358 was resolved (nearly 9 years ago).

To help us understand your request in detail, we ask you to recreate this issue as a feature request. We value your time and hate that this will create duplicate work for you, but GitHub currently offers no way to carry over the fields included in the bug report template to the feature request one. Thanks for understanding, and for your interest in helping improve NetBox.

@jnovinger commented on GitHub (Apr 1, 2025): @1024834 , thank you for opening an issue. However, this should actually be a feature request, since it seeks to change long standing behavior. In this case, this is the same behavior that's been in place since #358 was resolved (nearly 9 years ago). To help us understand your request in detail, we ask you to recreate this issue as a [feature request](https://github.com/netbox-community/netbox/issues/new?template=feature_request.yaml). We value your time and hate that this will create duplicate work for you, but GitHub currently offers no way to carry over the fields included in the bug report template to the feature request one. Thanks for understanding, and for your interest in helping improve NetBox.
adam commented 2025-12-29 21:38:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 1, 2025):

FYI the q filter intentionally matches only against the complete VID. Otherwise it would be extremely frustrating attempting to search for e.g. VLAN 1.

@jeremystretch commented on GitHub (Apr 1, 2025): FYI the `q` filter intentionally matches only against the complete VID. Otherwise it would be extremely frustrating attempting to search for e.g. VLAN 1.
adam commented 2025-12-29 21:38:36 +01:00
Author
Owner
Copy Link

@1024834 commented on GitHub (Apr 1, 2025):

FYI the q filter intentionally matches only against the complete VID. Otherwise it would be extremely frustrating attempting to search for e.g. VLAN 1.

It's like that for both, the quick search and the filter search. But wouldn't it make sense to receive the exact match as first result and 1* after that?

If I search for one in v4.2.5 I do get 1 as first result and some other VLANs, but I for one see no reason why the others from 1* should not appear.

@1024834 commented on GitHub (Apr 1, 2025): > FYI the `q` filter intentionally matches only against the complete VID. Otherwise it would be extremely frustrating attempting to search for e.g. VLAN 1. It's like that for both, the quick search and the filter search. But wouldn't it make sense to receive the exact match as first result and 1* after that? If I search for one in v4.2.5 I do get 1 as first result and some other VLANs, but I for one see no reason why the others from 1* should not appear.
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: 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#10969
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?