Alt Serial Control won't generate predictions with certain pattern frequency

Bug #1319538 reported by Holly Brennan on 2014-05-14
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned

Bug Description

Since upgrading from 2.3.4 to 2.5.2, I can't create serial predictions the same way.

For bimonthly subscriptions, I always select "Use number of issues per year" as the frequency in the pattern, rather than using the "Select frequency: Annual/etc". This is because I want to display both months for bimonthly issues, as they display on the issues themselves (example: I want the Apr/May 2014 issue of Fine Homebuilding to display as Apr/May 2014, not display only one of the months - May 2014). So I use number of issues per year, and then "use specific regularity info" in the next screen to set up which months are combined.

When using "Select frequency: bimonthly" the generated issues only display one of the two months for each issue. This is confusing for both staff and patrons because the issues in Evergreen don't match the physical copies.

Since upgrading to 2.5.2, when I create a pattern using "use number of issues per year", then create the New Issuance, nothing happens when I generate predictions. The thinking bar spins and spins and never errors out or produces issues. I once left it spinning for 20 minutes. (I have run into extended thinking bar spinning problems before, but it would always error out within 5 minutes)

What I would like:

- Have the Generate Predictions action function as before. If I use the number of issues per year is in the pattern, it should create issues

- OR, I'd be happy to use the "select frequency" option IF it displayed both months when choosing bimonthly

This problem only seems to affect NEW patterns created since the upgrade to 2.5.2. Patterns set up before this still generate predictions for bimonthly subscriptions as I like them, displaying both months for each issue.

Example of existing pattern for bimonthly Fine Homebuilding, which generates and displays perfectly (both on 2.3.4 and now in 2.5.2):
["0","0","8","1","a","no.","i","(year)","j","(month)","w","m","y","cm12/01","y","cm02/03","y","cm04/05","y","cm06/07","y","cm08/09","y","cm10/11"]

Example of new pattern created after upgrade to 2.5.2 (created today) which does not generate predictions:
["0","0","8","1","a","i.","i","(year)","j","(month)","w","6","y","cm02/03","y","cm04/05","y","cm06/07","y","cm08/09","y","cm10/11","y","cm12/01"]

Holly Brennan (hollyfromhomer) wrote :

There is an error after clicking the Generate Predictions button:

Timestamp: 5/15/2014 9:27:52 AM
Error: Error: Method error: undefined : *** Call to [open-ils.serial.make_predictions] failed for session [0.70210777705767121400174871991], thread trace [0]:
Don't know how to deal with frequency '6'! at /usr/local/share/perl/5.14.2/OpenILS/Utils/MFHD/Holding.pm line 488.

Source File: oils://remote/js/dojo/dojo/dojo.js
Line: 188

Dan Wells (dbw2) wrote :

I'm not sure when things may have changed with this particular code, but here are two ways to do what you want (generate a bi-monthly but show both months):

1) Do exactly as you have done with combining the issues, but rather than entering '6' issues per year, tell the system it is a "monthly". "Combined" issues only work when the combining interval (the 'm' in 'cm12/01') is the same as the frequency (the 'm' in subfield 'w'). As long as you combine all the months, you end up with the 6 issues you are after.

2) Keep '6' as the selected frequency, but then enter the "specific regularity info" as "Published" issues, not "Combined". Any time you use a numeric frequency, you need a matching number of 'pm12/01' entries in subfield 'y' (note the 'p' rather than the 'c').

Holly Brennan (hollyfromhomer) wrote :

Brilliant! You're the man, Dan. I chose Option 1, since it was closest to my previous procedure. With this new pattern, predictions were generated perfectly! Thank you!

I will be curious to find out if this was a quirk before that I was somehow allowed to create predictions the "wrong" way, or if this is a new bug that isn't letting me do something I should now.

But for now, I have a new procedure and it gives me the exact output as before, with no more effort.

Thanks, Dan! (And Jason, for poking me to check the error log which proved it wasn't just me doing something wrong!)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers