Bug 1964 - Facetted searching should change search box
Summary: Facetted searching should change search box
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: master
Hardware: PC All
: P3 normal (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL: http://opacdemo.koha.org/cgi-bin/koha...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-21 05:12 UTC by Nicole C. Engard
Modified: 2013-02-22 12:52 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
first search (66.21 KB, image/png)
2008-03-21 05:45 UTC, Chris Cormack
Details
second search (72.64 KB, image/png)
2008-03-21 05:45 UTC, Chris Cormack
Details
search box and actual search run - do not match. (31.86 KB, image/png)
2009-06-26 15:01 UTC, Chris Cormack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:36:39 UTC


---- Reported by nengard@gmail.com 2008-03-21 05:12:29 ----

On this results page - in the search box it says call (my search term) if I click on a facet then it stays "call", but on the top left it says "callbranch:MPL" and the URL changes to http://opacdemo.koha.org/cgi-bin/koha/opac-search.pl?q=call&limit=branch:MPL 

If I copy "callbranch:MPL" and put that in the search box it doesn't work - if I put a space after "call" it still doesn't work. It would be nice - as a librarian - to be able to use facet terms in my searching instead of going to an advanced search page - if possible.  Also it would be better if the terms in the search box changed in addition to showing the search on the top left.


 <kados> nengard: what you're describing should already be posible
 <kados> the call is junk, I've no idea how it's getting in there
 * kados investigates
 <nengard> :)
 <kados> oh ... it's the search term itself
 <kados> duh
 <nengard> hehe
 <nengard> kados - so what does this mean? it's a bug? or is it an enhancement request?
 <kados> nengard: it's a bug with the search syntax, file it under Searching



---- Additional Comments From nengard@gmail.com 2008-03-21 05:45:14 ----

Created an attachment
first search





---- Additional Comments From nengard@gmail.com 2008-03-21 05:45:37 ----

Created an attachment
second search





---- Additional Comments From nengard@gmail.com 2009-06-26 15:00:57 ----

This is still an issue and one that was pointed out in the training session I did today.



---- Additional Comments From nengard@gmail.com 2009-06-26 15:01:31 ----

Created an attachment
search box and actual search run - do not match.





---- Additional Comments From joe.atzberger@liblime.com 2009-07-08 17:18:35 ----

This basically comes down to defining, documenting and implementing a valid search syntax.  Right now, we don't have a consistent one.  It has to deal with boolean relationships, facets, "phrase matching", Unicode input, all zebra indexes, tags, etc.  The scope is actually quite large. 



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:36 UTC  ---

This bug was previously known as _bug_ 1964 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=1964
Imported an attachment (id=440)
Imported an attachment (id=441)
Imported an attachment (id=442)

Actual time not defined. Setting to 0.0
CC member bchurch@ptfs.com does not have an account here
CC member joe.atzberger@liblime.com does not have an account here
The original submitter of attachment 440 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 441 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 442 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.