I cannot reproduce this problem in version 16.05 or in the master branch. It seems likely that this is a data or configuration issue. I suggest bringing it to the Koha mailing list to see if anyone there has suggestions. Lowering severity as it is not confirmed. I get this error with 16.05 and a Unimarc catalog. Is your catalog Unimarc ou MARC21? Wrong diagnostic... In fact, I get this error when I limit an authority search by clicking ong 'Limit to currently available items'. Is it what you do Erjon? Yes, that is correct. Any known workarounds? Created attachment 55968 [details] [review] Bug 17278: Use available limit when requesting zebra when ccl query is used When a ccl query is used, the buildQuery subroutine does not handle the available limit (not an index). This available limit is handle later in the subroutine. This affect the author links on the detail page for instance (an=xx). A much better solution would be to keep an 'available' zebra index up-to-date. Test plan: (OPAC or staff interface, it does not matter) - Launch a search, click on a result and then on an author link to launch another query (an:xx) - Limit to available items without the 'facet' => Without this patch you won't get any results => With this patch applied you should get relevant result (regarding the known bugs 16970, 13715, 13658, 5463, etc.) Thanks Jonathan. It's almost there. But there is still something wrong. With your patch, after limiting by availability, if you click on 'Show all items' to remove the limitation, it isn't removed. As you implement it, the limitation is in the CCL query, and so the current code don't remove what you've added to the query: and ( ( allrecords,AlwaysMatches:'' not onloan,AlwaysMatches:'') and (lost,st-numeric=0) ) Created attachment 55972 [details] [review] Bug 17278: Fix "show all items" link Then we need to remove the "available" part from the query. They are really awkward patches... Note that I do not plan to provide follow-up if these patches break things (like facets, links, etc.) when this will get pushed. I will ask for a revert instead. I think it would be better to turn off the "available" feature by default as it does not work correctly. Created attachment 56566 [details] [review] [SIGNED-OFF] Bug 17278: Use available limit when requesting zebra when ccl query is used When a ccl query is used, the buildQuery subroutine does not handle the available limit (not an index). This available limit is handle later in the subroutine. This affect the author links on the detail page for instance (an=xx). A much better solution would be to keep an 'available' zebra index up-to-date. Test plan: (OPAC or staff interface, it does not matter) - Launch a search, click on a result and then on an author link to launch another query (an:xx) - Limit to available items without the 'facet' => Without this patch you won't get any results => With this patch applied you should get relevant result (regarding the known bugs 16970, 13715, 13658, 5463, etc.) Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Created attachment 56567 [details] [review] [SIGNED-OFF] Bug 17278: Fix "show all items" link Then we need to remove the "available" part from the query. They are really awkward patches... Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Created attachment 57626 [details] [review] [PASSED QA] Bug 17278: Use available limit when requesting zebra when ccl query is used When a ccl query is used, the buildQuery subroutine does not handle the available limit (not an index). This available limit is handle later in the subroutine. This affect the author links on the detail page for instance (an=xx). A much better solution would be to keep an 'available' zebra index up-to-date. Test plan: (OPAC or staff interface, it does not matter) - Launch a search, click on a result and then on an author link to launch another query (an:xx) - Limit to available items without the 'facet' => Without this patch you won't get any results => With this patch applied you should get relevant result (regarding the known bugs 16970, 13715, 13658, 5463, etc.) Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 57627 [details] [review] [PASSED QA] Bug 17278: Fix "show all items" link Then we need to remove the "available" part from the query. They are really awkward patches... Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> No regressions found, looks good. Passing QA The unit tests are failing with this patch: t/db_dependent/Search.t .. String found where operator expected at t/db_dependent/Search.t line 615, near "'an:42 and ( ( allrecords,AlwaysMatches:'' not onloan,AlwaysMatches:'" (Missing operator before ' not onloan,AlwaysMatches:'?) String found where operator expected at t/db_dependent/Search.t line 615, near "' not onloan,AlwaysMatches:'') and (lost,st-numeric=0) )'" (Missing operator before ') and (lost,st-numeric=0) )'?) syntax error at t/db_dependent/Search.t line 615, near "'an:42 and ( ( allrecords,AlwaysMatches:'' not onloan,AlwaysMatches:'" Execution of t/db_dependent/Search.t aborted due to compilation errors. # Looks like your test exited with 255 before it could output anything. t/db_dependent/Search.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 4/4 subtests Test Summary Report ------------------- t/db_dependent/Search.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 4 tests but ran 0. Files=1, Tests=0, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.08 cusr 0.00 csys = 0.10 CPU) Result: FAIL Same here: FAIL t/db_dependent/Search.t OK critic OK forbidden patterns OK git manipulation OK pod OK spelling FAIL valid t/db_dependent/Search.t had compilation errors. (Missing operator before ' not onloan,AlwaysMatches:'?) syntax error (Missing operator before ') and (lost,st-numeric=0) )'?) String found where operator expected Created attachment 57689 [details] [review] Bug 17278: Fix test compilation errors Sorry guys.. the tests passed when I ran them as part of the qa process first time around.. :( Aha... I've worked out why I cocked up.. :S I read the results from the wrong screen.. so they were the test results from another bug I was signing off.. Right.. I'll quickly re-QA this now Jonathan's done the followup! Created attachment 57710 [details] [review] Bug 17278: Use available limit when requesting zebra when ccl query is used When a ccl query is used, the buildQuery subroutine does not handle the available limit (not an index). This available limit is handle later in the subroutine. This affect the author links on the detail page for instance (an=xx). A much better solution would be to keep an 'available' zebra index up-to-date. Test plan: (OPAC or staff interface, it does not matter) - Launch a search, click on a result and then on an author link to launch another query (an:xx) - Limit to available items without the 'facet' => Without this patch you won't get any results => With this patch applied you should get relevant result (regarding the known bugs 16970, 13715, 13658, 5463, etc.) Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 57711 [details] [review] [PASSED QA] Bug 17278: Fix "show all items" link Then we need to remove the "available" part from the query. They are really awkward patches... Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 57712 [details] [review] [PASSED QA] Bug 17278: Fix test compilation errors Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Sorted.. double checked everything again.. passing qa Pushed to master for 16.11, thanks Jonathan! Pushed to 16.05.x, for 16.05.06 release Pushed to 3.22.x for 3.22.14 On 16/11/17 21:26, Andreas Roussos wrote: > Dear Devs, > > Re: Bug 17278 - Limit to available items returns 0 results > > We're running Koha 16.05.16 on Debian and are affected by this bug. > > AFAICT there were a couple of patches written for this, which were > pushed to the master/16.05.x/3.22.x branches. > > However, the commits for 16.05.x were later reverted: > http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=aed6d17ffd3aa6de49deb9dab9436ba979c35f6e > http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=4f761bb6904b127990b8d1e993ea67098f8cdb7c hi Andreas hmm, i think this revert might have been an accident :/ i'll aim to add the patchset to the next 16.05.x release (due in the next few days) thanks for spotting this cheers, Mason Pushed to 16.05.x, for 16.05.19 release |
Created attachment 55337 [details] limit search results to available opac Hi, Another problem I encountered with koha 16.05 is the function "limit to currently available" when trying to narrow down a search. If selected, the search will return 0 results, although there are many titles available. Kindly see attached image. Best regards, Erjon