Acq: Line Item Alert Types Not Scoped in Purchase Orders

[Jennifer Pringle]

Evergreen 3.11

When applying an alert to a line item on a purchase order the options for Alert Type no longer scope (they did in the dojo interface). I can now see the alert types for every library in our consortium in the drop down when logged in as a local system administrator at one of our libraries.

Some of our have alert types with the same names and you can't tell from the drop down which ones belong to which library.

Not sure what it was basing the scope off of in the dojo interface but it should do the same in the angular interface.

[Jeff Davis (jdavis-sitka)]

It looks like the Dojo interface displayed alert types belonging to the workstation OU or its ancestors (acq.lineitem_alert_text.owning_lib).

[Jeff Davis (jdavis-sitka)]

Working branch user/jeffdavis/lp2030820-scope-line-item-alert-type has a potential fix:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp2030820-scope-line-item-alert-type

To test, add some alert types to acq.lineitem_alert_text belonging to various org units (say, BR1 and BR3). Then go to Purchase Orders, do a search, and click on "Notes and Alerts" for one of the lineitems. The Alert Type dropdown should contain only alert types belonging to ancestors of your current workstation OU.

[Jennifer Pringle (jpringle-u)]

Working on our test systems and we plan to include the fix in our upgrade to 3.11 this month.

(I'm from the same org as Jeff so can't officially sign off.)

[Garry Collum (gcollum)]

I tested by creating several alert types at different levels of the heirarchy (SYS1, BR1, SL1, BR2, etc). When I looked at the Alert Type drop-down only those org units and their ancestors appeared as an option in the drop-down based on my current workstation OU. A signed-off branch is at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gcollum/lp2030820-scope-line-item-alert-type-signoff

[Terran McCanna (tmccanna)]

Thanks Jeff, Jennifer, and Garry!

Fix committed to 3.11 and up. (I was not sure if this should be backported further since the bug was reported in 3.11.)