Neglecting to set alert type when adding an Item Alert, causes all changes to be silently discarded on save.

[Nathan Eady]

Discovered on 3.3.
Reproduced on 3.5.1.

Steps to Reproduce:
 1. Start from a new profile, e.g., in a freshly-installed browser, or a
    browser that has just had its cache and so forth cleared out.
    (This is necessary to reproduce, because otherwise Evergreen remembers
    and defaults to a previously-used alert type.)
 2. Search->Search the Catalog
 3. Type in criteria and click Search.
 4. Click one of the titles in the results.
 5. In the list of item(s)/copi(es), click the edit link next to a barcode.
    (There may be alternatives to steps 2-5; this is one way to reproduce.)
 6. Make a change to the call number.
 7. Make a change to some copy field (e.g., Circulate as Type).
 8. Click the Item Alerts button.
 9. Leave the Type field unset.
10. Type some text in for the alert.
11. Click Ok.
12. Click Save & Exit.

Expected Results:
 1. After either step 11 or 12, an error message should be presented to the
    user explaining that alerts have to have a type.
 2. Also, ideally, the other (non-alert) changes should be saved.

Actual Results:
Evergreen appears to behave as though the changes have been saved; but they haven't been. This includes the volume-record (call number) change.

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

As an alternative fix to this issue, how about we disable the ok button when adding an item alert if the alert is blank or the alert type isn't specified?

<input type="submit" class="btn btn-primary" value="[% l('OK') %]{{ copy_alert.alert_type }}"
            ng-disabled="copy_alert.note == '' || copy_alert.alert_type === undefined" />

in t_add_copy_alert_dialog.tt2.

On the server side, logs like the following can let you know how often this happens. The DB insert fails with a null alert_type, but it is silent failure to the user.

27/pg.10.log.gz:2021-08-27 10:03:36 egdb1 postgres[26894]: [3-1] 2021-08-27 10:03:36 CDT [26894-1] evergreen@egdbprod ERROR: null value in column "alert_type" violates not-null constraint
27/pg.10.log.gz:2021-08-27 10:03:36 egdb1 postgres[26894]: [3-2] 2021-08-27 10:03:36 CDT [26894-2] evergreen@egdbprod DETAIL: Failing row contains (82548, null, 3489644, f, 2021-08-27 10:03:36.951408-05, 112773, Cover bent in book drop, null, null).

[Elaine Hardy (ehardy)]

+1

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

Here is a working branch with this fix: user/stompro/lp1898069_angularjs_copy_alert_prevent_invalid_save

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

This is for the AngularJS interface. This also prevents alerts with no note from being saved.

I think that the Angular interface isn't effected, it already seems to validate the required inputs.

Testing Notes:

0. Create a new workstation if item alert type has a default value.

1. Find an item and open it in the AngularJS Item Status (eg/staff/cat/item/3)

2. Action -> Add -> Add Item Alerts or "Item Alerts (Add)" add bottom of the page.

3. Try and create an alert with no alert type or with no note. Before the fix it would allow you to submit it, but no alert would be added because the DB would reject the request. After the fix the OK button is disabled until the required fields are filled in.

[Jennifer Pringle (jpringle-u)]

This fix fixes saving item alerts without item types through Item Status Action -> Add -> Add Item Alerts.

However, the bug is still present in the angularjs holdings editor accessed through the Fast Item add feature in Create New MARC Record. (related to https://bugs.launchpad.net/evergreen/+bug/1982876)

In the angularjs holdings editor you can enter alert text and no alert type and save your item, though it is discarding your changes and the item is not created.