Global search in v.3.4.X become completely useless :(

[eudjinnl]

The most useful thing for me in netbox was the global search. It gives a lot of useful information with one request right from the front page - searched objects with Sites, Tenants, Racks etc.
You can put the one word from object's desctiption and get tons of information. Now it brings the object inself without any aditional information about where this object is located.

Earlier if you put part of the network or ip address like 172.16.101 you got all objects with their location, description etc. and using this additional information you was able to recognise the exect object you are looking for.

Now all this usability has gone. Why did you make this decision? Can you revert these changes and make global search like it was before?

[kkthxbye-code]

Hi @eudjinnl

You have three options:

• Downgrade to 3.3.x. As you said the old search is the single most important feature, so the math should be pretty easy, just stay on 3.3.x forever.
• Create a plugin that brings back the original search. If you do not possess the development skills to do it, I would suggest paying for someone to do it or try to get a community member to help you.
• Create an actual proposal as to how the search could be imporved without sacrificing performance, plugin support, custom_field search etc.

Why did you make this decision?

#10560
https://github.com/netbox-community/netbox/releases/tag/v3.4.0

Can you revert these changes and make global search like it was before?

No.

As an aside, venting posts are next to useless and in my opinion makes your opinion less likely to be heard. You did not include a single solution in your rant.

If you do decide to make a feature request, please remember to read the contributer guide and follow the FR template.

https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md#bulb-feature-requests

[eudjinnl]

I'm sorry if my post looks like a whining or something like that. In fact I would like to know what was the reason behind this change ant its purpose, because I really can't understand it.

I've read your link with "This new implementation provides a much faster, more intelligent search capability" but I think that every action implies a purpose. The purpose of search is to use searched information futher.

But what information do new search give us? That there are some objects with search string in them. That's it.
What can I do with this information except from clicking every object trying to find the one I'm looking for? No addition information is given. Search results don't even show full string in Value cells so part of the information become ommitted even there.

I watched the video on NetBox Labs YouTube channel https://www.youtube.com/watch?v=lHW3NGPPFy4 . It had 2 comments there and both of them about lack of information in new global search.

Hopefully there still is a workaround - it's possible to go to the object type, search there and get object of this type with location, tenant and other information but as for me it's less convenient that get all information in global search as it was before.

[jcollie]

@eudjinnl are you sure that you don't just need to rebuild the search cache? It doesn't always get built properly when migrating from 3.3 to 3.4. This Reddit comment was helpful when I was having problems searching.

[eudjinnl]

Why would you expect a search for "century" to show you something that doesn't have "century" anywhere in the object, except that it links to some other object that contains "century"? To me, the search return exactly what it should be returning. From what I understand of the new search plugins, if you really want a search of circuits to ALSO search the provider name, it should be possible to create a custom search plugin that enables that.

https://docs.netbox.dev/en/stable/plugins/development/search/

Talking about the demo I'll give you a real example of the search. Let's say that I want to find objects with "Wireless" in them. So you type "Wireless" in global search and get list of 19 lines which looks completely the same. It's impossible to differ one object from another unless you click on every object.

The demo data has lack of description but I use descriptions in my installation. Lets say I want to know all preffixes that contain "guest wifi" in decription. Or I want to know preffix for specific site that contain "guest wifi" in decription. I had several options:

1. Click IPAM, click Preffixes, type "guest wifi" in Quick search or Click Filter and type it there and get result the same as global serch but only for prefixes
2. Click Organisation, click Site group, click Site, Click Prefixes and only then use search
3. type "guest wifi" on global search, get bunch of all objects with search pattern and a lot of information connected with those objects, and this information gives you an opportunity to choose the object you need.
   As for me the third options was quickest and most convenient.

Now with global search we get results with just objects theirselves and it's impossible to understand where object belongs to

[candlerb]

Talking about the demo I'll give you a real example of the search. Let's say that I want to find objects with "Wireless" in them. So you type "Wireless" in global search and get list of 19 lines which looks completely the same. It's impossible to differ one object from another unless you click on every object.

What you actually see is:

It's clear to me that the first object is a Role, and the subsequent objects are VLANs. It also gives the name and the VLAN ID of each VLAN.

Could you be specific as to what in addition you would like to see in this view? Given that global search returns a mixture of object types, it will presumably be different for each object type. Are you asking for a return to separate tables for each object type found?

[eudjinnl]

You get 19 identical objects. How can you use this information further. It's unable to differ objects one from another because you don't see any additional information like where they are located, are networks connected to these vlans, you know nothing except from that there are 19 Vlan 300.
Please take a time for https://www.youtube.com/watch?v=lHW3NGPPFy4 . It compares old style global search result and new one. It's just 3 min long. It shows clearly how many information about objects you can get with old search and how small with new one.
Yep, I'm asking for old style of global search result.

[jcollie]

One could argue that you should give things meaningful (and at least semi-unique) names. It's no wonder someone would be confused when everything has the same name. There are probably a lot of contexts where the only thing that you know about an object is is name, therefore assigning meaningful names is pretty essential to me.

[candlerb]

I do understand what you're getting at. For reference, here's a result from a global search on a 2.11.12 test installation I have lying around:

Therefore, if you had assigned sites, tenants, descriptions etc to these vlans, then it would be quicker to see which was which. I think for now, when you realise that (a) that the result you're looking for is a VLAN, and (b) you have multiple matching VLANs which are not distinguishable by name/ID, then you'd have to do a search under IPAM>VLANs instead. The "quick search" box there may be sufficient, or if not, there is the Filters tab.

Similarly, if you're doing a global search on IP address, and if you have lots of overlapping IP addresses in different VRFs, then you'd currently be better searching under IP>IP Address rather than using global search.

The new global search feature is a complete re-implementation, where all the searchable fields are in a single table (extras_cachedvalue). As a result, it's convenient (and quick) for the results to show only the rows which were matched in that table.

However, in principle, it would be possible to fetch all the details for each object as part of rendering the results table.

One option would be to do separate SQL queries to fetch each object as they are rendered. (I wonder if that might be happening already - otherwise, how is the "Name (ID)" label rendered for a VLAN?)

Another option would be to show all the other indexed fields for the same object, i.e. select field,value from extras_cachedvalue where object_type_id=X and object_id=Y;, or dynamically built equivalent to fetch multiple objects in a single query.

However, I do think you could approach this in a more constructive way. Saying in effect "new global search is rubbish, put it back how it was before" isn't going to achieve much. The user interface changed partly because of the internal implementation change, and the internals are definitely not going back how they were before. But from this new starting point, I think that specific proposals for improvements to the user interface would be considered.

[PieterL75]

I got the same feedback from my netbox users.
They used to be able to find the exact item in one search. Now they rarely use the global search and go to the 'model table' and filter from there.
I agree that the new search is amazing fast, but the results returned are more like what you expect on a 'type ahead' dropdown in the topsearchbar.
The search results should contain more metadata, so that the users can find what they need in one search.

I don't have a solution or a proposal that really fixes this (as I don't know the ins and outs of the code and structure), but I think that the NetBox team should take our feedback into account, and brainstorm on what can be done to augment the global search result with extra relevant data.
I know that the feedback on the remarks on the 3.5 search were "Why was this not mentioned in the beta testing, you all agreed that it was good". But not every admin of NetBox is taking part of the early-adopter testing..

[seismiccollision]

i haven't even caught up to version 3.4 yet so it's hard to provide feedback in beta testing... the only reason i noticed this issue was from seeing this discussion

[jeremystretch]

I know that the feedback on the remarks on the 3.5 search were "Why was this not mentioned in the beta testing, you all agreed that it was good". But not every admin of NetBox is taking part of the early-adopter testing..

I've been begging and pleading for people to help evaluate the beta releases for years. I'll say it again here: We cannot act on feedback that is not provided.

i haven't even caught up to version 3.4 yet so it's hard to provide feedback in beta testing...

We provide a public demo of each beta release for 30 days leading up to the final release.

[PieterL75]

I think there needs to be an official beta test team.. #14031

Then you know how many people tested it, and what they tested..

[PieterL75]

/Whining alert/
Each time I use the GlobalSearch, I'm disappointed in the usability of the results...
ex: I enter part of a vlan, and want to see the status of those vlans... You can't do that in the global search anymore !
Only a flat list of the vlans, without any relevant info, no multiobject edit actions, nothing..

As User, this Global Search was a step back in usability.
I would love to see those results in the 'type-ahead' of the searchbar, but the global search should really be taken on again..

Unfortunately, I don't have the expertise or time to make something better, But I assume that whining about it, must trigger you to improve that part of NetBox

This is above all a discussion thread, and not a FR
/End whining alert/

My proposal

• If no objects are selected, then keep the same flat result als we have now.
• if one object is selected, then show that object's table, as if it was a 'quick' search, using the user's table view. But don;t do the 'quick-search', but keep the 'lookup' matching expression
• add 'type-ahead' to the general top-search bar, using the all-object result (limiting to 10 results)

[PieterL75]

I created a FR with a silly idea I had...
to use keywords to limit the models the globalsearch presents type-aheads, and brings you to the model list/search rather than the global search results
#12959

[seismiccollision]

this seems like a reasonable improvement, i could probably work with it but i will continue missing the old search

[matejv]

I think the new search works well in that it finds the correct objects. It's just that the displayed info for each object could be improved.

I was thinking that instead of just showing all results in a table with Type, Object, Field, Value columns, each type could define a "summary" view for its objects - what attributes to show on results screen as sort of a card view or something. It might be even possible to reuse list table columns settings for each type for this. Then each entry could show it's "results" view under the matching result. Something like this (but obviously much cleaner):

I haven't looked at the search code at all yet, so I don't know if this is even feasible. It would probably mean running one or multiple DB queries for each result, so I'm not sure how performant that would be. Unless this summary would also be cached with the search index.

[candlerb]

In principle, you could get all the name/value pairs for an object from extras_cachedvalue, with a single query.

But since there would be a different set of names for each object type, either you'd need to include them all inline in the same row, or have a separate subtable for object type (and it would potentially have many columns)

Or you could add some sort of "search view priority" field to determine which fields to show.

[candlerb]

I will clarify that with some examples, which show what I'm talking about and also the limitations of this method.

Suppose you got some results from extras_cachedvalue, like this:

netbox=# select * from extras_cachedvalue where value='nuc1';
                  id                  |          timestamp           | object_id | field | type | value | weight | object_type_id
--------------------------------------+------------------------------+-----------+-------+------+-------+--------+----------------
 5b309d43-b768-486a-8fa8-53f1d0d68cae | 2023-03-02 08:01:45.35041+00 |         1 | name  | str  | nuc1  |    100 |             28
(1 row)

This gives us an object_id, object_type_id pair to identify the object found. So you can get all the indexed fields from that object like this:

netbox=# select field,value from extras_cachedvalue where object_id=1 and object_type_id=28;
   field   |    value
-----------+--------------
 asset_tag | None
 serial    | GEFY12345ABC
 name      | nuc1
(3 rows)

I think that those by themselves will give many of the fields you're interested in for interpreting the search results, without having to query the main model tables. Unfortunately, not all of them - for example, you don't get the primary_ip of a device here.

Here's what you get for a VLAN:

netbox=# select field,value from extras_cachedvalue where object_id=9 and object_type_id=38;
    field    |        value
-------------+---------------------
 name        | nsrc-alt
 vid         | 251
 description | Alternate NSRC SSID
(3 rows)

That helps with the the use case given earlier in this thread: the VLANs show their vid and their description. But it doesn't show other distinguishing features, like Site.

If you search for an IP address, the extras_cachedvalue table doesn't tell you the interface or device it's attached to. That makes it considerably less useful.

Also you'd have to build up quite a complex query if you have a mix of object types from the initial search:

select ... from extras_cachedvalue
where (object_type_id=28 and object_id in (?,?...))
or (object_type_id=38 and object_id in (?,?...))
... etc

What's the alternative? Simply to query every model table in turn, where you had one or more matches from the extras_cachedvalue.

select * from dcim_device where id in (?,?...)
select * from ipam_vlan where id in (?,?...)
select * from ipam_ipaddress where id in (?,?...)
...

This will slow down the rendering a bit, but will give you the full results as you had from the original search functionality, without having to change how the new search works. It may be necessary to do some joins in these queries, e.g. if you want the device listing to show the primary IP address.

[candlerb]

And here's a really cheapskate way of doing it: in the search results, next to the group of each object type found (say VLANs), add a link saying "More info..." which points to /ipam/vlans/?id=x&id=y&id=z, where the ids are from the search results. Then the user will get whatever their preferred, configured set of columns is for each listing.

[Hamitka]

How did the discussion end?
I also saw a new search after updating from version 3.3.7 and was a little disappointed in its usability.
After reading the above, I don't quite understand how the improvement of search speed and its display to the user are related.

Is it possible, after all, to return the search result view to a more informative view?

[kkthxbye-code]

I've published a very simple plugin that reintroduces the old search method for anyone who prefers it to the new one.

https://github.com/kkthxbye-code/netbox-old-search

@Hamitka - you recently asked for the old search method. Feel free to try out the plugin to test if it works as expected.

[Hamitka]

Thanks a lot
Some bug has been found, but in overall, thank you very much!
Bug:

<class 'AttributeError'>

'NoneType' object has no attribute 'get_absolute_url'

Python version: 3.8.10
NetBox version: 3.5.7

[kkthxbye-code]

Could I get you to create an issue here: https://github.com/kkthxbye-code/netbox-old-search/issues/new

Please try to include a description of what triggered the exception and if possible the full exception. This can be found by either checking the logs or alternatively setting DEBUG = True in configuration.py, restarting netbox and triggering the exception again.

[craigmcfly]

Is there any direction / news on this?

I added some comments in #14069

[jeremystretch]

I have to say I'm pretty disappointed, given the amount of dissent in this thread, that no one has taken the initiative to propose a detailed, specific enhancement to the global search feature. Many thanks to @candlerb for shedding some light on the challenges involved and at least exploring some potential approaches.

I've just submitted FR #14134 to propose an enhancement to the current global search functionality that I believe is 1) feasible and 2) addresses the root frustrations surfaced in this thread, if not perfectly. Please provide your feedback on that issue if you are interested in participating in the proposed implementation.

[DanSheps]

Make sure you vote on the linked issue to show your support for it

[seismiccollision]

@DanSheps do you mean "thumbs up" for voting?
i also appreciate all @candlerb's support on this
it's intimidating to attempt to propose a detailed, specific enhancement when it feels like my odds favor that it will get shot down and i won't be able to back up my idea technically but i haven't stopped thinking and still do care about this

[DanSheps]

Yes, thumbs up

[PieterL75]

I must say that I tested that old search plugin, but never brought it to my users.
The output is great, but it takes up a ton of whitespace, and it is slow.
The speed was the main goal for the current search, so once you get used to that, it feels like using the old search is also a step back

I do like the idea of the extra one column with 'additional fields'. I really did think of ways, but this one never came to my brain...

[eudjinnl]

Thank you very much for adding additional information to global search in v3.7.0. It's great!