In menus, qualify device names with site and/or tenant

[candlerb]

NetBox version

v3.5.4

Feature type

Change to existing functionality

Proposed functionality

Currently when you get a drop-down selection list of devices (e.g. when creating a cable), the list shows only the device name.

However, device names are only unique within a given site/tenant.

Therefore if you have 100 sites, each with a device named "PDU", you will see a drop-down menu with 100 entries all called "PDU" - it's impossible to distinguish one from another.

Proposal: the menu label for a device should show "device name - site - tenant". If the device has no name, then "device model - id - site - tenant".

Use case

In some contexts it is possible to filter this list down further - e.g. by opening the filter sub-window and filtering on site.

But in general, I think presenting a menu of identical-looking choices (when in fact they are significantly different, and choosing the wrong one could be a serious error) is a poor user experience.

Database changes

None

External dependencies

None

[DanSheps]

Tangentially related: #11478

This same problem pops up in the context of interfaces.

[opericgithub]

Why don't you include site and/or tenant column in a table view?

[candlerb]

Additional point 1: it occurs to me that these menus need to be searchable efficiently using AJAX. This suggests that there should be a "display label" field which is cached in the database model - much in the same way as interfaces have a _name field for natural sorting.

(This could also have a unique constraint, which would guarantee that you can never accidentally have two indistinguishable items in a menu)

Additional point 2: another tangential issue. In custom scripts, I would like to do this:

    pop_site = ObjectVar(
        model=Site,
        label="POP Site",
        query_params={
            status="active",
        },
    })

However, this displays only the Site "Name" attribute. I need also to show (and be able to search on) a site code, which is held separately in custom_field_data['mdf_id'] - but ObjectVar doesn't allow customization of the display label.

My workaround (which is OK for now because the list of sites isn't too large) is to generate a materialized ChoiceVar instead:

    pop_site_id = ChoiceVar([
            (
                site.id,
                f"{site.name} - {site.custom_field_data['mdf_id']}" if site.custom_field_data.get('mdf_id')
                else site.name
            )
            for site in Site.objects.filter(status='active')
        ],
        label="POP Site",
    )

But in the long term, if Site also had a display _name attribute, whose contents could be overridden with a custom function, that would achieve the same goal in a cleaner way.

[candlerb]

@DanSheps: a vaguely related case which doesn't involve VCs is when a cable endpoint has multiple terminations, and those are interfaces on different devices, then the interface names may become indistinguishable: #10841

[DanSheps]

@DanSheps: a vaguely related case which doesn't involve VCs is when a cable endpoint has multiple terminations, and those are interfaces on different devices, then the interface names may become indistinguishable: #10841

It is related in that all of this (this issue and the one I referenced) relates to the serializer's display_name field not including context data.

[martinum4]

Therefore if you have 100 sites, each with a device named "PDU", you will see a drop-down menu with 100 entries all called "PDU" - it's impossible to distinguish one from another.

That seem like the same problem OpenStreetMap-Contributors are facing, names are names, not descriptions etc.

If the device is distinguishable from others by type and role and it has no actual assigned name just leave the name empty…

[DanSheps]

I think the example was made overly generic, but take for example:

"CORE-SW-01", you might have one in Site A and Site B. If you search just "CORE-SW-01" it will bring in all. However if there is a display_name attribute that includes more name context data (such as "CORE-SW-01, Site A, Region B" vs "CORE-SW-01, Site B, Region B" you can pick the appropriate one.

[candlerb]

Yes that's it exactly.

[ITJamie]

I have also been thinking about this and playing with ideas how to implement a fix in a sane way across models.
I made develop...ITJamie:netbox:alt_display_name as a concept of how we could define an "additional" standardized model property that if exists would be used in selection/multiselection boxes where additional context would be useful.

[martinum4]

I personally thing the end-user-friendliest approach would be to allow comma to be used as "search character", eg you search for "sw-core-1, samplecity" it then searches for "sw-core-1" first and in the results for that it searches for "samplecity" in all the other linked attributes (racks, locations, sites, regions).

[jsenecal]

I personally thing the end-user-friendliest approach would be to allow comma to be used as "search character", eg you search for "sw-core-1, samplecity" it then searches for "sw-core-1" first and in the results for that it searches for "samplecity" in all the other linked attributes (racks, locations, sites, regions).

There are also limitations in the frontend library that netbox uses as it currently only allows to find/select results which have the string typed in the select box. Just more things to consider when thinking about "searching" from additional fields/relationships.

[DanSheps]

I have also been thinking about this and playing with ideas how to implement a fix in a sane way across models.
I made develop...ITJamie:netbox:alt_display_name as a concept of how we could define an "additional" standardized model property that if exists would be used in selection/multiselection boxes where additional context would be useful.

I am not against this approach, but I think if we are doing this it makes more sense to override in get_display() instead.

That said, one option that this got me thinking about more, is to perhaps have the widget allow you to define a list of fields to include in the display name and it combines them itself (this would only work for fields available via the nested serializer). Something like:

  display_field: '$name ($device.display)'

This way, you could override it on the form itself without changing the underlying get_display function. The ApiSelect function would need to handle tokenizing the fields and replacing them but it is less "disruptive" to the underlying API.

[candlerb]

perhaps have the widget allow you to define a list of fields to include in the display name

How would this work with filter-as-you-type, when there are a large set of objects in the database? Does it currently use an indexed column (Name)?