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...