Ability to display additional relevant context data within the select UI

[DanSheps]

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

[sleepinggenius2]

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.

[jeremystretch]

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?

[DanSheps]

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.

[github-actions]

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.

[jeremystretch]

Marking this as blocked by either #14734 or #14917

[jeremystretch]

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.

[sleepinggenius2]

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.

[jeremystretch]

@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.

[sleepinggenius2]

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.

[jeremystretch]

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.