Serials predictions with chronology but no enumeration corrupt, may prevent receiving
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
2.2 |
Fix Released
|
Medium
|
Unassigned | ||
2.3 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Reported in and reproducible in Evergreen 2.3.0. Unsure yet whether it's not somehow fixed in master (!), as I can't reproduce it /there/, but I don't see the code that could be fixing the problem.
The error message:
> Timestamp: 01/18/2013 06:03:34 PM Error: Error: Method error:
> undefined : *** Call to [open-ils.
> failed for session [0.893974742527
> trace [3]: Can't use an undefined value as an ARRAY reference at
> /usr/local/
>
>
> Source File: oils://
To reproduce: Pick any bib, add a subscription in alternate serials control. Set start date for, say, 1 Nov 2012 and an end date for 1 Jan 2014 (contrived, but helps with testing). Create one distribution (with a vanilla copy template) and one stream. Create a caption and pattern like this: ["2","0"
No problem so far, right? Well, look at the holding codes on the issuances starting with Jan 2013 closely. There's a subfield a in there that oughtn't be there (and, probably insignificantly, the new year (‡i) s an integer instead of a string).
Go to batch receiving and start receiving issues (with units attached). November 2012: no problem. December 2012: no problem. Jan 2013, problem.
For some reason this same process seems to work fine in master, but I've yet to identify the significant difference.
I've also got reports of the same error coming from sites receiving Christmas issues. I initially thought that might be related, but it could be a separate bug. More data here soon.
I actually knew almost everything I've written here by this time yesterday. Today I thought I'd get a handle on it, but with the time I've had to put toward it I've only gone around in circles so far. Something confusing is happening here (or something is just confusing on my test environment. It could always be just me).
More updates soon.
Changed in evergreen: | |
status: | New → Triaged |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
I am not saying we shouldn't support a caption like this if reasonable to do so, but it doesn't really conform to the documentation. The (MFHD) docs state:
"When only Chronology captions are used on an item (that is, the item carries no enumeration), the Chronology captions are contained in the relevant enumeration caption subfields ($a-$h)."
In other words, $i moves to $a, $j moves to $b, etc. I happen to think it's an odd rule, but the prediction code is definitely written to expect it.
So, short term (and it might be mildly painful if you have a lot of issuances), we should be able to redo the caption/pattern to fix this behavior. Also, if we are generating captions like this, we need to look at that code as well.
Longer term, again, if we can do so without mangling the code too much, I think it is good to support common mistakes like this and have it work in a reasonable manner.