https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674
--- Comment #2 from Phan Quang Minh <[email protected]> --- Two further findings from the same interoperability testing, both in core rather than in the plugin. I am adding them here rather than opening separate bugs because the first is the same defect already reported against the plugin, and the second now has its own bug (see below). 1. Agency identifiers are hardcoded in core too Koha/ILL/ISO18626/Request.pm, in the supplyingAgencyMessage payload: agencyIdValue => 'sup_agency_value', # line 352 agencyIdValue => 'req_agency_value', # line 359 This is the same defect reported against the plugin at https://github.com/openfifth/koha-ill-iso18626/issues/8, but here it is in core, on the supplying side added by bug 37762. The consequence on the receiving end is concrete: the requesting agency cannot tell which library the message came from. In our case the message arrived with supplyingAgencyId = "sup_agency_value", which matches no configured partner, so there is no way to verify the sender. That matters more for supplyingAgencyMessage than for other message types, because ISO 18626 puts requestingAgencyAuthentication in request and requestingAgencyMessage but has no equivalent element for supplyingAgencyMessage — the agency identifier is the only thing in the message that says who sent it. The identifier presumably wants to come from the library's own configuration, alongside whatever bug 37762 already stores per requesting agency in iso18626_requesting_agencies. 2. Element order is random Filed separately as bug 43694, because it is a different defect, it sits in Koha::REST::V1::to_xml rather than in the ILL code, and it is not deterministic: Perl randomises hash key order, so the same payload serialises to a different element order on each run, while the ISO 18626 schema uses xs:sequence. Worth noting for this bug: the envelope problem reported here and the ordering problem are both in Koha::REST::V1, and fixing either one alone still leaves Koha unable to exchange messages with a conformant implementation. It may be worth treating them as one piece of work. For what it is worth, we now have both directions working against Koha 26.05.02 — Koha borrowing from us and us borrowing from Koha — but only with a compatibility shim on our side that adds the missing envelope, reorders elements into schema order, and falls back to matching the transaction by requestingAgencyRequestId because the agency identifier is not usable. I would rather delete that shim than keep it, and am happy to test any patch against a conformant implementation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
