| Summary: | Limit to available does not exclude in-transit items | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Nicole C. Engard <nengard> |
| Component: | Searching - Elasticsearch | Assignee: | Jonathan Druart <jonathan.druart> |
| Status: | BLOCKED --- | QA Contact: | Bugs List <koha-bugs> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | acampbell, bdaeuber, blawlor, cbrannon, chughesman, daniel.gaghan, dcook, emily.lamancusa, hattara, jdemuth, jonathan.druart, kdembek, kholten, martin.renvoize, mspinney, olsson.nic, pedro.amorim |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9253 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5463 |
||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Bug Depends on: | 37334, 25375 | ||
| Bug Blocks: | |||
|
Description
Nicole C. Engard
2011-10-12 13:43:46 UTC
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. We would really like this change as well. Staff are seeing items available in the search results, going to the shelves, and not finding the item since it's either in transit or on the hold shelf. I've informed them to check the actual bib record or check the record in Aspen but it would make things even easier for them if they could just scan the search results. This seems to be a bug that has been outstanding for a long time, and is a basic function of catalog searching. I don't like being a nag, but this seems rather important, and necessary for both staff and patrons. I think that the challenge here is that whilst this sounds simple, it's actually rather involved. In my understanding, this is one of the parts of detail that we apply post-searching, so the information isn't available inside the indexes as it stands. It should be doable work, but it's not a quick job and thus is always at the bottom of developers' piles when there's more lucrative work in the queue :(. I'll try to see if I can carve out some time, but I'm also in the same boat of a whole queue of paid work with strict deadlines on my plate right now. This is the sort of thing I'd love to see the foundation sponsor once it's setup.. we all agree it's a bug and should be fixed, we just can't easily prioritise it individually when we have bills of our own to pay. The availability is in the ES's index already (bug 25375), we only need to adjust the "available" index. I can have a look at this, for ES only however. We can deal with in-transit, but what about withdrawn, lost, damaged (see bug 25375 comment 47). Remote branch pushed, there is a very simple patch that addresses this, but on top of another big work, bug 37334. https://gitlab.com/joubu/Koha/-/commits/bug_7012 Marking as BLOCKED but the remote branch can be tested. (In reply to Martin Renvoize (ashimema) from comment #14) > This is the sort of thing I'd love to see the foundation sponsor once it's > setup.. we all agree it's a bug and should be fixed, we just can't easily > prioritise it individually when we have bills of our own to pay. I think one of the problems here is also agreeing on a design. Joubu linked me to bug 7012 from bug 38181 as I point out the performance problems with calculating item status using the ORM item by item at search time. Bug 37334 will suffer from the same problem as bug 38181. Off the top of my head, we need to be storing the status in the database and indexing that. (In reply to Katrin Fischer from comment #9) > Elasticsearch and Zebra both index MARC. So bibliographic records and items. Technically, I don't think that's 100% true. We've made the search engines MARC-focused with Koha, but they don't have to be. We process MARC records and turn them into JSON document for Elasticsearch. We pass MARCXML records to zebraidx for Zebra, but technically we should be able to wrap the MARCXML with our own "Koha XML" and inject whatever we want. I don't think that this was possible with GRS-1 indexing but it should be with the DOM indexing. But the tricky part isn't the indexing. It's managing the state in the database across a huge range of Perl functions. |