[Bug 43674] New: ISO 18626 messages are missing the mandatory ISO18626Message envelope
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Bug ID: 43674 Summary: ISO 18626 messages are missing the mandatory ISO18626Message envelope Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs@lists.koha-community.org Reporter: minhpq@tinhvan.com QA Contact: testopia@bugs.koha-community.org CC: lisette@bywatersolutions.com, pedro.amorim@openfifth.co.uk, tomascohen@gmail.com Target Milestone: --- Koha's ISO 18626 implementation sends and expects the message type as the XML document element — <request>, <supplyingAgencyMessage>, <requestingAgencyMessage> — with no enclosing element. The schema at https://illtransactions.org/schemas/ISO-18626-v1_2.xsd defines a single root element: <xs:element name="ISO18626Message"> ... <xs:attribute name="version" use="required"/> and makes request / supplyingAgencyMessage / requestingAgencyMessage children of it. So a conformant implementation rejects Koha's messages at deserialisation, before any business logic runs, and Koha in turn rejects a conformant partner's messages. What Koha sends today: <?xml version="1.0" encoding="UTF-8"?> <request> <header> <requestingAgencyRequestId>2</requestingAgencyRequestId> ... What the schema requires: <?xml version="1.0" encoding="UTF-8"?> <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" version="1.2"> <request> <header> <requestingAgencyRequestId>2</requestingAgencyRequestId> ... Where this comes from: * Koha::REST::V1::to_xml builds the document element from the first key of the JSON structure, with no wrapper and no namespace. * Koha::REST::V1::parse_xml / _parse_node read an incoming document the same way. * Koha::REST::V1::ILL::ISO18626::message determines the message type with my ($messageType) = keys %$json, i.e. from the document element name, and Koha::ILL::ISO18626::message_types lists the six message types as though each were a root element. A side effect is that there is currently no way for a Koha instance to state which revision of ISO 18626 it speaks, since the version attribute lives on the envelope. How it was found: Testing a Koha 26.05.02 instance against a third-party ISO 18626 implementation written in .NET, generated directly from the official v1.2 XSD. Every message was rejected in both directions until a wrapping/unwrapping shim was added on the third-party side. With that shim, and with three conformance fixes applied to the koha-ill-iso18626 plugin (reported upstream at https://github.com/openfifth/koha-ill-iso18626/pull/5), the full round trip works: Koha sends request, the partner replies requestConfirmation with messageStatus OK, the partner sends supplyingAgencyMessage, vand the Koha ILL request moves to ExpectToSupply with the partner's supplyingAgencyRequestId stored. The envelope was the only remaining deviation. This has probably gone unnoticed because ISO 18626 testing so far appears to have been Koha-to-Koha — the recreation steps on bug 43003, for example, stand up two Koha instances with the same plugin on both. Two endpoints that share the same deviation understand each other perfectly; the problem only appears against an implementation built from the schema. Suggested fix: Handle the envelope in the core XML middleware — add it in to_xml on the way out, and unwrap it in the around_action hook on the way in — so every ISO 18626 route keeps working unchanged and nothing needs to know about it. Accepting both wrapped and unwrapped input for a transition period would avoid breaking anyone mid-upgrade. Related: bug 37762 (supplying agency workflows, where the core ISO 18626 handling was added) and bug 41091 (ISO18626 for borrowing). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41091, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37762 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Version|26.05 |Main --- Comment #1 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Thank you for this Phan, I'm bumping the bug severity a bit as this is an important required fix. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43694 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #2 from Phan Quang Minh <minhpq@tinhvan.com> --- 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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #3 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Created attachment 207088 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207088&action=edit Bug 43674: Wrap ISO 18626 messages in the ISO18626Message envelope ISO 18626 requires every message to be wrapped in an ISO18626Message element, in the ISO 18626 namespace, with a version attribute. Koha sent and expected the bare message, so schema-conformant partners rejected it. Koha now wraps outgoing messages and unwraps incoming ones. Unwrapped messages are still accepted. Test plan: 1) Apply patch and restart_all 2) Enable the ILLModule system preference 3) Run: curl -s -X POST http://localhost:8081/api/v1/public/ill/iso18626 \ -H "Content-Type: application/xml" \ -d '<ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"><request><header><requestingAgencyRequestId>1</requestingAgencyRequestId></header></request></ISO18626Message>' 4) Note the response is wrapped in <ISO18626Message ... ill:version="1.2"> (the BadlyFormedMessage errors are expected, the request above is deliberately minimal) 5) prove t/db_dependent/Koha/ILL/ISO18626.t t/db_dependent/api/v1/iso18626/request.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #4 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Created attachment 207089 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207089&action=edit Bug 43674: Wrap request.t test data in the ISO18626Message envelope The request, requestingAgencyMessage and mocked partner confirmation test data now use the ISO18626Message envelope, in the ISO 18626 namespace, instead of bare messages in a placeholder namespace. Test plan: 1) prove t/db_dependent/api/v1/iso18626/request.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #5 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Hi Phan, I've submitted patches here for the envelope issue. I've taken note of bug 43694 and plan to look into it. Again, thank you for your testing and feedback. Please open a new bug for this: (In reply to Phan Quang Minh from comment #2)
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.
-- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43694 See Also|https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43694 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43694 [Bug 43694] Koha::REST::V1::to_xml emits child elements in random order, producing schema-invalid XML -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |minhpq@tinhvan.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43695 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |pedro.amorim@openfifth.co.u |ity.org |k -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #6 from Phan Quang Minh <minhpq@tinhvan.com> --- Tested both patches on Koha 26.05.02 against a third-party ISO 18626 implementation — the .NET one that originally surfaced this bug, generated from the official v1.2 XSD. What I ran Steps 1-4 of your test plan pass. The response to the minimal request is wrapped: <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"><requestConfirmation>... and the BadlyFormedMessage errors are the expected ones for that deliberately minimal body. Backwards compatibility holds. Both of these are still accepted: - a bare <request> in the ISO 18626 namespace - a bare <request> with no namespace at all, which is what unpatched Koha sends I could not run step 5. This instance is a package install, so it has neither t/ nor the test harness. That is the only part of your plan I have not verified, which is why I am not setting the status to Signed Off — someone with ktd should do that. Third-party interoperability, which is the part I can contribute Our implementation sends and expects fully conformant messages. Before the patch it could not talk to Koha at all. After the patch: - Koha -> us: ten supplyingAgencyMessage exchanges, all accepted. The compatibility shim on our side no longer reports a missing envelope, which it did on every single message before. - us -> Koha: ten requests sent with our compatibility shim switched off entirely, so fully standard XML — envelope, correct namespace, schema element order — all ten accepted by the patched endpoint. So this patch is what lets a conformant implementation reach Koha at all. Thank you for turning it round so quickly. Two things still needed before the shim can go away Not objections to this patch, just reporting what is left, since I happen to have the only setup that can see it: 1. Timestamp format. Koha emits <timestamp>2026-09-30 10:23:41</timestamp> and <lastChange> likewise — a space instead of T, no timezone. That is not a valid xs:dateTime, and unlike element order it genuinely stops a parser: our deserialiser throws on it, and XSD validation rejects it. This is the one remaining defect that actually blocks the exchange. Already reported against the plugin at https://github.com/openfifth/koha-ill-iso18626/issues/7, but Koha/ILL/ISO18626/Request.pm has the same problem in core. 2. Agency identifiers. Core still sends supplyingAgencyId = 'sup_agency_value' and requestingAgencyId = 'req_agency_value' (Koha/ILL/ISO18626/Request.pm lines 352, 359). We cannot match an incoming supplyingAgencyMessage to a partner, so we fall back to matching on requestingAgencyRequestId alone — which means we cannot verify who sent it. See my earlier comment on this bug. Element order (bug 43694) turned out not to block us in practice — see my correction there. The XML is still schema-invalid, but our parser happens to tolerate it. Happy to re-test any further patch on the same setup. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #7 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Additional info: The ISO18626 ILL supply side module in Koha was developed using the latest schema version at the time of development: https://illtransactions.org/schemas/ISO-18626-2021-3.xsd Not the one you mention Phan: https://illtransactions.org/schemas/ISO-18626-v1_2.xsd -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #8 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Created attachment 207105 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207105&action=edit Bug 43674: (follow-up) Declare ISO 18626 version 2021-3 Koha's ISO 18626 messages follow the 2021-3 schema, but the envelope declared version 1.2 and the controller POD cited the v1.2 XSD. Test plan: 1) Apply patch and restart_all 2) Enable the ILLModule system preference 3) Run: curl -s -X POST http://localhost:8081/api/v1/public/ill/iso18626 \ -H "Content-Type: application/xml" \ -d '<ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="2021-3"><request><header><requestingAgencyRequestId>1</requestingAgencyRequestId></header></request></ISO18626Message>' 4) Note the response is wrapped in <ISO18626Message ... ill:version="2021-3"> (the BadlyFormedMessage errors are expected, the request above is deliberately minimal) 5) prove t/db_dependent/Koha/ILL/ISO18626.t t/db_dependent/api/v1/iso18626/request.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #9 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- (In reply to Phan Quang Minh from comment #6)
1. Timestamp format. Koha emits <timestamp>2026-09-30 10:23:41</timestamp> and <lastChange> likewise — a space instead of T, no timezone. That is not a valid xs:dateTime, and unlike element order it genuinely stops a parser: our deserialiser throws on it, and XSD validation rejects it. This is the one remaining defect that actually blocks the exchange. Already reported against the plugin at https://github.com/openfifth/koha-ill-iso18626/issues/7, but Koha/ILL/ISO18626/Request.pm has the same problem in core.
2. Agency identifiers. Core still sends supplyingAgencyId = 'sup_agency_value' and requestingAgencyId = 'req_agency_value' (Koha/ILL/ISO18626/Request.pm lines 352, 359). We cannot match an incoming supplyingAgencyMessage to a partner, so we fall back to matching on requestingAgencyRequestId alone — which means we cannot verify who sent it. See my earlier comment on this bug.
Thank you Phan. Please file a bug for each of these issues. My suggestion: rescope bug 43694 to the datetime issue. File a new bug for the req_agency_value/sup_agency_value issue. Let's keep testing and discussion here about the ISO18626 envelope. Thank you. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #10 from Phan Quang Minh <minhpq@tinhvan.com> --- Thank you for pointing that out — you are right, and I should have checked which schema revision the core work targets rather than assuming. For the record, illtransactions.org currently publishes five: v1_1, v1_2, v1_3, 2021-2 (June 2022) and 2021-3 (December 2025). We built against v1_2, which is two revisions behind the one you used. That is on us and we are moving to 2021-3. I have now diffed the two. None of the three reports changes: Envelope (this bug). 2021-3 declares ISO18626Message identically, same namespace, same required version attribute, wrapping the same xs:choice of six message types. Your patch is correct against 2021-3 as well as v1_2. Element order (bug 43694). 2021-3 uses xs:sequence throughout — 68 of them — so order is still significant. The reproduction in that bug stands unchanged. Agency identifiers (bug 43695). type_agencyId still carries agencyIdType and agencyIdValue. Worth noting that 2021-3 is stricter here than v1_2 was: in type_supplyingAgencyMessageHeader both supplyingAgencyId and requestingAgencyId are mandatory, so the hardcoded values are not an optional field being filled in with a placeholder — they are required content that currently carries no information. Where the revisions do differ, and it affects us rather than you: - v1_2 has a single shared header element. 2021-3 splits it into type_requestHeader, type_requestingAgencyMessageHeader and type_supplyingAgencyMessageHeader, with different content models. Notably the supplying header has no requestingAgencyAuthentication, which matches what I said earlier about there being nothing in a supplyingAgencyMessage to authenticate the sender with — it is explicit in 2021-3. - multipleItemRequestId is mandatory in v1_2 but optional in 2021-3. We had been filling it with a copy of requestingAgencyRequestId to satisfy v1_2, which was always a bit of a fiction; under 2021-3 we can simply omit it. - confirmationHeader drops multipleItemRequestId; messageInfo loses offeredCosts, retryAfter and retryBefore to the new retryInfo; serviceInfo renames preferredFormat to itemFormat and gains preferredEdition and loanCondition; supplyingAgencyMessage gains retryInfo and shippingInfo; consortialId is new. So the remaining timestamp issue I mentioned in comment #6 is unaffected by any of this: xs:dateTime means the same thing in every revision. Noted that you have made 43694 depend on this one. That ordering makes sense to me — the envelope patch touches the same serialisation path an ordering fix would have to change. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #11 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Yes, thank you Phan. Are you able to Sign-off here when convenient? Thank you. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43701 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207088|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207089|0 |1 is obsolete| | --- Comment #12 from Phan Quang Minh <minhpq@tinhvan.com> --- Comment on attachment 207089 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207089 Bug 43674: Wrap request.t test data in the ISO18626Message envelope
From ff318d95362027ea79da9349316f8db055717f05 Mon Sep 17 00:00:00 2001 From: Pedro Amorim <pedro.amorim@openfifth.co.uk> Date: Wed, 30 Sep 2026 15:51:50 +0000 Subject: [PATCH] Bug 43674: Wrap request.t test data in the ISO18626Message envelope
The request, requestingAgencyMessage and mocked partner confirmation test data now use the ISO18626Message envelope, in the ISO 18626 namespace, instead of bare messages in a placeholder namespace.
Test plan: 1) prove t/db_dependent/api/v1/iso18626/request.t
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --- t/db_dependent/api/v1/iso18626/request.t | 248 ++++++++++++----------- 1 file changed, 132 insertions(+), 116 deletions(-)
diff --git a/t/db_dependent/api/v1/iso18626/request.t b/t/db_dependent/api/v1/iso18626/request.t index b1b21efec21..94fa7b1cbb0 100755 --- a/t/db_dependent/api/v1/iso18626/request.t +++ b/t/db_dependent/api/v1/iso18626/request.t @@ -61,19 +61,21 @@ subtest 'list() tests' => sub { my $userid = $librarian->userid;
my $requestXml = <<'XML'; - <request xmlns="https://example.com/ill/request"> - <header> - <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> - <timestamp>2023-03-15 14:30:00</timestamp> - <requestingAgencyId> - <agencyIdType>ISIL</agencyIdType> - <agencyIdValue>req_agency_value</agencyIdValue> - </requestingAgencyId> - </header> - <bibliographicInfo> - <title>This is an optional title</title> - </bibliographicInfo> - </request> + <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"> + <request> + <header> + <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> + <timestamp>2023-03-15 14:30:00</timestamp> + <requestingAgencyId> + <agencyIdType>ISIL</agencyIdType> + <agencyIdValue>req_agency_value</agencyIdValue> + </requestingAgencyId> + </header> + <bibliographicInfo> + <title>This is an optional title</title> + </bibliographicInfo> + </request> + </ISO18626Message> XML
#FIXME: This error message should be something like "Expected content-type application/xml" @@ -97,22 +99,24 @@ XML );
my $bad_auth_requestXml = <<'XML'; - <request xmlns="https://example.com/ill/request"> - <header> - <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> - <timestamp>2023-03-15 14:30:00</timestamp> - <requestingAgencyId> - <agencyIdType>ISIL</agencyIdType> - <agencyIdValue>req_agency_value</agencyIdValue> - </requestingAgencyId> - </header> - <bibliographicInfo> - <title>This is an optional title</title> - </bibliographicInfo> - <serviceInfo> - <serviceType>Copy</serviceType> - </serviceInfo> - </request> + <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"> + <request> + <header> + <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> + <timestamp>2023-03-15 14:30:00</timestamp> + <requestingAgencyId> + <agencyIdType>ISIL</agencyIdType> + <agencyIdValue>req_agency_value</agencyIdValue> + </requestingAgencyId> + </header> + <bibliographicInfo> + <title>This is an optional title</title> + </bibliographicInfo> + <serviceInfo> + <serviceType>Copy</serviceType> + </serviceInfo> + </request> + </ISO18626Message> XML
$t->post_ok( @@ -127,11 +131,13 @@ XML 'error value is authentication failed' ); my $supplyingAgencyMessageConfirmationXml = <<'XML'; - <supplyingAgencyMessageConfirmation xmlns="https://example.com/ill/request"> - <confirmationHeader> - <timestamp>2023-01-01T00:00:00Z</timestamp> - </confirmationHeader> - </supplyingAgencyMessageConfirmation> + <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"> + <supplyingAgencyMessageConfirmation> + <confirmationHeader> + <timestamp>2023-01-01T00:00:00Z</timestamp> + </confirmationHeader> + </supplyingAgencyMessageConfirmation> + </ISO18626Message> XML
my $mock_ua_response = Test::MockObject->new(); @@ -151,26 +157,28 @@ XML );
my $authenticated_requestXml = <<'XML'; - <request xmlns="https://example.com/ill/request"> - <header> - <requestingAgencyAuthentication> - <accountId>asd</accountId> - <securityCode>asds</securityCode> - </requestingAgencyAuthentication> - <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> - <timestamp>2023-03-15 14:30:00</timestamp> - <requestingAgencyId> - <agencyIdType>ISIL</agencyIdType> - <agencyIdValue>req_agency_value</agencyIdValue> - </requestingAgencyId> - </header> - <bibliographicInfo> - <title>This is an optional title</title> - </bibliographicInfo> - <serviceInfo> - <serviceType>Copy</serviceType> - </serviceInfo> - </request> + <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"> + <request> + <header> + <requestingAgencyAuthentication> + <accountId>asd</accountId> + <securityCode>asds</securityCode> + </requestingAgencyAuthentication> + <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> + <timestamp>2023-03-15 14:30:00</timestamp> + <requestingAgencyId> + <agencyIdType>ISIL</agencyIdType> + <agencyIdValue>req_agency_value</agencyIdValue> + </requestingAgencyId> + </header> + <bibliographicInfo> + <title>This is an optional title</title> + </bibliographicInfo> + <serviceInfo> + <serviceType>Copy</serviceType> + </serviceInfo> + </request> + </ISO18626Message> XML
$t->post_ok( @@ -194,7 +202,8 @@ XML . $last_request->iso18626_request_id => json => { status => 'Loaned' } )->status_is(200);
my $requestingAgencyMessagexml = ' - <requestingAgencyMessage xmlns="https://example.com/ill/request"> + <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"> + <requestingAgencyMessage> <header> <requestingAgencyAuthentication> <accountId>asd</accountId> @@ -213,7 +222,8 @@ XML </supplyingAgencyId> </header> <action>%s</action> - </requestingAgencyMessage>'; + </requestingAgencyMessage> + </ISO18626Message>';
my $invalid_action_requestingAgencyMessagexml = sprintf( $requestingAgencyMessagexml, $last_request->iso18626_request_id, 'InvalidAction' ); @@ -326,26 +336,28 @@ subtest 'send_message() tests' => sub { );
my $request_no_callback_xml = <<'XML'; - <request xmlns="https://example.com/ill/request"> - <header> - <requestingAgencyAuthentication> - <accountId>no_callback_test</accountId> - <securityCode>test_secret_1</securityCode> - </requestingAgencyAuthentication> - <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> - <timestamp>2023-03-15 14:30:00</timestamp> - <requestingAgencyId> - <agencyIdType>ISIL</agencyIdType> - <agencyIdValue>req_agency_value</agencyIdValue> - </requestingAgencyId> - </header> - <bibliographicInfo> - <title>Test request - no callback</title> - </bibliographicInfo> - <serviceInfo> - <serviceType>Copy</serviceType> - </serviceInfo> - </request> + <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"> + <request> + <header> + <requestingAgencyAuthentication> + <accountId>no_callback_test</accountId> + <securityCode>test_secret_1</securityCode> + </requestingAgencyAuthentication> + <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> + <timestamp>2023-03-15 14:30:00</timestamp> + <requestingAgencyId> + <agencyIdType>ISIL</agencyIdType> + <agencyIdValue>req_agency_value</agencyIdValue> + </requestingAgencyId> + </header> + <bibliographicInfo> + <title>Test request - no callback</title> + </bibliographicInfo> + <serviceInfo> + <serviceType>Copy</serviceType> + </serviceInfo> + </request> + </ISO18626Message> XML
$t->post_ok( @@ -389,26 +401,28 @@ XML $mock_ua_fail->mock( 'post', sub { return $mock_fail_response; } );
my $request_bad_endpoint_xml = <<'XML'; - <request xmlns="https://example.com/ill/request"> - <header> - <requestingAgencyAuthentication> - <accountId>bad_endpoint_test</accountId> - <securityCode>test_secret_2</securityCode> - </requestingAgencyAuthentication> - <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> - <timestamp>2023-03-15 14:30:00</timestamp> - <requestingAgencyId> - <agencyIdType>ISIL</agencyIdType> - <agencyIdValue>req_agency_value</agencyIdValue> - </requestingAgencyId> - </header> - <bibliographicInfo> - <title>Test request - bad endpoint</title> - </bibliographicInfo> - <serviceInfo> - <serviceType>Copy</serviceType> - </serviceInfo> - </request> + <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"> + <request> + <header> + <requestingAgencyAuthentication> + <accountId>bad_endpoint_test</accountId> + <securityCode>test_secret_2</securityCode> + </requestingAgencyAuthentication> + <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> + <timestamp>2023-03-15 14:30:00</timestamp> + <requestingAgencyId> + <agencyIdType>ISIL</agencyIdType> + <agencyIdValue>req_agency_value</agencyIdValue> + </requestingAgencyId> + </header> + <bibliographicInfo> + <title>Test request - bad endpoint</title> + </bibliographicInfo> + <serviceInfo> + <serviceType>Copy</serviceType> + </serviceInfo> + </request> + </ISO18626Message> XML
$t->post_ok( @@ -444,26 +458,28 @@ XML );
my $request_invalid_url_xml = <<'XML'; - <request xmlns="https://example.com/ill/request"> - <header> - <requestingAgencyAuthentication> - <accountId>invalid_url_test</accountId> - <securityCode>test_secret_3</securityCode> - </requestingAgencyAuthentication> - <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> - <timestamp>2023-03-15 14:30:00</timestamp> - <requestingAgencyId> - <agencyIdType>ISIL</agencyIdType> - <agencyIdValue>req_agency_value</agencyIdValue> - </requestingAgencyId> - </header> - <bibliographicInfo> - <title>Test request - invalid url</title> - </bibliographicInfo> - <serviceInfo> - <serviceType>Copy</serviceType> - </serviceInfo> - </request> + <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"> + <request> + <header> + <requestingAgencyAuthentication> + <accountId>invalid_url_test</accountId> + <securityCode>test_secret_3</securityCode> + </requestingAgencyAuthentication> + <requestingAgencyRequestId>XYZ</requestingAgencyRequestId> + <timestamp>2023-03-15 14:30:00</timestamp> + <requestingAgencyId> + <agencyIdType>ISIL</agencyIdType> + <agencyIdValue>req_agency_value</agencyIdValue> + </requestingAgencyId> + </header> + <bibliographicInfo> + <title>Test request - invalid url</title> + </bibliographicInfo> + <serviceInfo> + <serviceType>Copy</serviceType> + </serviceInfo> + </request> + </ISO18626Message> XML
$t->post_ok( -- 2.47.3
-- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207105|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #13 from Phan Quang Minh <minhpq@tinhvan.com> --- Created attachment 207160 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207160&action=edit Bug 43674: Wrap ISO 18626 messages in the ISO18626Message envelope -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #14 from Phan Quang Minh <minhpq@tinhvan.com> --- Created attachment 207161 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207161&action=edit Bug 43674: Wrap request.t test data in the ISO18626Message envelope -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #15 from Phan Quang Minh <minhpq@tinhvan.com> --- Created attachment 207162 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207162&action=edit Bug 43674: (follow-up) Declare ISO 18626 version 2021-3 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #16 from Phan Quang Minh <minhpq@tinhvan.com> --- Signed off. Patches applied cleanly to a Koha 26.05.02 package install and retested against our third-party implementation, including the 2021-3 follow-up. With all three patches: - Koha -> us: six supplyingAgencyMessage exchanges, all accepted. - us -> Koha: ten requests and four requestingAgencyMessage actions (Received, ShippedReturn, Cancel, StatusRequest), all sent with our compatibility shim switched off entirely, so fully conformant XML. All accepted. - The response now declares ill:version="2021-3", and a message declaring the older 1.2 is still accepted. Same caveat as comment #6: I still cannot run step 5, since this is a package install with no t/ or test harness. Everything else in the test plan passes. I am signing off on the strength of the functional and interoperability testing; if the project would rather have a signoff that includes the unit tests, please treat this as testing feedback instead and I will not be offended. On splitting the remaining issues (comment #10): The agency identifier bug already exists — I filed it as bug 43695 at 11:13 UTC, about ten minutes before your comment, so you may not have seen it yet. For the datetime problem I have filed bug 43701 rather than rescoping 43694, and I would suggest keeping 43694 as it is. Three reasons: - They are different defects with different fixes: one is a value format, the other is the order elements are serialised in. - 43694 already carries a full report, a reproduction script and a correction I posted against my own original claim. Rescoping would discard all of that. - 43694 is the one you made depend on this bug, and that dependency is about the serialisation path, which the datetime fix does not touch. That said, you are the one carrying this work — if you would rather have 43694 rescoped,say so and I will close the new one as a duplicate. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org