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

Ability to display additional relevant context data within the select UI #8374

New Issue
Closed
opened 2025-12-29 20:35:55 +01:00 by adam · 10 comments
adam commented 2025-12-29 20:35:55 +01:00
Owner
Copy Link

Originally created by @DanSheps on GitHub (Jul 27, 2023).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.5.6

Feature type

Change to existing functionality

Proposed functionality

Add the ability to display additional context relevant to each select dropdown

This display would be:

  • Flexible
  • Form specific (for example a interface form might show the context but perhaps the IP<>vlan assignment form it might omit the context)

Optionally, it could include:

  • Ability to configure the context data (code or perhaps even user configurable to suit needs)
  • Ability to show/hide as part of the actual final display of the field, and not just when searching

Use case

When you go to select a VLAN for an interface, you might be in a situation where you may have x number of vlans even if you search by a specific VID you might get a result from global vlans, site specific vlans, global group vlans, and group scoped (site, site group, location, etc) vlans. It currently is impossible to differentiate between all the different vlans

Database changes

None required

External dependencies

No response

Originally created by @DanSheps on GitHub (Jul 27, 2023). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.5.6 ### Feature type Change to existing functionality ### Proposed functionality Add the ability to display additional context relevant to each select dropdown This display would be: * Flexible * Form specific (for example a interface form might show the context but perhaps the IP<>vlan assignment form it might omit the context) Optionally, it could include: * Ability to configure the context data (code or perhaps even user configurable to suit needs) * Ability to show/hide as part of the actual final display of the field, and not just when searching ### Use case When you go to select a VLAN for an interface, you might be in a situation where you may have x number of vlans even if you search by a specific VID you might get a result from global vlans, site specific vlans, global group vlans, and group scoped (site, site group, location, etc) vlans. It currently is impossible to differentiate between all the different vlans ### Database changes None required ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 20:35:55 +01:00
adam closed this issue 2025-12-29 20:35:56 +01:00
adam commented 2025-12-29 20:35:56 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Sep 11, 2023):

The other big place I just got hit with this is when working with any of the nested models, like Region or Site Group. It displays the nicely indented hierarchy by default, but when you are filtering, all of the context disappears. Since the unique constraint only requires the name to be unique to its parent, not having at least that parent context is rough. We've been finding ourselves having to replicate parent data into the child name, just to make the value more "globally" unique and easily selectable in a dropdown, which kind of defeats the purpose of having the nested model.

@sleepinggenius2 commented on GitHub (Sep 11, 2023): The other big place I just got hit with this is when working with any of the nested models, like Region or Site Group. It displays the nicely indented hierarchy by default, but when you are filtering, all of the context disappears. Since the unique constraint only requires the name to be unique to its parent, not having at least that parent context is rough. We've been finding ourselves having to replicate parent data into the child name, just to make the value more "globally" unique and easily selectable in a dropdown, which kind of defeats the purpose of having the nested model.
adam commented 2025-12-29 20:35:57 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 13, 2023):

The select widget populates options using the "brief" format of REST API results, which includes minimal representations of objects. Is the proposal here to revert to the full representation to make additional attributes accessible?

@jeremystretch commented on GitHub (Oct 13, 2023): The select widget populates options using the "brief" format of REST API results, which includes minimal representations of objects. Is the proposal here to revert to the full representation to make additional attributes accessible?
adam commented 2025-12-29 20:35:57 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 18, 2023):

Is the proposal here to revert to the full representation to make additional attributes accessible?

I think when I originally set this up, I wasn't nessicarily thinking this specifically, however this would be the easiest way to do it likely and it may be worth exposing the full results to pull in more attributes for other uses.

@DanSheps commented on GitHub (Oct 18, 2023): > Is the proposal here to revert to the full representation to make additional attributes accessible? I think when I originally set this up, I wasn't nessicarily thinking this specifically, however this would be the easiest way to do it likely and it may be worth exposing the full results to pull in more attributes for other uses.
adam commented 2025-12-29 20:35:57 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 17, 2024):

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jan 17, 2024): 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. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:35:57 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 24, 2024):

Marking this as blocked by either #14734 or #14917

@jeremystretch commented on GitHub (Jan 24, 2024): Marking this as blocked by ~either #14734 or~ #14917
adam commented 2025-12-29 20:35:58 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 9, 2024):

I'm making great progress with this using tom-select. The approach I've settled on its to establish a common template for rendering dropdown options, which will take the following variables as context data:

  • id: The option's value when selected (required)
  • label: The option's primary human-visible label (required)
  • parent: The option's parent object; e.g. an interface's device (optional)
  • description: Text to be displayed below the primary label, truncated to a maximum length (optional)
  • depth: The object's depth within a hierarchy, used to indent the label; e.g. regions (optional)

These will have default values which can be overridden on individual form fields.

@jeremystretch commented on GitHub (Feb 9, 2024): I'm making great progress with this using tom-select. The approach I've settled on its to establish a common template for rendering dropdown options, which will take the following variables as context data: - `id`: The option's value when selected (required) - `label`: The option's primary human-visible label (required) - `parent`: The option's parent object; e.g. an interface's device (optional) - `description`: Text to be displayed below the primary label, truncated to a maximum length (optional) - `depth`: The object's depth within a hierarchy, used to indent the label; e.g. regions (optional) These will have default values which can be overridden on individual form fields.
adam commented 2025-12-29 20:35:58 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Feb 9, 2024):

Would it be possible to also include an optional status, like is shown on the selector search results today? It seems to me like the data models and potentially even the rendering for both of those could be almost identical.

@sleepinggenius2 commented on GitHub (Feb 9, 2024): Would it be possible to also include an optional status, like is shown on the selector search results today? It seems to me like the data models and potentially even the rendering for both of those could be almost identical.
adam commented 2025-12-29 20:35:58 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 9, 2024):

@sleepinggenius2 Possibly, but we have to be cognizant of how much data we can reasonably squeeze into a single dropdown item. Remember that the goal here is to help the user differentiate among the available options. Including the status may make sense, but we also want to be careful not to overwhelm the user with extraneous content.

@jeremystretch commented on GitHub (Feb 9, 2024): @sleepinggenius2 Possibly, but we have to be cognizant of how much data we can reasonably squeeze into a single dropdown item. Remember that the goal here is to help the user differentiate among the available options. Including the status may make sense, but we also want to be careful not to overwhelm the user with extraneous content.
adam commented 2025-12-29 20:35:58 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Feb 9, 2024):

Totally understand the space constraints. It just seemed like a good opportunity to potentially align the template for dropdown items and for selector search results to provide a consistent user experience between both interfaces, as well as from a maintainability standpoint. There already seemed to be a lot of overlap with the variables you were defining.

@sleepinggenius2 commented on GitHub (Feb 9, 2024): Totally understand the space constraints. It just seemed like a good opportunity to potentially align the template for dropdown items and for selector search results to provide a consistent user experience between both interfaces, as well as from a maintainability standpoint. There already seemed to be a lot of overlap with the variables you were defining.
adam commented 2025-12-29 20:35:58 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 9, 2024):

I ended up adding support for six discrete attributes:

  • Value
  • Label
  • Disabled indicator
  • Description
  • Depth in hierarchy (for indentation)
  • Parent object

I'm going to leave it at this for now, as we can't currently populate some of these attributes anyway due to the use of "brief" mode in retrieving the API data. (#15087 should address this.) The important part is that we've established a pattern for declaring and rendering these attributes, which can be easily extended in the future if need be.

@jeremystretch commented on GitHub (Feb 9, 2024): I ended up adding support for six discrete attributes: - Value - Label - Disabled indicator - Description - Depth in hierarchy (for indentation) - Parent object I'm going to leave it at this for now, as we can't currently populate some of these attributes anyway due to the use of "brief" mode in retrieving the API data. (#15087 should address this.) The important part is that we've established a pattern for declaring and rendering these attributes, which can be easily extended in the future if need be.
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#8374
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?