Closed minusdavid closed 11 months ago
This seems to be fetched correctly for /api/v1/contrib/kohasuomi/availability/biblios/{biblio_id}/search though...
Just noticed for api/v1/contrib/kohasuomi/availability/biblios/{biblio_id}/hold that it does show a hold_queue_length of 1 at the item level... so that's weird
It's not very obvious, but availability/biblios/{biblio_id}/hold
only considers the given patron, while availability/biblios/{biblio_id}/search
returns the general status.
I noticed that but I don't really understand why that is.
I would think that you'd use availability/biblios/{biblio_id}/search
on a search result/item detail page, and then availability/biblios/{biblio_id}/hold
on a holds page, but it seems like you'd need both for a holds page?
Or do you do holds from the search results page anyway?
We use both, search
for general availability information and hold
for checking if the current user can place a hold and the possible pick up locations. See KohaRest::getPickUpLocations for an example.
I think I understand. You can't use hold
to replicate the Koha OPAC reserve page but it works fairly well overall.
I've incorporated the search
into my frontend and I'm just about to try out the hold
I think I see the utility of having the hold_queue_length return the patron's number of holds on an item, since it looks like the Koha API doesn't prevent you from putting multiple holds on the same item...
The thing is, we don't really use the hold queue length information here, but just check if hold is available, i.e. unavailabilities should indicate the reason(s) when a hold can't be placed. But obviously the queue length should at least be consistent, so let's continue in #25.
Fixed as part of #25.
The hold_queue_length should be the equivalent of the "Number of holds" on the OPAC or the counter of "Holds" from /cgi-bin/koha/reserve/request.pl on the staff interface