https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674

--- Comment #6 from Phan Quang Minh <[email protected]> ---
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.
_______________________________________________
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/

Reply via email to