Null statcats break copy templates

Bug #1788680 reported by Jeff Davis
68
This bug affects 33 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
High
Unassigned
3.1
Fix Released
High
Unassigned
3.2
Fix Released
High
Unassigned
3.3
Fix Released
High
Unassigned

Bug Description

EG 3.0+

In the web client, copy templates do not apply properly when the template has null statcat values but a non-null statcat_filter value. For example, a copy template like the following will not work:

"Adult fiction":{"mint_condition":"t","statcats":{"223":null},"circ_lib":10,"ref":"f","circ_modifier":"book","loan_duration":2,"location":586,"holdable":"t","opac_visible":"t","circulate":"t","statcat_filter":10}

This issue was originally reported in bug 1772062 and a fix was provided:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1772062-copy-templates-null-stat-cats

Since this is only a partial fix (the original bug has several other possible causes), we are breaking it out into a separate bug report.

Tags: pullrequest
tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.1.5
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

Testing the fix is a little cumbersome. Here's a contrived example; adjust as needed for your environment, or try it with an existing copy template that has null statcat values but a non-null statcat_filter value.

1. Create a copy stat cat at BR1:

INSERT INTO asset.stat_cat (id, owner, name) VALUES (1, 4, 'test stat cat');

2. Create a copy template for your test user with a non-null statcat_filter value and some null values for statcats, referencing the stat cat you just created:

INSERT INTO actor.usr_setting (usr, name, value) VALUES (1, 'webstaff.cat.copy.templates', '{"Science fiction":{"mint_condition":"t","statcats":{"1":null},"circ_lib":4,"ref":"f","circ_modifier":null,"loan_duration":2,"location":123,"holdable":"t","opac_visible":"t","circulate":"t","statcat_filter":4}}');

3. Login to the web client as your test user at BR1.

4. Go to the copy editor, select your copy template and click Apply. You'll see a console error and the copy attributes (shelving location, etc) are not correctly populated from your template.

5. Apply the bugfix.

6. Clear cache (and possibly local storage?) and repeat step #4. This time, clicking Apply should set your copy attributes correctly based on your template.

Changed in evergreen:
milestone: 3.1.5 → 3.1.6
Changed in evergreen:
milestone: 3.1.6 → 3.2.1
Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Changed in evergreen:
milestone: 3.2.2 → 3.2.3
Changed in evergreen:
milestone: 3.2.3 → 3.3-beta1
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Revision history for this message
Andrea Neiman (aneiman) wrote :

SCLENDS has signed a contract with Equinox to address this bug.

Changed in evergreen:
milestone: 3.3-rc → 3.3.1
Dan Wells (dbw2)
Changed in evergreen:
importance: Undecided → High
milestone: 3.3.1 → 3.next
assignee: nobody → Dan Wells (dbw2)
Revision history for this message
Dan Wells (dbw2) wrote :

We suddenly began running into this regularly. The offered branch is a very simple change, and it works, so pushed to master through rel_3_1. Thanks, Jeff!

Personally, I think this bug resolves the root problem of bug #1772062 as well. The initially reported console errors are exactly what this change fixes.

Changed in evergreen:
status: New → Fix Committed
assignee: Dan Wells (dbw2) → nobody
Changed in evergreen:
milestone: 3.next → 3.4-beta1
Galen Charlton (gmc)
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.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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