Acq: Be case-insensitive when looking for EDI documents already fetched
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
2.3 |
Fix Released
|
Medium
|
Unassigned | ||
2.4 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Evergreen 2.3+
The edi_fetcher relies on a routine in OpenILS::Acq::EDI to, among
other things, try to avoid fetching the same EDI document multiple times
when many rows in acq.edi_account refer to the same remote host and
login credentials.
Since in practice most vendors seem to run FTP servers for EDI on
Windows, not UNIX, and pathnames are therefore case-insensitive, that
test for other occurrences ought also to be case-insensitive.
If I were to look at this as a purist, I could argue that vendor servers
might sometimes by run on UNIX, and that for some reason it is possible
that different vendor-to-buyer EDI documents (order responses or
invoices) could have pathnames that differ only in the case of some
characters. But that seems wildly unlikely. If anyone does take this
possibility seriously, perhaps acq.edi_account needs a Boolean column to
indicate the remote host's case [in]sensitivity.
Otherwise this will do.
Changed in evergreen: | |
status: | New → Triaged |
Changed in evergreen: | |
milestone: | 2.4.0-rc → none |
Changed in evergreen: | |
milestone: | none → 2.5.0-m1 |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
I may have been too abstract in the bug description above. I'll follow my own oft-given advice and give reproducible steps and an observable error symptom.
1) Set up two EDI accounts for the same vendor, with the same hostname, username, and password fields. Vary the in_dir between the two accounts only in case (i.e, make one all-caps and the other one all lowercase). Some other fields like vend_code can be different between the two accounts. Your EDI vendor must run its FTP server on Windows (or you must mock up a case-insensitive FTP server) to test this.
2) Run the edi_fetcher. If documents are successfully retrieved, before the given patch is applied to your system, you'll have two new rows in edi_message for the same document (or more if the document contains many messages). After the patch is applied, the same operation should only result in one new row for the same document (assuming only one message in the document).