Bugzilla – Bug 1807
':' character blocks search ; search () give odd results
Last modified: 2010-07-13 20:13:20 UTC
---- Reported by frederic@tamil.fr 2008-01-30 23:50:43 ---- SEARCH RESULT black panthers Some biblio records black : panthers Nothing ---- Additional Comments From henridamien@koha-fr.org 2008-02-01 00:43:30 ---- this is owed to the fact that no matter what is before, : or = in search boxes are considered as ccl commands : here index black contains panther. This is a bug in this case but is a feature for big search box ---- Additional Comments From frederic@tamil.fr 2008-02-01 01:30:14 ---- You're correct. Being able to send CCL queries directly to Zebra search engine is a great feature for power users. But it doesn't make sense for end user, especially in a Google-Like search box. End users search for books typing title and subtitle separated by :. A solution could be to allow : interpretation only in Advanced search when Keyword index is selected. ---- Additional Comments From henridamien@koha-fr.org 2008-03-15 15:40:56 ---- Moving criticity up Since this can cause ppl not to be confident in our search. indeed, if they copy paste a title which contains : or = then they CANNOT find it !!!! ---- Additional Comments From jmf@liblime.com 2008-05-19 13:43:48 ---- The right way to fix this would be to assign a specific subset of ccl-style parameters such as ti: for title, su: for subject, and only treat those : as assignment operators, and the rest of the ':' and '=' as keyword terms. I'll take a look at what this will take to accomplish. ---- Additional Comments From paul.poulain@biblibre.com 2008-06-05 06:04:51 ---- couldn't we request that an explicit ccl query start by "ccl:" so "title = bear" => search "title & bear" and "ccl: title=bear" => CCL search on title for value "bear" I think that a poweruser entering an equation can understand he must start it by ccl ! ---- Additional Comments From drdrulm@yahoo.com 2008-06-12 15:31:33 ---- : is nothing, try searching on: cats \ (with that slash) I get at: http://smfpl.dev.kohalibrary.com/cgi-bin/koha/opac-search.pl?q=cats\ _____________________________________________________________________ Koha error The following fatal error has occurred: Trailing \ in regex m/cats\/ at /home/liblime/kohaclone/C4/Search.pm line 1319. Apache Server version: Apache/2.2.3 Server built: Jan 31 2008 08:42:27 Koha 3.00.00.087 Koha DB 3.0000087 MySQL mysql Ver 14.12 Distrib 5.0.32, for pc-linux-gnu (x86_64) using readline 5.2 OS Linux demo01.ec2.liblime.com 2.6.16.33-xenU #2 SMP Wed Aug 15 17:27:36 SAST 2007 x86_64 GNU/Linux Perl 5.008008 ---- Additional Comments From joe.atzberger@liblime.com 2008-07-07 11:28:52 ---- Darrell -- Works for me (no crash, valid results) on Koha 3.00.00.096. --joe ---- Additional Comments From jmf@liblime.com 2008-07-07 21:26:51 ---- Fixing this properly will require a refactor of the search API, and ultimately a query parser. It might be best accomplished by 1. integrating SRU and CQL support into Index Data's Pazpar2 tool, and then using that as the front-end search API for Koha 3.2. I'm changing the Version to 3.2, and keeping it open as a blocker. ---- Additional Comments From frederic@tamil.fr 2009-03-31 08:24:10 ---- Any progress in search refactoring direction? Now, a CCL/PQF search is possible, BUT on the first result page, at the bottom, the next-previous buttons don't work at all. ---- Additional Comments From laurence.lefaucheur@biblibre.com 2009-06-19 13:26:01 ---- Problem searching terms with () Test : searching cd in title : 96 results searching (cd) in title : 8777 results, and in this case it is not possible to go to other results pages than the first. The link from page number is : /koha/catalogue/search.pl?&offset=120&sort_by=relevance, and return to advanced search page ---- Additional Comments From chris@bigballofwax.co.nz 2009-12-12 08:09:56 ---- \ works ok now () is still a problem, its caused by if ( $query =~ /(\(|\))/ ) { return ( undef, $query, $simple_query, $query_cgi, $query, $limit, $limit_cgi, $limit_desc, $stopwords_removed, 'ccl' ); } Which causes us to bail out before $query_cgi has anything assigned to it, and only the first operand used as the search. I think that not trying to handle nested queries is a valid stance for 3.2.0 That would mean that you can search on phrases containing (). I have sent a patch for that, and will send a patch fixing the : error too. Search.pm is slated for a total rewrite for 3.4.0, but I think that having it working (and losing the nested queries) is ok for 3.2.0 .. galen? ---- Additional Comments From chris@bigballofwax.co.nz 2009-12-12 08:17:27 ---- Created an attachment Patch to fix searching on () ---- Additional Comments From chris@bigballofwax.co.nz 2009-12-12 09:08:28 ---- Created an attachment Patch to stop : blocking searches ---- Additional Comments From nengard@gmail.com 2009-12-13 22:06:05 ---- *** http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2702 has been marked as a duplicate of this bug. *** ---- Additional Comments From colin.campbell@ptfs-europe.com 2010-01-28 14:36:34 ---- The second patch seems to have the unwelcome side effect of of breaking search links in opac and staff e.g. when opac-search.pl id called with q=au:Name the au:Name search fails ---- Additional Comments From colin.campbell@ptfs-europe.com 2010-02-02 09:55:07 ---- Chris Nighswonger has posted a patch referring to http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4074 to address the side effect reported in the second patch. ---- Additional Comments From chris@bigballofwax.co.nz 2010-02-11 20:20:30 ---- This has been patched to a working extent for the 3.2 release C4/Search.pm needs a total rewrite and is on the cards for 3.4 so shifting this to that. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:34 UTC --- This bug was previously known as _bug_ 1807 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=1807 Imported an attachment (id=370) Imported an attachment (id=371) Actual time not defined. Setting to 0.0 CC member jwagner@ptfs.com does not have an account here CC member laurence.lefaucheur@biblibre.com does not have an account here The original submitter of attachment 370 [details] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 371 [details] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
Question mark doesn't work either. Example, searching for the movie "Are we there yet?" retrieves no results, but the same search without the question mark "?" does.