Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #844] search not returning all results, only first match (without * at the end) #396

Closed
icinga-migration opened this issue Oct 1, 2010 · 24 comments
Milestone

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/844

Created by Infinity on 2010-10-01 22:00:17 +00:00

Assignee: ricardo
Status: Resolved (closed on 2011-11-22 12:21:10 +00:00)
Target Version: 1.6
Last Update: 2014-12-08 09:50:31 +00:00 (in Redmine)

Icinga Version: 1.10.0
OS Version: any

Making a normal search with a "regexp" return only the first result.
How to reproduce the problem:
i have 3 hosts, named: host01,host02,host03, if i will run a search against host or host0 i will receive the first result which is host01 and not all host*.

I might be missing something here, but isnt this the purpose of the search engine? if i want to see all host* so i will be able to search by just typing host?

Attachments

Changesets

2010-10-02 13:20:42 +00:00 by mfriedrich 4f28f61

classic ui: fix search not returning all results, only first match (without * at the end) #844

last minute patch by Ricardo, great!

fixes #844

2011-04-05 10:41:36 +00:00 by ricardo d787f07

first part of status.cgi rewrite

* added a new struct witch holds status data for hosts AND services
* just one sort function left
* data for host and service list get filtered first and if necesarry filtered then
* corrected indentation

refs: #844
refs: #852

2011-11-05 16:14:22 +00:00 by ricardo 03224af

classic ui: fixed search not returning all results, only first match (without * at the end) #844

refs: #844

Done a rewrite of the search part. If user is searching something and a host or service
matches, then the status entry gets marked as a match. When statusdata gets displayed
it only shows the matching one's. Added "search_matched" to both statusdata struct.

The filter uses regular expressions. Following items get checked against search string:

* Host
** Host Name
** Display Name
** Alias
** Address
** Address6

* Service
** Description
** Display Name
** Host Name
** combination of hostname and service description "hostname servicedescription"

If all of this fails it tries to find a hostgroup or servicegroup which has to match the
exact search string. This is still the old behavior.

2011-11-06 18:54:32 +00:00 by ricardo 46a1e76

classic-ui: restores backwards compatibility with old search method #844

refs: #844

Adds old search method again.

Minor bug fixes.

2011-11-14 20:37:25 +00:00 by ricardo 3f7f38f

classic-ui: bugfixes for search in status.cgi #844

refs: #844

* fixing problem with NULL pointer
* fixing status list titles

Relations:

@icinga-migration
Copy link
Author

Updated by ricardo on 2010-10-01 23:52:43 +00:00

  • File added fixed_wildcard_problem_in_search_844.diff
  • Status changed from New to Resolved
  • Assigned to set to ricardo
  • Target Version set to 1.2 (Stable)
  • Done % changed from 0 to 90

patch is attached

It usually works with "host*".

With this patch its possible to use "host" without the wildcard character.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-10-02 13:18:31 +00:00

  • Subject changed from New search does not return all results to search not returning all results, only first match (without * at the end)

@icinga-migration
Copy link
Author

Updated by ricardo on 2010-10-05 08:54:21 +00:00

  • Status changed from Resolved to Assigned
  • Target Version changed from 1.2 (Stable) to 62

sorry, have to revert the commit

it seems it's not working out properly.

Will have a look after my holidays.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-10-10 12:14:02 +00:00

  • Target Version changed from 62 to 1.3

@icinga-migration
Copy link
Author

Updated by ricardo on 2010-11-05 10:42:21 +00:00

my thoughts about this:

In my opinion status.cgi has to rewritten a quite a bit.

the filters have to apply before any "ouput function" gets triggerd.

And so it's much easier to simply show the prefiltered data.

In main a new function after reading_cgi_vars must be implemented with takes the host and service data, filters it, and putting it into new objects which are get displayed.

At the moment every "display function" is doing this on it's own.

And with this structure it is easy to implement a search.

I hope you get what I tried to say :-)

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-01-04 07:32:39 +00:00

  • Target Version changed from 1.3 to 1.5
  • Done % changed from 90 to 50

yep, a new backend api would do the trick, something like livestatus provides now, and the core should provide in that case - extended from the rest.

i'll postpone to next unstable version, ok?

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-04-07 20:33:52 +00:00

  • Target Version changed from 1.5 to 1.4

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-04-27 18:30:39 +00:00

while implementing the display_name search - it's mainly being done over here:

if((strstr(temp_host->name,host_name)==temp_host->name) || !strncasecmp(temp_host->name,host_name,strlen(host_name))){

given the fact, that it's not a regex, it would probably need one for the future searches of status.c

so a considered solution can be manually adding a new regexp as host_filter instead of providing the blank host_name as search attribute.

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-04-27 23:20:55 +00:00

Would be nice if you have a quick solution for it for now.

As already mentioned, this whole search stuff has to be rewritten.

Question:

is it possible to do make the search field live search able again with javascript? It could request with an url and get a result in jason? Anyone knowledge on that?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-04-28 09:29:55 +00:00

dunno if the quickfix is applicable for 1.4 though - it would be a replacement hack. but ypou are right, the search needs to be rewritten either way.

regarding the livesearch - i have thought about a while ago. it is possible using e.g. jquery (like most of the examples out there use it).
you'll mainly need a cgi providing the data in an xml formatted way, searching through stuff with specified GET mechanism.
the main problem i can see - it opens doors for hackers, if the cgi providing the data is in an unsafe, public place - meaning to be accessed with some GET params. the users still needs to be authenticated if we take status.cgi for that (with navbarsearch=true), but there needs to be a mechanisms to disallow user manipulations on that.
furthermore, a live search is an asynchronous http xml request, so it will stress browser and server if being used (would be good for the refresh though!), so considering a small search.cgi is better than a complex structure like status.cgi

maybe you'll create a feature request for a new "search.cgi" introducing livesearch (you've deleted jquery recently in git btw) and one for fixing the search all over (the navbarsearch=true indicator in status.cgi is really good, as the mechanism showing host_name OR host_filter via regexp on the cgi works rather perfect. only the section of "what did the user search" is a mess.

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-04-28 09:49:33 +00:00

jquery.js is still in the tree.

And it could be included in status.cgi. If it is a search request then it get processed and returned otherwise "the normal way" gets processed. Because in the beginnig you have to load the same data anyway. And yes it will stress the the server. In this case a config option would do the trick.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-04-28 20:32:56 +00:00

  • Target Version changed from 1.4 to 1.5

well this is a too big issue now within our 2 week feature freeze policy. i'll postpone to 1.5

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-06-16 17:03:12 +00:00

we could just say, that each input is to be marked as regex and therefore feed into the filter logic?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-07-12 18:48:39 +00:00

  • Target Version changed from 1.5 to 1.6

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-10-17 13:07:28 +00:00

  • Target Version changed from 1.6 to 1.7

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-11-05 16:20:23 +00:00

  • Status changed from Assigned to Feedback
  • Target Version changed from 1.7 to 1.6
  • Done % changed from 50 to 90

this lasted long enough.

now in dev/cgis

please test properly.

Commit message:

classic ui: fixed search not returning all results, only first match (without * at the end) #844

refs: #844

Done a rewrite of the search part. If user is searching something and a host or service
matches, then the status entry gets marked as a match. When statusdata gets displayed
it only shows the matching one's. Added "search_matched" to both statusdata struct.

Also added new get var "search_string". 

The filter uses regular expressions. Following items get checked against search string:

* Host
** Host Name
** Display Name
** Alias
** Address
** Address6

* Service
** Description
** Display Name
** Host Name
** combination of hostname and service description "hostname servicedescription"

If all of this fails it tries to find a hostgroup or servicegroup which has to match the
exact search string. This is still the old behavior.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-06 09:09:26 +00:00

  • File added classicui_rewritten_search_matching_all_hosts_and_services_and_groups05.png
  • File added classicui_rewritten_search_matching_all_hosts_and_services_and_groups01.png
  • File added classicui_rewritten_search_matching_all_hosts_and_services_and_groups02.png
  • File added classicui_rewritten_search_matching_all_hosts_and_services_and_groups03.png
  • File added classicui_rewritten_search_matching_all_hosts_and_services_and_groups04.png
  • File added classicui_rewritten_search_matching_all_hosts_and_services_and_groups05.png
  • Category set to 52

wow. #icinga #epicwin

just tested those, works like a charm.

but as a matter of compatibility - plugins like nagstamon are using the search to filter various things in their result view.

currently, it's

status.cgi?search_string=critical

could you please add a compatibility layer to keep the following intact?

status.cgi?navbarsearch=1&host=host_
status.cgi?navbarsearch=1&host=host_*

i (and probably others) have many bookmarks like that. i have not a problem with combining those and showing all matches for the host (if authorized), so that the compatibility would be

status.cgi?navbarsearch=1&host=host_

only showing the new behaviour. would be great if you could add that into your new implementation too in order to keep support questions low.

below some screenshots on how it looks over here

classicui_rewritten_search_matching_all_hosts_and_services_and_groups01.png

classicui_rewritten_search_matching_all_hosts_and_services_and_groups02.png

classicui_rewritten_search_matching_all_hosts_and_services_and_groups03.png

classicui_rewritten_search_matching_all_hosts_and_services_and_groups04.png

classicui_rewritten_search_matching_all_hosts_and_services_and_groups05.png

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-06 09:09:37 +00:00

  • File deleted classicui_rewritten_search_matching_all_hosts_and_services_and_groups05.png

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-11-06 19:15:27 +00:00

added old method again.

in current 'dev/cgis'

can you test if this works as expected?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-07 08:15:49 +00:00

  • File added classicui_rewritten_search_compatibility01.png
  • File added classicui_rewritten_search_compatibility02.png

works as expected. thanks.

could we rename the topic to something like

"rewrite search to not only match hosts, but all hosts/services/groups and their attributes"

and change that in Changelog too? i think ppl don't recognize this issue as it is meant to be. (of course everyone hates native search only looking for hosts).

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-07 08:16:14 +00:00

classicui_rewritten_search_compatibility01.png
classicui_rewritten_search_compatibility02.png

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-15 09:22:42 +00:00

tested the latest fixes and merged current r.6 into dev/cgis to get the latest release tree - working fine so far.

can we set that to 100%?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-22 12:21:10 +00:00

  • Status changed from Feedback to Resolved
  • Done % changed from 90 to 100

i consider that stable working now. thanks for fixing, resolved - finally.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-12-08 09:50:32 +00:00

  • Project changed from 19 to Core, Classic UI, IDOUtils
  • Category changed from 52 to Classic UI
  • Icinga Version set to 1
  • OS Version set to any

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant