Serials predictions with chronology but no enumeration corrupt, may prevent receiving

[Lebbeous Fogle-Weekley]

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.serial.receive_items.one_unit_per]
> failed for session [0.89397474252766281358550204781], thread
> trace [3]: Can't use an undefined value as an ARRAY reference at
> /usr/local/share/perl/5.10.1/OpenILS/Utils/MFHD/Holding.pm line 562.
>
>
> Source File: oils://remote/js/dojo/dojo/dojo.js Line: 188

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","8","1","i","(year)","j","(month)","w","m","x","01"]. Create your dummy issuance with a date of 1 Oct 2012. Generate predictions to end of subscription.

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.

[Dan Wells (dbw2)]

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.

[Lebbeous Fogle-Weekley (lebbeous)]

Thanks for pointing that out, Dan. Possibly I can fix the problem for the records I'm dealing with by making the pattern more strictly correct, and if the Caption/Pattern wizard needs to be made to follow that rule more closely, I'll make that change too, instead of supporting the wrong pattern.

Assuming all that works out the way it should, I'm wondering if the absence of a subfield ‡a should usually be an error condition.

[Lebbeous Fogle-Weekley (lebbeous)]

Thanks Dan,

So the example patterns are just wrong as you pointed out. Further, this branch prevents the caption/pattern wizard from generating them (moving chronology fields to the enumeration slots when actual enumeration is not in use)./

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/senator/scap-wizard-enum-is-chron

No steps taken at this time to prevent hand-entered patterns that look like the one in the initial bug report, for now.

[Dan Wells (dbw2)]

Code looks good, and works properly in testing of common patterns.

Pushed to master, rel_2_3, and rel_2_2. Thanks, Lebbeous!