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

GlobalSearch: Find related items #7241

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

Originally created by @PieterL75 on GitHub (Nov 17, 2022).

NetBox version

v3.4-beta

Feature type

Change to existing functionality

Proposed functionality

When searching for an IP address, it would be great if the device it is assigned to, also is found.

When searching for an IP address, it would be great if the prefixes, aggregrate it falls under , also is found.

etc

Use case

Augment the search results, so that relations between the searched item and related objects in netbox are seen

Database changes

No response

External dependencies

No response

Originally created by @PieterL75 on GitHub (Nov 17, 2022). ### NetBox version v3.4-beta ### Feature type Change to existing functionality ### Proposed functionality When searching for an IP address, it would be great if the device it is assigned to, also is found. When searching for an IP address, it would be great if the prefixes, aggregrate it falls under , also is found. etc ### Use case Augment the search results, so that relations between the searched item and related objects in netbox are seen ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:20:46 +01:00
adam closed this issue 2025-12-29 20:20:46 +01:00
adam commented 2025-12-29 20:20:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 17, 2022):

I intentionally did not include related objects in the search results, for several reasons. Primarily, it pollutes the search results with a large number of redundant and likely irrelevant entries. It's only ever possible to return objects related to an object that is already present in the search results (and that would have a higher precedence than the related objects).

It's also extremely difficult to ensure the accuracy of cached results across relationships, particularly those where no foreign key exists (such as from an IP address to its containing prefixes). By limiting the results to direct object attributes, we ensure a highly performant and accurate engine that returns only directly relevant results.

@jeremystretch commented on GitHub (Nov 17, 2022): I intentionally did not include related objects in the search results, for several reasons. Primarily, it pollutes the search results with a large number of redundant and likely irrelevant entries. It's only ever possible to return objects related to an object that is already present in the search results (and that would have a higher precedence than the related objects). It's also extremely difficult to ensure the accuracy of cached results across relationships, particularly those where no foreign key exists (such as from an IP address to its containing prefixes). By limiting the results to direct object attributes, we ensure a highly performant and accurate engine that returns only directly relevant results.
adam commented 2025-12-29 20:20:47 +01:00
Author
Owner
Copy Link

@julianstolp commented on GitHub (Nov 18, 2022):

I like the speed of the new search, but I think a lot of the clarity and usability of the search results has been lost.
It was always useful to compare the search results by, for example, part of the device name with the related results and thus quickly select the actual device you are looking for. I almost never enter complete search terms.

Would it be possible to dynamically reload the related search results and integrate them into the table as a column?

So in principle visually exactly as built up to version 3.3 only the related objects are dynamically reloaded.

@julianstolp commented on GitHub (Nov 18, 2022): I like the speed of the new search, but I think a lot of the clarity and usability of the search results has been lost. It was always useful to compare the search results by, for example, part of the device name with the related results and thus quickly select the actual device you are looking for. I almost never enter complete search terms. Would it be possible to dynamically reload the related search results and integrate them into the table as a column? So in principle visually exactly as built up to version 3.3 only the related objects are dynamically reloaded.
adam commented 2025-12-29 20:20:47 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Jan 4, 2023):

Global search has been a big hit and our team are really thankful, but like above users feel it would be nice for some of the "related" info to be available again.

for example,

  • on a vlan result, the vlan group
  • on an ip, the associated device
  • on a device, the tenant or device role

The new search results are incredibly fast. We would be more than willing to sacrifice some of that speed for more context.

if a "second" data pull stage happened after retrieving the search results to go pull the information for each result on the current results page i understand it would slow down the responsiveness, this could be a configurable option or even a toggle in the search bar.

one of the ways of limiting the overhead would be to set a separate pagination limit for the amount of results shown per page on search, that way if say it finds 1000 results, the newer pagination limit (lets say 100) would mean that netbox would only need to look up additional data on the current page of 100 results. that would make netbox still feel fast while giving the previous search result contexts?

this would also have the advantage of global search cache getting "tested" before being displayed. eg if during the second stage where it pulls more info about each object, it could check that the field it was found still matches the search param, if not it could be ignored and cache marked as "bad" for that object

@ITJamie commented on GitHub (Jan 4, 2023): Global search has been a big hit and our team are really thankful, but like above users feel it would be nice for some of the "related" info to be available again. for example, - on a vlan result, the vlan group - on an ip, the associated device - on a device, the tenant or device role The new search results are incredibly fast. We would be more than willing to sacrifice some of that speed for more context. if a "second" data pull stage happened after retrieving the search results to go pull the information for each result on the current results page i understand it would slow down the responsiveness, this could be a configurable option or even a toggle in the search bar. one of the ways of limiting the overhead would be to set a separate pagination limit for the amount of results shown per page on search, that way if say it finds 1000 results, the newer pagination limit (lets say 100) would mean that netbox would only need to look up additional data on the current page of 100 results. that would make netbox still feel fast while giving the previous search result contexts? this would also have the advantage of global search cache getting "tested" before being displayed. eg if during the second stage where it pulls more info about each object, it could check that the field it was found still matches the search param, if not it could be ignored and cache marked as "bad" for that object
adam commented 2025-12-29 20:20:47 +01:00
Author
Owner
Copy Link

@t8simon commented on GitHub (Jan 12, 2023):

I would not see it as pollution, more as an enrichment, which eliminates clicks and gains more overview for the user (as long as there is grouping of objects).
With the new results in 3.4 I tend to often not use the global search but go to the model and filter for example on the IP-Address table instead, because there I have most of the related Items that I need. But this only works if I know on what model to dig - sometimes there is just a keyword that needs to be searched over everything and then it can be a lot of clicks to find the relevant items in context. Especially for users that don't use netbox regularly the acceptance has worsened.

The overview in the old results was quiet good (especially the grouping), although I wished for the same table content flexibility as in the model table (with adding / removing columns). Also some related Items would be nice to show up. For example when searching for vm2 it would be nice to have the IP addresses belonging to vm2 appearing as results as well.

@t8simon commented on GitHub (Jan 12, 2023): I would not see it as pollution, more as an enrichment, which eliminates clicks and gains more overview for the user (as long as there is grouping of objects). With the new results in 3.4 I tend to often not use the global search but go to the model and filter for example on the IP-Address table instead, because there I have most of the related Items that I need. But this only works if I know on what model to dig - sometimes there is just a keyword that needs to be searched over everything and then it can be a lot of clicks to find the relevant items in context. Especially for users that don't use netbox regularly the acceptance has worsened. The overview in the old results was quiet good (especially the grouping), although I wished for the same table content flexibility as in the model table (with adding / removing columns). Also some related Items would be nice to show up. For example when searching for vm2 it would be nice to have the IP addresses belonging to vm2 appearing as results as well.
adam commented 2025-12-29 20:20:47 +01:00
Author
Owner
Copy Link

@michaelklose commented on GitHub (Jan 12, 2023):

The overview in the old results was quiet good (especially the grouping), although I wished for the same table content flexibility as in the model table (with adding / removing columns). Also some related Items would be nice to show up. For example when searching for vm2 it would be nice to have the IP addresses belonging to vm2 appearing as results as well.

I fully agree with your points. For example we miss currently the status of an object in the results.

@michaelklose commented on GitHub (Jan 12, 2023): > The overview in the old results was quiet good (especially the grouping), although I wished for the same table content flexibility as in the model table (with adding / removing columns). Also some related Items would be nice to show up. For example when searching for vm2 it would be nice to have the IP addresses belonging to vm2 appearing as results as well. I fully agree with your points. For example we miss currently the status of an object in the results.
adam commented 2025-12-29 20:20:48 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jan 12, 2023):

I also miss the 'Refine Search' button now..
When looking for devices, they were grouped together with low details.. Clicking the 'refine search' brought me direct to the device list page, and I was able to bulk update in a click..
Now I have to search, copy the search value, go to the device list page, open the filter tab and enter the search value
(or alternatively, go direct to that devicefilter, but then the global search page is loosing its importance)

I was actualy about to open a FR to have the search pages show the users-customized-list per model, in stead of that fixed table. But then the new search came, and made me 'looking as a cat in a tree'

@PieterL75 commented on GitHub (Jan 12, 2023): I also miss the 'Refine Search' button now.. When looking for devices, they were grouped together with low details.. Clicking the 'refine search' brought me direct to the device list page, and I was able to bulk update in a click.. Now I have to search, copy the search value, go to the device list page, open the filter tab and enter the search value (or alternatively, go direct to that devicefilter, but then the global search page is loosing its importance) I was actualy about to open a FR to have the search pages show the users-customized-list per model, in stead of that fixed table. But then the new search came, and made me 'looking as a cat in a tree'
adam commented 2025-12-29 20:20:48 +01:00
Author
Owner
Copy Link

@ataylor93 commented on GitHub (Jan 25, 2023):

I would like to add that the related objects feel like a major loss of functionality.

Being able to search an IP address to get its parent prefix and/or site that it belongs to was SO useful. I use it on a daily basis.

Love the speed of the new search but would certainly trade that back for the usability of the previous model.

@ataylor93 commented on GitHub (Jan 25, 2023): I would like to add that the related objects feel like a major loss of functionality. Being able to search an IP address to get its parent prefix and/or site that it belongs to was SO useful. I use it on a daily basis. Love the speed of the new search but would certainly trade that back for the usability of the previous model.
adam commented 2025-12-29 20:20:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 25, 2023):

Love the speed of the new search but would certainly trade that back for the usability of the previous model.

That's funny, because for years the old search model was a constant source of complaints due to how limited and slow it was.

Folks, I can appreciate that people that people would prefer an ideal search solution, but this is what I came up with after several weeks of effort. I won't claim it's the best possible solution, but I didn't see anyone else propose something better. Now, if anyone would like to invest the time and effort in researching specifically how the existing implementation can be improved, I'm more than happy to discuss. However, this FR in its current form - which amounts to little more than lamenting the trade-offs of the new implementation - is not actionable, so I'm going to close it.

Again, if anyone is interested in putting in the work to address the problems I noted above, I'm happy to discuss in a new FR outlining the specific proposed improvements and how they can be feasibly achieved.

@jeremystretch commented on GitHub (Jan 25, 2023): > Love the speed of the new search but would certainly trade that back for the usability of the previous model. That's funny, because for years the old search model was a constant source of complaints due to how limited and slow it was. Folks, I can appreciate that people that people would prefer an ideal search solution, but this is what I came up with after several weeks of effort. I won't claim it's the best possible solution, but I didn't see anyone else propose something better. Now, if anyone would like to invest the time and effort in researching specifically _how_ the existing implementation can be improved, I'm more than happy to discuss. However, this FR in its current form - which amounts to little more than lamenting the trade-offs of the new implementation - is not actionable, so I'm going to close it. Again, if anyone is interested in putting in the work to address the problems I noted [above](https://github.com/netbox-community/netbox/issues/10944#issuecomment-1318618794), I'm happy to discuss in a new FR outlining the specific proposed improvements and how they can be feasibly achieved.
adam commented 2025-12-29 20:20:48 +01:00
Author
Owner
Copy Link

@ataylor93 commented on GitHub (Jan 25, 2023):

Provide a checkbox on the search page to include related objects? Or an option somewhere in the config to turn this on/off by default?

@ataylor93 commented on GitHub (Jan 25, 2023): Provide a checkbox on the search page to include related objects? Or an option somewhere in the config to turn this on/off by default?
adam commented 2025-12-29 20:20:48 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jan 25, 2023):

I agree that it is not feasible to try to replicate the old-result style.

Can the current table be extended with 2 columns ? related model, related ID.
When being indexed, that related item can be shown in the result. not as an extra item in the list, but as a column on a result.

plugins should also be able to provide a way to explain what a 'related item' is for the models they create...

That might be a compromise to the current view ?

For the refine search, you could add that as a dropdown on top of the result. open the dropdown, select the model and go to the searchpage of that model with the current search parameter

@PieterL75 commented on GitHub (Jan 25, 2023): I agree that it is not feasible to try to replicate the old-result style. Can the current table be extended with 2 columns ? related model, related ID. When being indexed, that related item can be shown in the result. not as an extra item in the list, but as a column on a result. plugins should also be able to provide a way to explain what a 'related item' is for the models they create... That might be a compromise to the current view ? For the refine search, you could add that as a dropdown on top of the result. open the dropdown, select the model and go to the searchpage of that model with the current search parameter
adam commented 2025-12-29 20:20:49 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jan 25, 2023):

Thinking of it.. the search is that fast, it could even be possible to search 'parents' if requested.
Meaning that all 'related objects are also added to there result, and their related items, till no more relations are found..

@PieterL75 commented on GitHub (Jan 25, 2023): Thinking of it.. the search is that fast, it could even be possible to search 'parents' if requested. Meaning that all 'related objects are also added to there result, and their related items, till no more relations are found..
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 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#7241
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?