When I limit to only available items in the OPAC it doesn't appear to be limiting anymore.
Actually it does work, but 'in transit' is considered 'available' why is that? should it be? I would think available is on the shelf. Nicole
(In reply to comment #1) > Actually it does work, but 'in transit' is considered 'available' why is that? Especially since the staff client considers "in transit" to be /unavailable/ with regard to placing holds from the search results page.
(In reply to Owen Leonard from comment #2) > (In reply to comment #1) > > Actually it does work, but 'in transit' is considered 'available' why is that? > > Especially since the staff client considers "in transit" to be /unavailable/ > with regard to placing holds from the search results page. This is the main reason we reported it as a bug- so that students at our univerities wouldn't get confused when they tried either placing a hold or finding the material on the shelves and it wasn't available.
We at PCCLD are seeing this error on 18.05 and it's causing some headaches amongst our staff.
It looks like this issue is also listing items that are on hold as available in addition to in-transit. Does anyone know if this was a recent change or did it originally include on hold items?
Hoping to revive this bug. On the search results page in the staff interface, items are still counted as available both when they are in transit and sitting on the holds shelf. This is confusing to our staff. Items should only be listed as available if they are physically on the shelf.
Just to explain why this is not as easy of a fix as it might sound: The information if an item is on hold or in transfer is only found in the reserves table right now. it's not part of the item records. In order to be able to exclude these from the availability search, the information needs to be made available to the search engines. This means: The information needs to be added to the records, for example into otherwise unused MARC fields at the time of indexing. And every time a hold changed status, we'd need to automatically trigger reindexing of the record. At the moment the filter only looks at information in the item record already.
(In reply to Katrin Fischer from comment #7) > At the moment the filter only looks at information in the item record > already. Is performance the reason Koha can't also check the reserves table? Is this something that can (or has?) been addressed with elastic search? We're willing to pitch in funds if a solution is possible.
(In reply to Benjamin Daeuber from comment #8) > (In reply to Katrin Fischer from comment #7) > > > At the moment the filter only looks at information in the item record > > already. > > Is performance the reason Koha can't also check the reserves table? Is this > something that can (or has?) been addressed with elastic search? > > We're willing to pitch in funds if a solution is possible. Elasticsearch and Zebra both index MARC. So bibliographic records and items. Information from reserves is not part of the data that we push to the search engines for indexing at the moment. So we would need to do that AND then make sure everytime a hold changes in any way, the record gets reindexed with updated information. I was just trying to explain why this isn't just about changing the search query used. The data is currently not available for searching in the first place.
you could change to "Seeking cosponsors" if you wanted - also people from bug 5463 could be interested. It's mostly the same issue. Hm, actually it depends. transfers can also be in branchtransfers... so maybe we'd need both info from reserves and branchtransfers.
I am hoping this feature will get some much needed attention. It has been unreliable for way too long.