Item alerts cannot be applied to multiple items

[Beth Willis]

Item alerts cannot be applied to multiple items when adding new holdings with a single call number.

To test:

Select a bib record
Select "Add Holdings"
In the "Holdings Details", increment the number of items to add
Add a call number and barcodes
Select item attributes to apply (including an item alert) or apply a template that includes an item alert);

Note: when adding new item alert, clicking on "OK" adds the item alert but does not close the box. You must "x out" of this box.

Go to Holdings View
Note that only the first item added has an item alert. (See attached screenshot.)

I am not seeing the same problem when editing multiple items from holdings view or when adding multiple items to a bib record, all of which have different call numbers.

E.g. 3-2-4

[Janet Schrader (jschrader)]

Confirmed in 3.2.5

This is impacting the workflow in large libraries that often buy multiple items and also for libraries with branches.

For libraries with branches if cataloging multiple items for several branches the alert is added only to the first item for each branch. So if adding 2 items for branch A, 1 item for branch B, 3 items for branch C, only 3 items end up with alerts, 1 for branch A, 1 for branch B, and 1 for branch C.

[Josh Stompro (u-launchpad-stompro-org)]

Confirmed in EG 3.3.4

In the browser console, there is an error when the ok button is pressed in the add alert popup.

TypeError: Cannot read property 'push' of undefined
    at app.js:2310

Which is in app.js

 a.ack_time(null);
                            a.alert_type(
                                $scope.alert_types.filter(function(at) {
                                    return at.id() == copy_alert.alert_type;
                                })[0]
                            );
----> cp.copy_alerts().push( a );
                        });

So cp.copy_alerts() isn't defined when it is called.

I noticed that the copy_alert_dialog() compared to the copy_note_dialog() function is missing a bit like this.

2126 angular.forEach(copy_list, function (cp) {
2127 if (!angular.isArray(cp.notes())) cp.notes([]); <----
2128 var n = new egCore.idl.acpn();
2129 n.isnew(1);

copy_alert_dialog() doesn't seem to have anything defining an empty cp.copy_alert([]) like the copy notes do. So maybe adding in something like "if (!angular.isArray(cp.copy_alerts())) cp.copy_alerts([]);" after the forEach would do the trick.

                     if (typeof(copy_alert.note) != 'undefined' &&
2302 copy_alert.note != '') {
2303 angular.forEach(copy_list, function (cp) {
2304 var a = new egCore.idl.aca();
2305 a.isnew(1);
2306 a.create_staff(copy_alert.create_staff);

[Josh Stompro (u-launchpad-stompro-org)]

Here is a working branch with the one line change.
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1832735_volcopy_copy_alert

It seemed to fix the issue with the copy alert dialog not closing when clicking ok. And the alert seemed to be applied to multiple copies.

Josh

[Beth Willis (willis-a)]

I tested Josh's code and found that it fixes part of this bug.

If you add holdings, create multiple items for a single call number and include an alert as one of the item attributes, the alert is associated with each item and will display correctly the relevant action is taken.

However, if you include an alert as part of an item template and apply this template when creating multiple items as above, the alert is associated only with the first item. The alert does not display for the remaining items relevant action is taken.

I probably should have been more clear in the original bug report that there were two parts to this bug.

Tested on EG 3-3-5

[Josh Stompro (u-launchpad-stompro-org)]

Thanks for testing Beth, I'll try out applying via template and see if I can spot the issue.
Josh

[Josh Stompro (u-launchpad-stompro-org)]

I tested adding notes and alerts, and I think notes are also broken, being applied via template. There is a console error "TypeError: "cp.notes(...) is undefined"

Josh

[Beth Willis (willis-a)]

Josh,

There is another bug related to item notes in item templates: https://bugs.launchpad.net/evergreen/+bug/1850802

Thanks for working on this!
Beth

[Josh Stompro (u-launchpad-stompro-org)]

Beth, it seems like the same fix works for the alerts and notes applied via template, there is just a different function used when applying a template that needed to be updated.

The usability could still use some work. If you apply a template twice, then there will be duplicate notes and alerts added to each item. There is no indication that the alerts or notes have been applied. No way to tell how many alerts/notes are already there.

I updated the branch I posted before so it includes the fixes for notes & alerts via template, and the fix for setting alerts via the "Item Alerts" button dialog.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1832735_volcopy_copy_alert

Josh

[Beth Willis (willis-a)]

I have tested this code and it works as indicated. It is possible to batch add item alerts to multiple items when adding or editing holdings. This also works when applying an item template that includes an alert.

I have tested this code and consent to signing off on it with my name, Beth Willis and my email address, <email address hidden>.

Notes:

It still is not possible to edit/remove item alerts from multiple items in batch as documented in bug #1827236: https://bugs.launchpad.net/evergreen/+bug/1827236

If a template is applied to an item multiple times, the item alert will be assigned to that item multiple times. There is no indication that the item has multiple instances of the same alert. I will open a separate bug about this.

[Beth Willis (willis-a)]

Note: tested the above on EG 3-3-5

[Jane Sandberg (sandbergja)]

This works well for me. Thanks for your code, Josh! And thanks for testing, and for those helpful testing steps, Beth.

I agree that the UI is not great, but it looks like Janet has reported that separately on bug 1833458, so we can continue that discussion there.

I've pushed this fix to master, rel_3_4, and rel_3_3.