Acq: Be case-insensitive when looking for EDI documents already fetched

Bug #1169291 reported by Lebbeous Fogle-Weekley
8
This bug affects 1 person
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.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/senator/edi-fetcher-case

Revision history for this message
Lebbeous Fogle-Weekley (lebbeous) wrote :

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).

Ben Shum (bshum)
Changed in evergreen:
status: New → Triaged
Ben Shum (bshum)
Changed in evergreen:
milestone: 2.4.0-rc → none
Ben Shum (bshum)
Changed in evergreen:
milestone: none → 2.5.0-m1
Revision history for this message
Ben Shum (bshum) wrote :

Picked to master, rel_2_4, and rel_2_3.

Changed in evergreen:
status: Triaged → Fix Committed
Ben Shum (bshum)
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.