Web Client: Serials - Predict New Issues Defaults to Previous Pattern

Bug #1745427 reported by John Amundson on 2018-01-25
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Unassigned
3.0
High
Unassigned
3.1
High
Unassigned

Bug Description

This has been tested on Evergreen 3.0.3 - Web Client.

When using the Predict New Issues button from either the Manage Issues tab or Manage Predictions tab of a record's Serials interface and multiple patterns exist on for the subscription, (only one active), the Predict New Issues dialog box has to be "tricked" into using the new pattern.

To get the dialog box to display the correct pattern, the "Type" can be changed to something else, (i.e. Supplement), and then changed back, (i.e. Basic).

Additionally, if issues exist and Predict New Issues is used, the system ignores the entered information. This is discussed in this bug: https://bugs.launchpad.net/evergreen/+bug/1745425
I have split the bugs because they seem to be separate issues but they combine to create some frustrating workflows.

One way these bugs cause problems is when a subscription changes the way it is published, (i.e. from monthly to seasonal).

Here is how the worfklow SHOULD work:
1. Create/select a new prediction pattern for the new publishing schedule.
2. Activate the new pattern and deactivate the old pattern.
3. Click Predict New Issues.
4. Enter in the new publication date/enumerations/chronology as needed.
5. Enter a prediction count and select Save. New issues should be created using the new prediction pattern.

If this workflow is followed then the new issues will ignore the entered information and continue to predict off an old issue with the old prediction pattern. If staff somehow manage to get the new prediction pattern to show, then Predict New Issues will sometimes fail silently and not predict new issues, (in the XUL client, the way around this was to create a new starting issues), and to continue predicting this way can lead to some eraditic results.

Here is a workaround to get it to work:
1. Create/select a new prediction pattern for the new publishing schedule.
2. Activate the new pattern and deactivate the old pattern.
3. Edit Holdings Code of latest expected issue.
4. In the dialog box, change "Type" to Supplement and then back to Basic. This will update the dialog box to the new pattern.
5. Enter in the new issue's publication date/enumerations/chronology as needed. Select Save.
6. The issue should be updated to the new pattern. CLick Predict New Issues.
7. In the dialog box, change "Type" to Supplement and then back to Basic. This will update the dialog box to the new pattern.
8. Ignore fields because they won't be recognized.
9. Enter a prediction count and select Save. New issues should be created using the new prediction pattern.

Predict New Issues should show the chosen/active Prediction Pattern.

Galen Charlton (gmc) on 2018-05-02
Changed in evergreen:
status: New → Confirmed
importance: Undecided → High
Kathy Lussier (klussier) on 2018-05-14
tags: added: webstaffblocker
Galen Charlton (gmc) wrote :

A patch is available at the tip of the user/gmcharlt/lp1745427_change_pred_patterns branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1745427_change_pred_patterns

tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.2-rc
Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Jason Stephenson (jstephenson) wrote :

We're looking at this at CW MARS, also, at least on rel_3_0. Don't let that stop you from pushing it if it works for you.

Mike Rylander (mrylander) wrote :

I didn't let it stop me, Jason. :)

Picked to 3.0-master for serial justice. Thanks, Galen!

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Mike Rylander (mrylander) → nobody
John Amundson (jamundson) wrote :

Thanks for your work on this Galen.

I have been testing the patch on a 3.0 system. While the patch alleviates most of my concerns on this bug, (and even some from bug #1745425), there are a few things that are still a little funky.

Here are my observations.

1. If a subscription has multiple patterns, and Predict New Issues is chosen from a pattern on the "Manage Predictions" tab, it doesn't matter which pattern the button is attached to, the Predict New Issues screen defaults to the active pattern. If multiple patterns are active, then the pattern with the most recent ID is chosen. Since only one pattern should be active at once, I don't see this as a problem, just a little odd from a user standpoint.

2. After a prediction change, the Predict New Issues window will reflect the new pattern and will accept new enumeration/chronology captions, BUT if the publication date is adjusted, the prediction fails silently. (the failure produces the attached console error). This means the user will have to either adjust the holdings code of the most recent issue to produce the correct publication date or predict more and then delete until the correct set of issues/dates is present.

3. When Edit issue holdings codes is chosen on an issue using an old pattern, the Predict New Issues screen does not reflect the new pattern, (this can still be changed by moving the type from supplement back to basic). These leads the user into thinking the issue will maintain the old pattern with new values. However, if the type isn't changed and the code edited, the resulting issue is a weird amalgamation of the two patterns.

I know Mike has already pushed the fix, and I can come to terms with that because my observations will probably be edge cases, but I still wanted to mention them. I'll also note that bug #1745425 should still be left open because that problem is not fixed if a pattern change is not involved.

John Amundson (jamundson) wrote :
Andrea Neiman (aneiman) wrote :

Hi John,

Since the fix on this bug is already committed, if you feel the issues you mentioned merit further community attention/discussion, please open new bugs for them. Thanks!

Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers