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

@candlerb commented on GitHub (Jul 5, 2023):

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 commented on GitHub (Jul 5, 2023): 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.

adam commented

@candlerb commented on GitHub (Jul 5, 2023):

@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

@candlerb commented on GitHub (Jul 5, 2023): @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 ![image](https://github.com/netbox-community/netbox/assets/44789/02a1f641-e4d4-4f9d-8a7e-376462ff635c)

adam commented

@DanSheps commented on GitHub (Jul 5, 2023):

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

@DanSheps commented on GitHub (Jul 5, 2023): > @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.

adam commented

@martinum4 commented on GitHub (Jul 6, 2023):

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…

@martinum4 commented on GitHub (Jul 6, 2023): >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…

adam commented

@DanSheps commented on GitHub (Jul 6, 2023):

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.

@DanSheps commented on GitHub (Jul 6, 2023): 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.

adam commented

@candlerb commented on GitHub (Jul 6, 2023):

Yes that's it exactly.

@candlerb commented on GitHub (Jul 6, 2023): Yes that's it exactly.

adam commented

@ITJamie commented on GitHub (Jul 6, 2023):

I have also been thinking about this and playing with ideas how to implement a fix in a sane way across models.
I made https://github.com/netbox-community/netbox/compare/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.

@ITJamie commented on GitHub (Jul 6, 2023): ![Screenshot 2023-06-28 at 22 54 27](https://github.com/netbox-community/netbox/assets/1613241/bd0ee92e-e0bf-4cd7-932f-d2c77c688fc8) I have also been thinking about this and playing with ideas how to implement a fix in a sane way across models. I made https://github.com/netbox-community/netbox/compare/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.

adam commented

@martinum4 commented on GitHub (Jul 6, 2023):

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

@martinum4 commented on GitHub (Jul 6, 2023): 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).

adam commented

@jsenecal commented on GitHub (Jul 7, 2023):

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.

@jsenecal commented on GitHub (Jul 7, 2023): > 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.

adam commented

@DanSheps commented on GitHub (Jul 11, 2023):

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.

@DanSheps commented on GitHub (Jul 11, 2023): > 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](https://github.com/netbox-community/netbox/compare/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: ```python 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.

adam commented

@candlerb commented on GitHub (Jul 11, 2023):

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)?

@candlerb commented on GitHub (Jul 11, 2023): > 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)?

adam commented

@DanSheps commented on GitHub (Jul 11, 2023):

I believe the filter-as-you-type (might be mistaken mind you) uses a async request to dcim/interfaces/?q=X, which wouldn't interfere with it, to my knowledge.

Take this with a grain of salt as I am not a typescript expert.

@DanSheps commented on GitHub (Jul 11, 2023): I believe the filter-as-you-type (might be mistaken mind you) uses a async request to `dcim/interfaces/?q=X`, which wouldn't interfere with it, to my knowledge. Take this with a grain of salt as I am not a typescript expert.

adam commented

@candlerb commented on GitHub (Jul 11, 2023):

Yes you're right, for example it calls /api/dcim/devices/?brief=true&q=X when searching for a device to create a cable endpoint (seen via developer console)

The problem though will be that q may not match the strings being shown. For example, if the drop-down shows

core-sw-01 (site foo)
core-sw-02 (site bar)

and the user types 'bar', they would expect the list to contract to

core-sw-02 (site bar)

but I think it will just go to empty (testing seems to confirm this; if I type part of a site name, I don't see any devices)

@candlerb commented on GitHub (Jul 11, 2023): Yes you're right, for example it calls `/api/dcim/devices/?brief=true&q=X` when searching for a device to create a cable endpoint (seen via developer console) The problem though will be that `q` may not match the strings being shown. For example, if the drop-down shows ``` core-sw-01 (site foo) core-sw-02 (site bar) ``` and the user types 'bar', they would expect the list to contract to ``` core-sw-02 (site bar) ``` but I think it will just go to empty (testing seems to confirm this; if I type part of a site name, I don't see any devices)

adam commented

@github-actions[bot] commented on GitHub (Oct 10, 2023):

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 (Oct 10, 2023): 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

@ITJamie commented on GitHub (Oct 23, 2023):

@DanSheps you mentioned in https://github.com/netbox-community/netbox/pull/13156 that you were looking at another way to do this. I have vague memory of another PR fixing something like this but am having trouble tracking it down to suggest something similar for this.

@ITJamie commented on GitHub (Oct 23, 2023): @DanSheps you mentioned in https://github.com/netbox-community/netbox/pull/13156 that you were looking at another way to do this. I have vague memory of another PR fixing something like this but am having trouble tracking it down to suggest something similar for this.

adam commented