Angular catalog serials menu doesn't include Quick Receive

[Mary Llewellyn]

Version: 3.5.1
Browser: Chrome Version 86.0.4240.198 (Official Build) (64-bit)

When you click on the Serials button in the traditional staff catalog, you get 3 menu choices:
Quick Receive, Manage Subscriptions, Manage MFHDs

In the Angular staff catalog, there are only 2 choices
Manage Subscriptions, Manage MFHDs

What I expected:
To have the Quick Receive menu option to be present in the Angular catalog menu

[Jane Sandberg (sandbergja)]

I spent some time looking at how the AngularJS client's Quick Receive works. For anybody who takes this ticket, here are the broad strokes that I saw, in case it is helpful to you:

1) When Quick Receive is clicked, open a modal containing the egSubSelector/eg-sub-selector (subscription selector) directive. This directive is, in turn, made of an org selector and a PCRUD-generated list of subscriptions at that bib record and OU (and the OU's descendants). My impression is that it would be easy to address usability bug 1915567 while re-implementing this subscription selector in Angular.

2) When the user chooses the subscription they want, the AngularJS serials service's fetchItemsForSub method does some work to search for just the right serials items.

3) The item IDs get passed to the AngularJS serials service's process_items method, which ultimately sends a call to open-ils.serial.receive_items

At a casual glance, steps 2 and 3 seem to do a lot of work. Perhaps, rather than re-implementing them exactly in Angular, some of that logic could be done in Perl.

[Christine Burns (christine-burns)]

tested on 3.8 - Quick Receive option is still missing

[Jennifer Pringle (jpringle-u)]

Still missing in 3.9. Libraries using serials may consider this a blocker for using the new staff catalogue.

[Elizabeth Davis (elidavis)]

Just echoing Jennifer's comments that the lack of Quick Receive and even the catalog search on top of the Manage Subscription screen is making it very difficult for staff to receive new issues in the new staff catalog.

[Tiffany Little (tslittle)]

Marking this as High importance based on Jennifer and Elizabeth's most recent comments.

[Elizabeth Davis (elidavis)]

I know it wasn't on the list, but I checked this on the bug squashing test servers. I didn't see it and was hoping to. It may prevent us from using the boopac.

[Mary Llewellyn (mllewell)]

Still missing in 3.11.

[Jane Sandberg (sandbergja)]

Here is a branch implementing Quick Receive in the Angular client (top 4 commits): https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1906462-angular-quick-receive

This work was commissioned by PaILS, who will be testing it presently. I'll add the pullrequest tag after their testing and any follow-up work.

Here are some testing notes, including a basic serials subscription setup:
1. Set up some subscriptions and predict some issues.
  a. Open your favorite bib record in the staff catalog.
  b. Go to Serials > Manage Subscriptions.
  c. Add a new subscription with a start date of today. If you want to test the barcode receive functionality, select a Receiving Template you have previously created in Admin > Serials Admin > Serial Item Templates.
  d. If you want to test the routing lists, use the actions menu to select "Add Additional Routing" and add some users and/or departments.
  e. Go to the Manage Predictions tab
  f. Press Add New
  g. Press Create from Template
  h. Select Daily
  i. Press Create
  j. Press Predict New Issues
  k. Select the number of issues you want to Predict
2. Go back to the bib record
3. Go to Serials > Quick Receive
4. Select the appropriate org unit and subscription
5. Press Continue
6. Enter any necessary metadata. Uncheck any items you don't want to receive.
7. Press Receive or Receive and Print Routing List.
8. Confirm that Serials > Manage Subscriptions > Manage Issues tab shows the issues as received now.

[Jane Sandberg (sandbergja)]

Pushed a new branch here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1906462-angular-quick-receive-2

There is no difference in functionality, it merely:
* Includes the Sponsored-by: PaILS line in the commit messages, which I had forgotten earlier
* Corrects a pervasive typo in my code (Recieve instead of Receive). Thanks to Galen for bringing this to my attention.
* Makes a small docs correction
* Rebases on main

[Elizabeth Davis (elidavis)]

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

[Galen Charlton (gmc)]

I've started reviewing this. I don't have the time to do a complete review in one sitting, but here's what I have so far:

[1] The form seems to be expecting that at least one item will have call number and barcode supplied, even if you haven't ticked the checkbox to barcode the issue. In other words, it's not allowing you to receive without barcoding without also fiddling with the form, which is a regression on the AngularJS Quick Receive and a showstopper. I'm adjusting the LP tags accordingly.

[2] I'm not a fan of the template row automatically overwriting inputs in the item rows; the AngularJS Quick Receive has an explicit apply button, which gives a little more room for the operator to catch an error before committing to a batch change, especially since neither version of Quick Receive has undo.

[3] Nit regarding the routing list: the hyphen before the routing list entry note is always displayed, even if there is no note for that entry.

[4] Maybe a nit regarding the routing list, maybe not: the AngularJS version of the printed routing list included the patron addresses. If that's functionality that anybody might need, I think it would be better for the new server-side print template to include it (and in general, match the older version as closely as possible.) (Also, if it's not wanted, it's easier to remove fields than add them when customizing print templates.)

[Jane Sandberg (sandbergja)]

Thank you for the review, Galen! I've fixed the bugs you identified in a fifth commit on this branch: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1906462-angular-quick-receive-2

[Jason Etheridge (phasefx)]

Thanks Jane, Galen. I'm able to cause a DB insert error if you reuse the same call number label.

You should also include the print template in the seed data, though I note that the main serials interface doesn't use said template for the same thing.

Incidentally, Stephanie and I helped write a serials specification a while back, and for Quick Receive the plan was to leverage the same UI as Receive Next and Receive Selected (which I believe would also have some improvements), but with an org and subscription selector at the top. It would default to the first "open" Subscription (where the current date falls within the Start Date and End Date) or, otherwise, the Subscription with the greatest Start Date.

https://yeti.equinoxoli.org/dev/public/techspecs/serials_202303.pdf

[Jane Sandberg (sandbergja)]

Thanks for taking a look and for that spec, Jason. I can get the DB error too, re-assigning myself to take a look.

Unless I'm missing something, the user/sandbergja/lp1906462-angular-quick-receive-2 branch does add a print template to the 950 seed data file. Is there something else I should check?

Yeah, I decided to introduce a new print template for the routing list, to move away from dojo and to give end-users more ability to configure what gets printed. I was thinking that it could be used for other receive options in the interface as they are brought over to angular, although it does give that inconsistency for now, where users can configure the quick receive print template, but not the one that prints when they receive from the "Manage Issues" tab.

[Jane Sandberg (sandbergja)]

The database error when re-using the same call number label also occurs in the current AngularJS quick receive, so I opened a new bug for it: bug 2053054. Since the bug also exists in the AngularJS interface, I don't personally see it as a blocker to this ticket, but I'm certainly open to different views on the matter.

[Galen Charlton (gmc)]

Happy Daylight Savings!

I'm seeing a test failure when running `npm run test` in ET or timezones further east:

Firefox 115.0 (Linux x86_64) SubscriptionSelectorComponent findSubscriptions() sets subscriptionList property FAILED
        Expected $[0].label = 'Subscription 12 at MYLIB (1/1/20-1/1/26)' to equal 'Subscription 12 at MYLIB (1/1/20-12/31/25)'.
        <Jasmine>
        46806/</</<@main.js:22076:42
        <email address hidden>:436:158
        <email address hidden>:26063:33
        <email address hidden>:436:46
        <email address hidden>:219:35
        <email address hidden>:26342:28
        wrapTestInZone/<@vendor.js:26357:14
        <Jasmine>
        <email address hidden>:436:158
        <email address hidden>:219:35
        64924/</scheduleResolveOrReject/<@polyfills.js:1312:28
        <email address hidden>:463:171
        <email address hidden>:265:37
        <email address hidden>:634:23
Firefox 115.0 (Linux x86_64): Executed 60 of 156 (1 FAILED) (0 secs / 2.254 secs)
Firefox 115.0 (Linux x86_64) SubscriptionSelectorComponent findSubscriptions() sets subscriptionList property FAILED
        Expected $[0].label = 'Subscription 12 at MYLIB (1/1/20-1/1/26)' to equal 'Subscription 12 at MYLIB (1/1/20-12/31/25)'.
        <Jasmine>
        46806/</</<@main.js:22076:42
        <email address hidden>:436:158
        <email address hidden>:26063:33
        <email address hidden>:436:46
        <email address hidden>:219:35
        <email address hidden>:26342:28
        wrapTestInZone/<@vendor.js:26357:14
        <Jasmine>
        <email address hidden>:436:158
        <email address hidden>:219:35
        64924/</scheduleResolveOrReject/<@polyfills.js:1312:28
        <email address hidden>:463:171
        <email address hidden>:265:37
WARN: Object{pid: 10241, servertime: 'Sun Oct 15 06:05:50 2023', stacktrace: '/usr/local/share/perl/5.30.0/OpenILS/Application/Booking.pm:213 /usr/local/share/perl/5.30.0/OpenSRF/Application.pm:628 /usr/share/perl5/Error.pm:465', ilsevent: '', textcode: 'RESOURCE_IN_USE', desc: 'Resource is in use at this time'}
Firefox 115.0 (Linux x86_64): Executed 74 of 156 (1 FAILED) (0 secs / 2.489 secs)
WARN: Object{pid: 10241, servertime: 'Sun Oct 15 06:05:50 2023', stacktrace: '/usr/local/share/perl/5.30.0/OpenILS/Application/Booking.pm:213 /usr/local/share/perl/5.30.0/OpenSRF/Application.pm:628 /usr/share/perl5/Error.pm:465', ilsevent: '', textcFirefox 115.0 (Linux x86_64): Executed 156 of 156 (1 FAILED) (5.438 secs / 5.067 secs)
TOTAL: 1 FAILED, 155 SUCCESS
TOTAL: 1 FAILED, 155 SUCCESS

[Jane Sandberg (sandbergja)]

Daaaaaaaaaaaaaaaates!!! :-(

Thanks, Galen. I'll grab this one back and try to figure it out.

[Galen Charlton (gmc)]

My recommendation for the quickest way to resolve it - don't try to set the timezone, since I discovered in the context of thinking about a test plan for another bug that there's no way to explicitly set the timezone _within_ the test code short of doing a lot of extensive mocking of Date or using the TZ environment variable. Instead, I suggest grabbing the current timezone, whatever it happens to be, and using that as part of setting up the start and end date values in the relevant test.

[Jane Sandberg (sandbergja)]

Thanks, Galen. That did the trick!

user/sandbergja/lp1906462-angular-quick-receive-3 contains a sixth commit that uses the current timezone, rather than hardcoding a timezone offset. It also rebases on main.

Thanks also for the clue about the TZ environment variable. I didn't use it in the test code, but it sure was convenient for the purposes of running the test suite in various timezones, e.g.:

TZ=Pacific/Honolulu npm run test
TZ=Europe/Helsinki npm run test # test suite fails without the most recent commit

[Andrea Neiman (aneiman)]

We looked at this in code review on https://bugsquash.mobiusconsortium.org/eg/staff (which Blake confirmed is running the most recent branch, user/sandbergja/lp1906462-angular-quick-receive-3).

It appears that Quick Receive will not allow issues to be received without barcoding - if you attempt to receive an issue unbarcoded, Quick Receive will auto-generate a barcode regardless of whether or not "Automatically generate barcodes" is checked in the Quick Receive interface.

See serial items 1076 and 1080 on the above noted test server for examples of this. See serial item 1077 for an example of unbarcoded receive from within the Manage Issues tab.

[Jane Sandberg (sandbergja)]

Thanks for catching this, Andrea and other code review friends! I pushed a fix to the same branch (user/sandbergja/lp1906462-angular-quick-receive-3): https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1906462-angular-quick-receive-3

It is now 7 commits long 😬

[Chrisy Schroth (cschroth)]

Thanks for all your hard work Jane! The problem from yesterday with Quick Receive auto-generating barcodes seems to be fixed. The problem with routing lists not printing if you do not barcode the items from bug https://bugs.launchpad.net/evergreen/+bug/1823784 (marked a duplicated to this one) is also fixed.

There is a new problem that the Distribution/Stream Notes fields are not displaying in this update. We use these alert notes to tell branch staff that the item does not get barcodes, and that they need to uncheck the barcode items box before they receive the item, and print the routing list if appropriate. I can take some screenshots if that helps.

I put a test subscription note with the alert box checked on TCN 282 (Catster) on this test server if you need to try it out.

[Galen Charlton (gmc)]

I've pushed out a new collab branch, working/collab/gmcharlt/lp1906462_more_review, that includes follow-ups to fix lint and allow null to be passed as the call number affix value without breaking serial receiving.

(By the way, contra comment 16, the AngularJS Quick Receive seemed to handle cases where the affixes were left unset just fine)

Other feedback:

[1] The checkboxes for whether a routing list should be printed or not seem to do nothing; it looks like the "Receive and print routing list" button will print the routing lists regardless of the checkbox settings.

[2] The AngularJS Quick Receive was more sophisticated in its handling of call numbers; in particular, it looks for all call numbers (with affixes) that have been used for the bib at the receiving library and presents a drop-down allowing the user to pick one to use as a batch update option. It also fills in the call number of the last issue that was received.

However, I think there's a broader discussion to be had regarding that feedback, regarding the second point: while it's clear that more work would need to be done to fully replicate the functionality of the AngularJS Quick Receive (and TBH, I think replicating its ability to help the user select the call number to use for barcoded issues rather than type them in from scratch is important), are we at a point where it's "good enough" for the moment?

[Eva Cerninakova (ece)]

I have tested the Quick Receive using https://bugsquash.mobiusconsortium.org server, record 156. I created subscription, distributions and streams.
There is a problem with the same call number described in Jane's comment (#16, bug 2053054).
,
I can confirm that I don't see any other problems. It is possible to Quick Receive a single issue or multiple issues (no matter whether multiplicity occurs as a distribution or as a stream or both) without barcodes, with automatically generated barcodes, or with manually added barcodes.

Just a note: in my opinion, the button label "Apply to all following items" might be a little confusing if only one issue is being received. I would prefer, e.g., the following item/items.

[Chrisy Schroth (cschroth)]

I agree with Galen in comment #24 that the Quick Receive should be grabbing the call numbers from somewhere for the user to select/edit for their new item. The record I received an item on didn't yet have a call number, so I assumed the next one received would grab that call number for editing.

The current Quick Receive in the traditional catalog of version 3-11-3 has the dropdown box with Default selected, but all other possible call numbers to choose from. It then auto fills the call number box for the item you are receiving with the last created call number so you can edit it to match your new item. Either would work, both would be ideal. As long as the branch level staff aren't trying to type in the full call number each time, which not only slows them down, but is just asking for mistakes and typos.

[Jane Sandberg (sandbergja)]

Grabbing this to:
* add distribution/subscription notes (previously only issuance notes were included)
* Change "all following items" to "the following item/items"
* add a call number dropdown
* figure out those routing list checkboxes

[Chrisy Schroth (cschroth)]

Jane, Thanks again for all your hard work! I am attaching (I hope) a screen capture of how the Quick Receive screen looks in our current 3-11-3 catalog (obviously under the Traditional catalog). I don't actually see Issuance notes in our catalog, so I didn't know that was possible in this screen. I chose an example where we have a Subscription Alert Note in use.

[Jane Sandberg (sandbergja)]

Thanks, Chrisy! That's helpful.

[Jane Sandberg (sandbergja)]

Fixes pushed to Galen's collab branch: working/collab/gmcharlt/lp1906462_more_review

Here is a link: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/lp1906462_more_review -- it is now an 11-commit monster!

Galen, thanks for your two new commits as well! I have tested those commits and consent to signing off on them with my name, Jane Sandberg, and my email <email address hidden> (I don't think I can force push my signoff to your collab branch).

[Blake GH (bmagic)]

All,

we have a library interested in putting this patch on production. But they are on 3.11. I created a working branch for 3.11 FYI:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/blake/lp1906462_more_review_3_11

[Blake GH (bmagic)]

Noting here that the 3.11 branch doesn't work due to some angular/node version assumptions of the original branch. At least that's my current theory.

Error: src/app/staff/serials/quick-receive.component.html:3:5 - error NG8001: 'eg-back-button' is not a known element:
1. If 'eg-back-button' is an Angular component, then verify that it is included in the '@Component.imports' of this component.
2. If 'eg-back-button' is a Web Component then add 'CUSTOM_ELEMENTS_SCHEMA' to the '@Component.schemas' of this component to suppress this message.

This error doesn't appear when I install Evergreen via main branch, then checkout 3.11.1 and cherry-pick my 3.11 branch. Then reinstall the eg2 pieces as well as the rest of Evergreen.

[Jane Sandberg (sandbergja)]

It looks like that back button component is only in 3.12 and above. It was part of bug 1993824. Does cherry-picking the non-linkchecker parts of commit d24be693ca3b728acf0cb79f8be95108abb5717f get you further, Blake?

[Blake GH (bmagic)]

Jane,

My project was an effort to get this patch installed on production for the library. And this branch, with a minor merge conflict, does merge onto 3.11. But that alone doesn't get me to where I want to go. Fooling with production to a larger degree isn't something I want to do, so I reversed. Instead, IMO we need to upgrade production to a newer version of Evergreen, and hopefully this bug fix will be included :)

Your referenced commit doesn't cherry-pick onto 3.11.1 (nor rel_3_11) without conflict.