Bug 7012 - Limit to available does not exclude in-transit items
Summary: Limit to available does not exclude in-transit items
Status: BLOCKED
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching - Elasticsearch (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Jonathan Druart
QA Contact: Bugs List
URL:
Keywords:
Depends on: 37334 25375
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-12 13:43 UTC by Nicole C. Engard
Modified: 2024-11-13 17:10 UTC (History)
17 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2011-10-12 13:43:46 UTC
When I limit to only available items in the OPAC it doesn't appear to be limiting anymore.
Comment 1 Nicole C. Engard 2011-10-12 14:17:45 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
Comment 2 Owen Leonard 2011-10-12 14:44:48 UTC
(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.
Comment 3 Karl Holten 2015-12-10 20:50:54 UTC
(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.
Comment 4 Daniel Gaghan 2019-04-09 15:49:47 UTC
We at PCCLD are seeing this error on 18.05 and it's causing some headaches amongst our staff.
Comment 5 Daniel Gaghan 2019-12-02 18:30:31 UTC
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?
Comment 6 Carolyn Hughesman 2022-11-28 17:27:34 UTC
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.
Comment 7 Katrin Fischer 2022-11-28 20:16:56 UTC
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.
Comment 8 Benjamin Daeuber 2022-11-30 14:00:05 UTC
(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.
Comment 9 Katrin Fischer 2022-11-30 18:54:23 UTC
(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.
Comment 10 Katrin Fischer 2022-11-30 18:56:45 UTC
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.
Comment 11 Christopher Brannon 2023-03-22 19:11:13 UTC
I am hoping this feature will get some much needed attention.  It has been unreliable for way too long.
Comment 12 Keith Dembek 2024-06-18 17:30:20 UTC
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.
Comment 13 Christopher Brannon 2024-06-18 23:35:04 UTC
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.
Comment 14 Martin Renvoize (ashimema) 2024-10-15 08:58:30 UTC
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.
Comment 15 Jonathan Druart 2024-10-15 10:38:23 UTC
The availability is in the ES's index already (bug 25375), we only need to adjust the "available" index.
Comment 16 Jonathan Druart 2024-10-15 10:39:30 UTC
I can have a look at this, for ES only however.
Comment 17 Jonathan Druart 2024-10-15 10:40:32 UTC
We can deal with in-transit, but what about withdrawn, lost, damaged (see bug 25375 comment 47).
Comment 18 Jonathan Druart 2024-10-15 10:44:12 UTC
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.
Comment 19 David Cook 2024-10-21 22:50:01 UTC
(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.
Comment 20 David Cook 2024-10-21 23:00:18 UTC
(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.