Currently Koha's ILL module allows for the Koha library to be a borrowing library/institution but does not currently allow for the Koha library to be a supplying agency/lending library.
Interested! I still need to have a conversation with a library about this, but I think they're interested in using Koha to manually track ILLs which they process via other external systems/processes. I'm going to look for confirmation on that though...
Adding the phrase "ISO 18626" to this bug, so that it's searchable. While the ISO standard wouldn't be a requirement to move ahead with this work, it would be a very useful addition here.
I started replying to David's comment on bug 19605 but I think it's better placed here because of ISO 18626. (In reply to David Cook from comment #45) > I'm intrigued by the idea of an ISO 18626 ILL Koha plugin, although not sure > if it would be that straightforward or if backends like Rapido and ReShare > would need their own plugins. Waiting to hear back libraries about > workflows... As I understand it: 1) Services like Rapido or ReShare would require their own plugins, yes. 2) ISO 18626 would ideally be implemented in core Koha in bug 37762. To start with, ISO 18626 defines 6 messages: https://illtransactions.org/schemas/ISO-18626-2021-2.xsd <xs:element ref="request"/> <xs:element ref="requestConfirmation"/> <xs:element ref="supplyingAgencyMessage"/> <xs:element ref="supplyingAgencyMessageConfirmation"/> <xs:element ref="requestingAgencyMessage"/> <xs:element ref="requestingAgencyMessageConfirmation"/> Some thoughts: We already have a POST /ill/requests endpoint in Koha. We would need to make it ISO 18626 compliant. And add everything else. I'm aware that https://wiki.koha-community.org/wiki/ISO18626_RFC describes a plugin, not core. But that RFC defines the plugin as a whole module, not a 'backend' plugin. We could have backends optionally have a new 'ILL_supplier' capability. If the backend has this capability, it tells Koha it is able to act as a supplier and the logic may follow that. These are just some ideas, happy to discuss, happy to be proven wrong.
Can you explain your thoughts a bit more on a core ISO18626 API and the relationship to the backend? Right now the backends implement the "connection" to the ILL system and how things get "translated" for Koha. How would a native ISO API fit?
Created attachment 175323 [details] Simple use case Had a chat with Martin, trying to come up with a light spec to get some work started here at some point. What I'm currently thinking would be core ISO18626 API to allow Koha to act as a supplying agency using the ISO18626 standard. The picture is a minimalist use case to start with. I don't know yet how backends fit here. Dev plan: - New illrequests database column `category` enum('send','received'). - All existing ILL requests become "Sent Requests". - New requests coming in from the ISO18626 interface are created as 'received'. Prerequisites: - The requesting agency needs to already exist on the supplying Koha as an ILL partner (as the request will be linked to that ILL partner). - New 'borrower' database columns to store required requesting agency details (credentials, URLs). Only shown if ILLModule enabled. This is just brainstorming and open to discussion / input. I'd love to hear back from you.
Created attachment 175324 [details] UI ILL requests table with tabs mock-up
This is sounding pretty good although that UI is having that common Koha problem of being way too wide I think...
Added the branch info here to the bug and updated it to be known that we're working on this. I've dropped the PoC UI screenshot as that is no longer relevant. We've decided to build a new vuejs module for supplying side ILL specifically, while keeping the current 'ILL requests' as is. All the ISO18626 specification is added to the swagger schemas, which allows for validation of all inbound/outbound ISO18626 messages. This is still a work in progress but the plan is to have it in a 'ready to test' stage in the near future.