Display additional object attributes in global search results

[jeremystretch]

NetBox version

v3.6.4

Feature type

Change to existing functionality

Proposed functionality

This FR proposes extending NetBox's global search feature to include certain additional object attributes when display global search results. (This does not impact model-specific filters.) Several extensions are necessary to implement this in a feasible manner.

1. Define display attributes on each SearchIndex class

The display_attrs attribute will define the additional attributes (if any) to include alongside search results. For example:

@register_search
class DeviceIndex(SearchIndex):
    model = models.Device
    fields = (
        ('asset_tag', 50),
        ('serial', 60),
        ('name', 100),
        ('description', 500),
        ('comments', 5000),
    )
    display_attrs = ('site', 'location', 'rack', 'description')

This tells NetBox to also include the site, location, rack, and description for each global search result returning a device. Attributes will be included only if the object has a non-empty value for the specified field.

Although these attributes don't directly impact the search engine itself, IMO we should set them on the indexers (as opposed to the models) to maintain a clean API.

2. Extend search backend to support prefetching of display attributes

Prefetching related objects is necessary to ensure a reasonably performant implementation. Using the example above, each matching device would trigger up to three discrete SQL queries (on each for site, location, and device) without prefetching enabled. (This is necessary only for related objects: Concrete fields will have already been populated while retrieving the object associated with each result.)

We should be able to employ Django's prefetch_related_objects() utility function to attach prefetched objects to the results list after it has been retrieved. However, because global search results are heterogeneous, we must manually attach prefetched objects per result type. This will require calling prefetch_related_objects() on subsets of the results list organized by content type.

3. Determine how to display the additional attributes

Assuming we can efficiently retrieve the attributes, we still need to determine the best way to incorporate them into the search results. I see several options:

1. Introduce a single column to hold all attributes per result.
2. List all results in a separate row beneath each result.
3. Dynamically add a table column for each attribute across all results.

There are pros and cons to each approach, however I don't consider option 3 truly viable, as it could generate very large tables when many types of objects are returned, and would be very difficult for the user to read. Option 1 (shown above) is probably the simplest.

Use case

These attributes are intended to convey additional context to the user where readily distinguishing between similar search results may be difficult. For example, multiple results might each reference a "VLAN 100," each of which is assigned to a different site. This enhancement provides the context necessary for the user to see the site to which each VLAN is assigned without needing to navigate to each object individually.

Database changes

I don't believe any changes to the database schema are necessary to support this functionality. We probably won't even need to trigger a re-indexing of cached values.

External dependencies

None

[candlerb]

This will require calling prefetch_related_objects() on subsets of the results list organized by content type.

But taking this to its logical conclusion, you could also render separate tables for each content type (i.e. Device, Site, VLAN etc)

If you did this, then there would be no need for any separate display_attrs configuration. You'd just display the normal tables for each object type, with the user's preferred set of columns from the listing views.

The output would then look very similar to global search in older versions of Netbox. It wouldn't be quite so compact vertically, as you'd need a main heading and a row of column headings for each object type, but it would be better horizontally as you wouldn't need a "Type" column.

[jeremystretch]

But taking this to its logical conclusion, you could also render separate tables for each content type (i.e. Device, Site, VLAN etc)

That's not a viable solution, because results are now properly ordered by relevance (weight) rather than type. It's entirely possible, for example, to return some devices, then some sites, then more devices, then a circuit, and then more devices. Breaking these into separate tables would look terrible and be difficult to read, especially since each table would render separately with its own column widths. On top of that, it would preclude us from using the stock table rendering utilities: It would need to employ custom templating to manually start a new table each time the object type changes.

[eudjinnl]

This way it looks much better as for me. List of found objects can be really long but anyway there is some information to differentiate the objects.
I think if Site/Tenant and description information is provided for every object it would be great.

Another moment, now if we have match in description field NetBox show us quote from full description with pattern it has found. Is it possible to show us full description?

[seismiccollision]

option 1 sounds like a good step forward. it might additionally be nice if attributes that already have defined colors like "status" were rendered in the results with those colors (where the current screenshot has all attributes in grey bubbles)

[PieterL75]

I do like this idea, I never made it further than option 2 or 3.
It will give a clean, fast result

The only thing I'm missing is a link to the object search page. For ex, I'm looking for 'test0', I see the devices that I want, but it depends on a custom field to choose the device I want to open.
My personal device search table is customized to show that custom field.
So I would like to see a link that brings you to the device search page (or whatever model you need), with 'q=test0'

[jeremystretch]

@PieterL75 where would you put that link? IMO there's no natural spot to place a single model-specific link, but maybe we could add a simple icon link in the object type column to direct users to the search for that specific type of object.