starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 22:03:32 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Expand Edit Interface 802.1Q VLAN form search query #3120

New Issue
Closed
opened 2025-12-29 18:25:52 +01:00 by adam · 9 comments
adam commented 2025-12-29 18:25:52 +01:00
Owner
Copy Link

Originally created by @tyler-8 on GitHub (Jan 3, 2020).

Originally assigned to: @hSaria on GitHub.

Environment

  • Python version: 3.6.8
  • NetBox version: 2.6.7

Proposed Functionality

When using the GUI Select2 fields for adding untagged/tagged VLANs to a device/VM interface, expand the search parameters to also search by site and VLAN group. Currently it appears that only the VLAN Name and VID are used. The dropdown currently displays the sites in the dropdown list, but they're not part of the search parameters.

Use Case

When you have a cookiecutter design for a particular type of site, the VIDs and VLAN names are repeated identically, and added to their respective sites and VLAN groups, if applicable.

When you go to add those VLANs to an interface and search for vlan 5 for example, you may get dozens or hundreds of results because that VID and name are repeated lots of times. This makes it nearly impossible to add the VLAN through the GUI.

A potential workaround with the current state is to make all the VLAN names unique by adding the site name to the VLAN name, but this seems repetitive and less flexible, should the site name ever change for example.

A cursory glance makes this appear to be an issue with the REST API (and the q param) but there is also a site filter param that could be used in this case.

Database Changes

N/A

External Dependencies

N/A

Originally created by @tyler-8 on GitHub (Jan 3, 2020). Originally assigned to: @hSaria on GitHub. <!-- NOTE: This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.8<!-- Example: 3.5.4 --> * NetBox version: 2.6.7<!-- Example: 2.3.6 --> <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality When using the GUI Select2 fields for adding untagged/tagged VLANs to a device/VM interface, expand the search parameters to also search by site and VLAN group. Currently it appears that only the VLAN Name and VID are used. The dropdown currently displays the sites in the dropdown list, but they're not part of the search parameters. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case When you have a cookiecutter design for a particular type of site, the VIDs and VLAN names are repeated identically, and added to their respective sites and VLAN groups, if applicable. When you go to add those VLANs to an interface and search for vlan `5` for example, you may get dozens or hundreds of results because that VID and name are repeated lots of times. This makes it nearly impossible to add the VLAN through the GUI. A potential workaround with the current state is to make all the VLAN names unique by adding the site name to the VLAN name, but this seems repetitive and less flexible, should the site name ever change for example. A cursory glance makes this appear to be an issue with the REST API (and the `q` param) but there is also a `site` filter param that could be used in this case. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes N/A <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies N/A
adam added the status: acceptedtype: feature labels 2025-12-29 18:25:52 +01:00
adam closed this issue 2025-12-29 18:25:52 +01:00
adam commented 2025-12-29 18:25:53 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jan 19, 2020):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Jan 19, 2020): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:25:53 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Jan 20, 2020):

This is being worked on, stalebot!

@tyler-8 commented on GitHub (Jan 20, 2020): This is being worked on, stalebot!
adam commented 2025-12-29 18:25:53 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 20, 2020):

The PR (#3925) is awaiting maintainer review/merge. Hopefully they’ll get some free time soon now that the big issues from v2.7 have been fixed.

On 20 Jan 2020, at 6:33 pm, Tyler Bigler notifications@github.com wrote:


This is being worked on, stalebot!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

@hSaria commented on GitHub (Jan 20, 2020): The PR (#3925) is awaiting maintainer review/merge. Hopefully they’ll get some free time soon now that the big issues from v2.7 have been fixed. > On 20 Jan 2020, at 6:33 pm, Tyler Bigler <notifications@github.com> wrote: > >  > This is being worked on, stalebot! > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe.
adam commented 2025-12-29 18:25:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 21, 2020):

This is being worked on, stalebot!

Per the contributing guide:

Be sure to open an issue before starting work on a pull request, and discuss your idea with the NetBox maintainers before beginning work. This will help prevent wasting time on something that might we might not be able to implement. When suggesting a new feature, also make sure it won't conflict with any work that's already in progress.

and

Any pull request which does not relate to an accepted issue will be closed.

While community contributions are always appreciated, it is crucial that development effort remains focused on priorities. We introduced stalebot for a reason: to automatically close issues that are either not of interest (as indicated by the lack of discussion) or that we do not have the resources to explore currently.

Please wait to begin any work on an issue until after a maintainer has marked it as accepted, and understand that every issue that gets submitted has a time cost associated with it, as do pull requests. The mere presence of a pull request has no bearing on whether an issue gets accepted, as we cannot allow arbitrary engagement to drive long-term prioritization. We discourage contributors from expending the effort prematurely to avoid a situation where they perceive their time as wasted.

@jeremystretch commented on GitHub (Jan 21, 2020): > This is being worked on, stalebot! Per the [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md): > Be sure to open an issue before starting work on a pull request, and discuss your idea with the NetBox maintainers **before beginning work**. This will help prevent wasting time on something that might we might not be able to implement. When suggesting a new feature, also make sure it won't conflict with any work that's already in progress. and > Any pull request which does not relate to an **accepted** issue will be closed. While community contributions are always appreciated, it is crucial that development effort remains focused on priorities. We introduced stalebot for a reason: to automatically close issues that are either not of interest (as indicated by the lack of discussion) or that we do not have the resources to explore currently. Please wait to begin any work on an issue until _after_ a maintainer has marked it as accepted, and understand that _every_ issue that gets submitted has a time cost associated with it, as do pull requests. The mere presence of a pull request has no bearing on whether an issue gets accepted, as we cannot allow arbitrary engagement to drive long-term prioritization. We discourage contributors from expending the effort prematurely to avoid a situation where they perceive their time as wasted.
adam commented 2025-12-29 18:25:54 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jan 24, 2020):

I think one thing we need to make sure to capture in this, and I haven't looked at the PR yet to see if it is captured, is that when you search by VID, you need to search the global, the global groups, and the site specific vlan and vlan groups.

I do think this is something we should look at doing and it was on the todo list, however the filtering javascript would need more love then I could dedicate to it to get it working the way it needs to. If hSaria is willing to own this, I don't see any problem accepting it.

@DanSheps commented on GitHub (Jan 24, 2020): I think one thing we need to make sure to capture in this, and I haven't looked at the PR yet to see if it is captured, is that when you search by VID, you need to search the global, the global groups, and the site specific vlan and vlan groups. I do think this is something we should look at doing and it was on the todo list, however the filtering javascript would need more love then I could dedicate to it to get it working the way it needs to. If hSaria is willing to own this, I don't see any problem accepting it.
adam commented 2025-12-29 18:25:54 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 24, 2020):

@DanSheps Yep, that's captured in the PR.

... the global, the global groups, and the site specific vlan and vlan groups.

Simply limiting the VLANs to the global ones site_id=null and the site-specific ones site_id={site_pk} will achieve this.

There's an explanation in https://github.com/netbox-community/netbox/issues/3589#issuecomment-569978444, but here's the summary on why it works:

  • a VLAN can be in a global VLAN group only if it has no site, and
  • a VLAN can be in a site VLAN group only it it is in the same site.

Stated differently

  • a VLAN in a site cannot be in a global VLAN group, and
  • a VLAN not in a site cannot be in a site VLAN group.
@hSaria commented on GitHub (Jan 24, 2020): @DanSheps Yep, that's captured in the PR. > ... the global, the global groups, and the site specific vlan and vlan groups. Simply limiting the VLANs to the global ones `site_id=null` and the site-specific ones `site_id={site_pk}` will achieve this. There's an explanation in https://github.com/netbox-community/netbox/issues/3589#issuecomment-569978444, but here's the summary on why it works: > * a VLAN can be in a global VLAN group only if it has no site, and > * a VLAN can be in a site VLAN group only it it is in the same site. > > Stated differently > > * a VLAN in a site cannot be in a global VLAN group, and > * a VLAN not in a site cannot be in a site VLAN group.
adam commented 2025-12-29 18:25:54 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 27, 2020):

If hSaria is willing to own this, I don't see any problem accepting it.

@DanSheps, sure. The PR already adjusts how the data-additional-query-param-* is handled to allow multiple values (i.e. calling add_additional_query_param multiple times with the same name but different values will simply add to a list, instead of overriding it). If there's anything else you guys think needs to be done, I'd be happy to help where I can.

@hSaria commented on GitHub (Jan 27, 2020): > If hSaria is willing to own this, I don't see any problem accepting it. @DanSheps, sure. The PR already adjusts how the `data-additional-query-param-*` is handled to allow multiple values (i.e. calling `add_additional_query_param` multiple times with the same name but different values will simply add to a list, instead of overriding it). If there's anything else you guys think needs to be done, I'd be happy to help where I can.
adam commented 2025-12-29 18:25:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 30, 2020):

Marking this as blocked until we have a chance to look at consolidating the interface forms (#4057). Will keep the PR open.

@jeremystretch commented on GitHub (Jan 30, 2020): Marking this as blocked until we have a chance to look at consolidating the interface forms (#4057). Will keep the PR open.
adam commented 2025-12-29 18:25:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 14, 2020):

Unblocking since it might actually be easier to tackle #4057 after these changes are made.

@jeremystretch commented on GitHub (Feb 14, 2020): Unblocking since it might actually be easier to tackle #4057 _after_ these changes are made.
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 status: accepted 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#3120
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?