search

NatLibFi / koha-plugin-rest-di

REST API plugin for Koha to provide additional functionality for discovery interfaces such as VuFind
GNU General Public License v3.0
9 stars 9 forks source link

hold_queue_length at bib-level always 0 for /api/v1/contrib/kohasuomi/availability/biblios/{biblio_id}/hold #25

Closed minusdavid closed 1 year ago

minusdavid commented 1 year ago

The hold_queue_length is 0 at the record-level even when there is a record-level hold already in place for that patron.

The hold_queue_length for the items is correct, but not at the record/bib-level.

EreMaijala commented 1 year ago

Okay, uh, we have indeed a few issues here. First of all, at item level hold_queue_length is always for all holds, while at biblio level it's only for the current patron and not even that if ignore_patron_holds is specified. Now I need to dig a bit deeper to find out why exactly do we have it this way. It's quite possible that part of it is an unexpected side-effect of ignore_patron_holds, but I'm not sure why we'd only count the holds of the given patron when calculating queue length.

minusdavid commented 1 year ago

At the biblio level, I wasn't even getting the holds for the current patron though :/

EreMaijala commented 1 year ago

@minusdavid I'm having a bit trouble deciding what to do with this. The current situation is obviously wrong, but I'm not sure if specifying patron_id or setting ignore_patron_holds should affect hold_queue_length. What would you expect?

minusdavid commented 1 year ago

Sorry, @EreMaijala . I just noticed the email notification now.

I figure hold_queue_length should show the same thing as Koha. So at the bib level it shows all holds, and then at the item level it shows the number of holds for that particular item.

For ignore_patron_holds, as per the API description, that should just affect whether or not something is holdable?