https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37762 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olli-antti.kivilahti@hypern | |ova.fi --- Comment #3 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.