Make this upstream?

[tomascohen]

Hi, I'm all in to make this into Koha upstream this cycle. Can we talk about it?

[nugged]

Let's do that. I will talk tomorrow (EEST work daytime Wednesday) with @EreMaijala to figure out who's part where can be.

[EreMaijala]

@tomascohen That'd be great. I think some of the functionality may already be possible with x-koha-embed, but a lot isn't. However, I would use the opportunity to streamline some of the code. Particularly the biblio/item availability checks are quite complex. E.g. in most cases it would be enough to get one reason for something being unavailable, but currently you usually get all the ones that apply.

I think it might make sense to document what we really need and is missing from Koha at the moment, then see what's the most sensible way to accomplish that.

[tomascohen]

Yeah, my interest is particularly on adding such classes for checkoutability and holadability and routes for that.

[EreMaijala]

I think that one way to proceed would be to describe what endpoints there would be and what they would return. For our use case it's important to be able to retrieve all relevant information for a biblio or an item with a single request. Otherwise there's easily too much overhead on each end.

Most of the logic around availability information is indeed about checkoutability and holadability, but item statuses are important as well, and there can be several relevant ones at the same time (e.g. "Checked out" and "On hold").

Have you already thought about possible routes or would you like me to draft something for a base?

[minusdavid]

I'd love to get involved with this work. I'm doing some work on discovery, and need availability/holdability endpoints as well.

Overall, I think it makes sense to get the same information that you'd see on the OPAC, since I imagine that's a/the typical use case.

[minusdavid]

I had feared that I'd have to write my own plugin endpoints, but I think I'll try koha-plugin-rest-di out for now!

I'd also love to hear more about your experience with performance @EreMaijala . I was thinking you'd want to get as much information as possible from 1 API call to reduce overhead for sure, although I suppose there's a cost/benefit balance when there's many items.

[minusdavid]

Overall I'm liking /api/v1/contrib/kohasuomi/availability/biblios/{biblio_id}/search although I find it interesting that it returns multiple unavailabilities when the OPAC only shows 1.

For instance, the API will say that it has "Item::CheckedOut" (with the due date but not the borrower) and "Item::Held", but the OPAC only says "Checked out".

It looks like the staff interface shows both "Checked out to " and "There is an item level hold on this item".

Actually, it seems that the system preference "OPACShowHoldQueueDetails" allows hold details to be shown on the OPAC as well...

There are so many system preferences to potentially take into account...

[EreMaijala]

@minusdavid You're right in that there's always the need to find the balance between fetching enough information but not too much. I think that for most purposes the current availability implementation is a bit overkill. Then again returning all the reasons why something isn't available makes it possible for the caller to decide the order of importance for the reasons. That's why I believe it's useful if the caller can indicate how much information to return (e.g. the patron information endpoint already does some of that).

It's also a balancing act trying to decide which sysprefs to take into account. On one hand it's nice that you can control with Koha prefs what's shows in the discovery interface, on the other hand often it makes sense to make this decision in the DI preferences, particularly since you could have several different interfaces for different audiences.

[minusdavid]

I'm happy to follow your lead on this one, especially since you folk have been running this in production for so long!

[minusdavid]

Could I get your comment on #22 ?

Overall, api/v1/contrib/kohasuomi/availability/biblios/{biblio_id}/hold is also looking great for determining holdability!

[EreMaijala]

I'm happy to follow your lead on this one, especially since you folk have been running this in production for so long!

That's still not proof of things being polished in any way. :) The current endpoints were created long time ago, and when I built this plugin I just copy-pasted most of the existing code here. They work fine, also in production, but some optimization for different use cases would be nice.

[minusdavid]

Well, I'm hoping to start using these endpoints, so happy to provide feedback on things. I need to leave work for the day, but keen to chat a bit more about how these endpoints get used currently.

[EreMaijala]

Thanks, feedback and suggestions are always appreciated!

[minusdavid]

By the way, what's the best way to provide feedback/suggestions? On here or by email or something else?

[EreMaijala]

Here, if it's okay to keep the discussion public and available for future generations as well. :) Otherwise email.