http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 --- Comment #1 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 28525 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28525&action=edit Bug 12323 - Acquisitions search results fixed in order of biblionumber The acquisitions search is exhibiting the same behavior as bug 11410. Results are always fixed in order of biblionumber, among other possible issues ( including the ampersand issue ). Test Plan: 1) From an open basket, choose "Add to basket" 2) Run a search for "From an existing record" 3) Note the "View MARC" URLs are fixed in order of biblionumber 4) Apply this patch 5) Refresh the page 6) Note the results are no longer fixed in order of biblionumber -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #3 from Christopher Brannon <cbrannon@cdalibrary.org> --- The results look much better, but when I do a search, the number of results vary. For example, in our catalog: "benny and joon" produce 1404 results. "benny & joon" produce 1525 results. As far as the results go, I am very pleased, but just need to make sure the number of results isn't a sign of another problem. Christopher -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to Christopher Brannon from comment #3)

The results look much better, but when I do a search, the number of results vary. For example, in our catalog:

"benny and joon" produce 1404 results.

"benny & joon" produce 1525 results.

As far as the results go, I am very pleased, but just need to make sure the number of results isn't a sign of another problem.

Christopher

I just tried using & and && in the query parser as boolean operators and they don't work either (although doing an advanced boolean search while using QP will show && as a boolean operator, but that points to problems with the QueryParser). I would recommend (kw:benny) and (kw:joon), or kw:"benny" and kw:"joon". Either of those should yield the same results. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- Created attachment 28972 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28972&action=edit Bug 12323 [SIGNED OFF] - Acquisitions search results fixed in order of biblionumber The acquisitions search is exhibiting the same behavior as bug 11410. Results are always fixed in order of biblionumber, among other possible issues ( including the ampersand issue ). Test Plan: 1) From an open basket, choose "Add to basket" 2) Run a search for "From an existing record" 3) Note the "View MARC" URLs are fixed in order of biblionumber 4) Apply this patch 5) Refresh the page 6) Note the results are no longer fixed in order of biblionumber Signed-off-by: David Cook <dcook@prosentient.com.au> Works as described. I think the code could be a bit tidier, but I think it makes sense to use buildQuery here. It'll detect CCL, CQL, and PQF queries, as well as parsing a regular keyword search as one would expect when searching the catalogue. It also has the added bonus of performing relevance searching, so long as QueryAutoTruncation is off, and so long as library staff avoid using the "*" truncation wildcard (see bug 12430). While there are simpler ways to fix this acq bug, I think this was probably the best move, as it adds a bit to the consistency of what librarians can expect from their search results. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Kyle M Hall from comment #2)

Note: UseQueryParser needs to be disabled.

I have tested this and with QueryParser set to "Try" my search results are NOT sorted by biblionumber. With QueryParser set to "Do not try" the results are sorted. Is this the expected behaviour? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #7)

(In reply to Kyle M Hall from comment #2)

...

Note: UseQueryParser needs to be disabled.

I have tested this and with QueryParser set to "Try" my search results are NOT sorted by biblionumber.

With QueryParser set to "Do not try" the results are sorted.

Is this the expected behaviour?

This should be the expected behaviour, as the QueryParser doesn't rely on buildQuery for performing relevance searching (relevance searching is built into the QP config). So the QP will have the same results before and after this patch, while non-QP will be very different (i.e. relevance only added when using this patch). Ideally, we would just use QueryParser here (as buildQuery isn't very good at parsing free-form searches), but until we transition more completely to QueryParser, I suppose this makes sense. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #10)

I've retested this:

I searched for an existing record to create an order line from in acquisitions. My search term was DE-576, which is the MarcOrgCode that appears in most of my records.

Without patch, plain master: - QueryParser: Try - Results ARE sorted by biblionumber

- QueryParser: Don't try - Results ARE sorted by biblionumber

With patch: - Query parser: Try - Results ARE sorted by bilbionumber

- Query parser: Don't try - Results ARE sorted by bilbionumber

... I am confused now. Maybe some other setting plays a role here?

When QueryParser is set to "Don't try", "QueryAutoTruncation" will turn off relevance searching if it's set to "automatically". However, relevance searching shouldn't be affected by "QueryAutoTruncation" when QueryParser is set to "Try". I suspect...that your result might be coincidence, Katrin. With the QueryParser, it applies relevance to your search query as well as adding relevance subqueries for title keyword and title exact. Since you're using "DE-576" as your search term, you'll probably get no hits for title keyword or title exact, so the relevance "bumps" become irrelevant. Then, for the results you do get, I suspect that "DE-576" would only show up once in a record so each record retrieved would have the same relevance score. Since the search term is quite specific, Zebra will probably only return records with that exact search term so you won't get anything "less relevant". tl;dr Katrin, could you try again but using a more vague search term? Something that is likely to appear in a lot of different records with different frequency? Probably a noun. I often like to use "health" or "test" as we have a lot of medical records. I might be wrong, but...I think that's the most logical explanation for your results. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |12742 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com Status|Passed QA |Pushed to Master --- Comment #14 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Patch pushed to master. Thanks Kyle! -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtj@kohaaloha.com Keywords| |rel_3_16_candidate --- Comment #16 from Mason James <mtj@kohaaloha.com> --- Pushed to 3.16.x, will be in 3.16.8 -- You are receiving this mail because: You are watching all bug changes.