There seem to be inconsistencies with the search results when selecting the "Limit to records with available items" option, when we have a notice with two items if the first item is «notforloan» and the second is «notforloan» too or «withdrawn» the notice is still available. And these conditions also are showing : Case : 1- Record with first item as «notforloan» - The second is «notforloan» 2- Record with first item as «notforloan» - The second is «withdrawn» 3- Record with first item as «itemlost» - The second is «notforloan» 4- Record with first item as «itemlost» - The second is «withdrawn» 5- Record with first item «onloan» - The second is «notforloan» 6- Record with first item «onloan» - The second is «withdrawn» To reproduce: 1. Catalog a new record (record test 1) 1.1. Go to Cataloging 1.2. Click New record 1.3. Fill out the mandatory fields (000, 003, 005, 008, 040$c, 245$a, 942$c) 1.4. Click Save (No need to add an item) 1.5. Add two items, set a negative notforloan (ordered) for the two items 2. Repeat step 1, by creating a record (record test 2) with two items one negative notforloan item and the second as «withdrawn» item 3. Repeat step 1, and creating all the record in «Case» section 4. Go to the Opac and search for the created record 5. Click on «Limit to records with available items» ----> All the created items is still showing
Created attachment 170481 [details] [review] Bug 37680: inconsistencies with the search results when selecting the "Limit to records with available items" option There seem to be inconsistencies with the search results when selecting the "Limit to records with available items" option, when we have a notice with two items if the first item is «notforloan» and the second is «notforloan» too or «withdrawn» the notice is still available. And these conditions also are showing : Case : 1- Record with first item as «notforloan» - The second is «notforloan» 2- Record with first item as «notforloan» - The second is «withdrawn» 3- Record with first item as «itemlost» - The second is «notforloan» 4- Record with first item as «itemlost» - The second is «withdrawn» 5- Record with first item «onloan» - The second is «notforloan» 6- Record with first item «onloan» - The second is «withdrawn» To reproduce: 1. Catalog a new record (record test 1) 1.1. Go to Cataloging 1.2. Click New record 1.3. Fill out the mandatory fields (000, 003, 005, 008, 040$c, 245$a, 942$c) 1.4. Click Save (No need to add an item) 1.5. Add two items, set a negative notforloan (ordered) for the two items 2. Repeat step 1, by creating a record (record test 2) with two items one negative notforloan item and the second as «withdrawn» item 3. Repeat step 1, and creating all the record in «Case» section 4. Go to the Opac and search for the created record 5. Click on «Limit to records with available items» ----> All the created items is still showing 6. Apply the patch 7. Rebuild bibliographic index ./misc/search_tools/rebuild_elasticsearch.pl -d -v -r -b 8. Repeat step 4 and 5 ----> the created items is no more showing
Hi Hammat, the test plan is not totally clear as is the bug description - is this about the negative not for loan values only?
(In reply to Katrin Fischer from comment #2) > the test plan is not totally clear as is the bug description - is this about > the negative not for loan values only? Hi Katrin, This is about negative not for loan values and withdrawn values also, for example if we have a notice with two withdrawn items the notice is still available and this is not the only case if we have a notice with two items when one is checked out and the other is withdrawn or have a negative not for loan value the notice is still available
Hi Hammat, I have updated the bug description to reflect this. Hope I understood correctly!
I cannot apply the patches because I get the following errors: Error getting login cookie from browser: Cannot find default Firefox profile Configured browser: firefox3 (change with 'git config --global bz.browser <value>') Possible browsers: chromium, epiphany, firefox3, galeon, google-chrome I'm trying to do this in Chrome.
(In reply to Catrina Berka from comment #5) > I cannot apply the patches because I get the following errors: > Error getting login cookie from browser: > Cannot find default Firefox profile Hi, I think the errors that you got is not rely to the patch. Are able to apply other pathes? In my case, the patch apply without any error.
Hi Hammat, I was able to sign off on some other bugs and was able to apply those patches successfully yesterday.
Created attachment 170611 [details] Test records for the cases described I created the records for the cases, you can import these in KTD, you will need to checkout to a patron the barcodes ONLOAN1 and ONLOAN2 Search for "Bug 37680" to see the records
I think this works as intended, but not as described in the test plan - after 'limiting to available' I still see the two "ordered" items as their notforloan is negative and the code looks for positive not for loan We also need a test here for 'marc_records_to_documents' Additionally, QA tools fail tidiness: WARN Koha/SearchEngine/Elasticsearch.pm WARN tidiness The file is less tidy than before (bad/messy lines before: 313, now: 315)
(In reply to Nick Clemens (kidclamp) from comment #9) > I think this works as intended, but not as described in the test plan - > after 'limiting to available' I still see the two "ordered" items as their > notforloan is negative and the code looks for positive not for loan If the two items of a notice are "ordered", Shouldn't the notice be unavailable? after 'limiting to available' we shouldn't see them, isn't it the way it should be? in our installations we consider a notice with two ordered item as unavailable
(In reply to Hammat wele from comment #10) > (In reply to Nick Clemens (kidclamp) from comment #9) > > I think this works as intended, but not as described in the test plan - > > after 'limiting to available' I still see the two "ordered" items as their > > notforloan is negative and the code looks for positive not for loan > > If the two items of a notice are "ordered", Shouldn't the notice be > unavailable? > after 'limiting to available' we shouldn't see them, isn't it the way it > should be? in our installations we consider a notice with two ordered item > as unavailable They are available for holds, I am not sure if they should be filtered out, I would be okay either way. If you do want to fitler them the code will need an adjustment
(In reply to Nick Clemens (kidclamp) from comment #11) > (In reply to Hammat wele from comment #10) > > (In reply to Nick Clemens (kidclamp) from comment #9) > > > I think this works as intended, but not as described in the test plan - > > > after 'limiting to available' I still see the two "ordered" items as their > > > notforloan is negative and the code looks for positive not for loan > > > > If the two items of a notice are "ordered", Shouldn't the notice be > > unavailable? > > after 'limiting to available' we shouldn't see them, isn't it the way it > > should be? in our installations we consider a notice with two ordered item > > as unavailable > > They are available for holds, I am not sure if they should be filtered out, > I would be okay either way. If you do want to fitler them the code will need > an adjustment My two cents: to me, "Limit to available items" should only show items that are on the shelf ready for people to take out. If we consider "available for hold" to be available, then checked out items are also available and that doesn't make sense to me.
I think that brings us back to a discussion often had about how we define "available" Option A: Availalable means it's available for checkout. As the library circulation rules factor into this one, we cannot fully tell from what is available to Zebra if something can be checked out or not. But it would mean that it would make sense to exclude "not for loan" in general. Option B: Available means it's available for use. That would mean, the not for loan items and item types are still counted as available. I that case I would only exclude not for loan -1 by default, as they are not supposed to be in the library yet. For our academic/special libraries I think Option B would be preferable. Overall it maybe shows that finding a good default is hard and that it should be made configurable at some point?