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

Display additional object attributes in global search results #8784

New Issue
Closed
opened 2025-12-29 20:41:09 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:41:09 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Oct 28, 2023).

Originally assigned to: @jeremystretch on GitHub.

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.

screenshot

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

Originally created by @jeremystretch on GitHub (Oct 28, 2023). Originally assigned to: @jeremystretch on GitHub. ### 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. ![screenshot](https://github.com/netbox-community/netbox/assets/13487278/dcc99e38-3a83-4e23-940e-a9299ef28007) #### 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: ```python @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()`](https://docs.djangoproject.com/en/4.2/ref/models/querysets/#django.db.models.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
adam added the status: acceptedtype: feature labels 2025-12-29 20:41:09 +01:00
adam closed this issue 2025-12-29 20:41:10 +01:00
adam commented 2025-12-29 20:41:10 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Oct 29, 2023):

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.

@candlerb commented on GitHub (Oct 29, 2023): > 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.
adam commented 2025-12-29 20:41:10 +01:00
Author
Owner
Copy Link

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

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.

@jeremystretch commented on GitHub (Oct 30, 2023): > 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.
adam commented 2025-12-29 20:41:10 +01:00
Author
Owner
Copy Link

@eudjinnl commented on GitHub (Oct 31, 2023):

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?

@eudjinnl commented on GitHub (Oct 31, 2023): 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?
adam commented 2025-12-29 20:41:11 +01:00
Author
Owner
Copy Link

@seismiccollision commented on GitHub (Nov 2, 2023):

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)

@seismiccollision commented on GitHub (Nov 2, 2023): 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)
adam commented 2025-12-29 20:41:11 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Nov 2, 2023):

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'

@PieterL75 commented on GitHub (Nov 2, 2023): 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'
adam commented 2025-12-29 20:41:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 2, 2023):

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

@jeremystretch commented on GitHub (Nov 2, 2023): @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.
adam commented 2025-12-29 20:41:11 +01:00
Author
Owner
Copy Link

@eudjinnl commented on GitHub (Jan 9, 2024):

Guys, thank you for update. I've just installed it and made some searches. It looks great!
The discussion started by me went not so good from the beginning (sorry for that) but now we have that change in global search! I really appreciate your work. Thank you!

@eudjinnl commented on GitHub (Jan 9, 2024): Guys, thank you for update. I've just installed it and made some searches. It looks great! The discussion started by me went not so good from the beginning (sorry for that) but now we have that change in global search! I really appreciate your work. Thank you!
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#8784
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?