Angular Acquisitions Sprint 4: Purchase Order & Line Items Interface

[Andrea Neiman]

This work is funded by the Evergreen Community Development Initiative.

Building on the work by Bill Erickson in Bug 1929741, Equinox will continue to angularize the acquisitions interfaces. This piece is focused on the Purchase Order & Line Items interfaces.

Full functional specifications can be seen here: https://yeti.equinoxoli.org/dev/public/techspecs/angacq_sprint4_rev202107.pdf

ECDI is also funding two bugfixes as part of this project:

Bug 1268006 (ACQ should apply a default owning lib to copies managed via batch update)
Bug 1357037 (Additional sort order options when viewing purchase order line items)

[Galen Charlton (gmc)]

A patch series is available in the branch user/gmcharlt/lp1942220_angular_acq_sprint4 / https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1942220_angular_acq_sprint4

This pull request incorporates the following pending contributions by other Evergreen developers:

* Bug 1929741 (Angularize ACQ Selection and Order Interfaces) [Bill Erickson]
* Bug 1929749 (Angularize Acq Load MARC Order Records) [Tiffany Little]
* Bug 1570623 (Acquisitions: Line Item already owned Copy Count is not updated when a copy is deleted / cancelled) [Tiffany Little]

This pull request also includes patches for the following bugs/enhancements:

* Bug 1981714 (new library setting to specify owning library for auto-created line items)
* Bug 1357037 (Additional sort order options when viewing purchase order line items)
* Bug 1960526 (Angular link color and link accessibility)

This pull request also includes fixes for the following bugs:

* Bug 1268006 (ACQ should apply a default owning lib to copies managed via batch update)

[Ruth Frasur Davis (redavis)]

I and members of the ECDI acquisitions testing team have tested this code and consent to signing off on it with my name (Ruth Frasur/rfrasur) and email address, <email address hidden>.

[Andrea Neiman (aneiman)]

Documentation draft here to facilitate testing:

https://docs.google.com/document/d/1LA4lOatvpfqV4pC4cuki8m8wVCQ5DK_rr-d5hIXijxM/edit?usp=sharing

[Galen Charlton (gmc)]

A community test server is now available. The particulars can be found here:

https://docs.google.com/document/d/1N49RCxJxp7Yjqgmy67F4rtbSrH3kd2bouDbeKAg42EY/edit

[Tiffany Little (tslittle)]

I'm planning on testing more extensively later, but I was just tinkering this morning and noticed that if you go to PO#2 on the test server, the statuses are wrong for line items #4 and #5. #4 shows as Delayed Backorder, but if you go into the Items, it's actually Canceled:Invalid ISBN. #5 shows as Canceled:Invalid ISBN, but if you go into the Items it's actually Delayed:Backorder.

I'm not sure where it's grabbing the fund info from either--#4 shows as having $12 encumbered even though the item is canceled, but even if it wasn't, the encumbrance should be $18.50. Unless it's grabbing the price info from line item#3, which *is* $12.

[Mary Llewellyn (mllewell)]

A few niggling observations:

After activating a purchase order, it does not automatically refresh to change the line item statuses and color. I've had to manually refresh the browser to see the change.

Show Originating Acquisition (Item Status): does not focus on the line item when you arrive on the purchase order. A red box around the line item would be helpful.

Invoicing from a PO. Selecting line items and creating an invoice should open the invoice in a new tab.

The Link to Provider from the PO should open provider record in a new tab.

[Tiffany Little (tslittle)]

Re: my #5 comment--I do still see that issue on PO#2, but I haven't been able to replicate it when I create my own purchase orders on the test server. So I'm hoping there's just something odd about PO#2.

I tested using the system level acqadmin perm of br1krush, and thus far I don't see anything else that I would consider a showstopper. I do agree with Mary's notes above--especially about the PO reloading upon activation--but wouldn't want to hold this back from getting into 3.10 just based on those lingering tweaks.

[Christine Morgan (cmorgan-z)]

I came across an issue that I see as a regression. In the dojo interface it is currently possible to use the batch updater in the purchase order to update the fund in selected line items after the purchase order has been activated. Our libraries use this to change the fund when they have accidentally used the wrong fund, have decided to use a different fund, or have uploaded a file with the wrong fiscal year set. In the new interface I see that the batch update option in the PO Actions menu is disabled after the purchase order has been activated so that it is now not possible to update funds. I realize that everything else in the batch updater, except possibly for the collection code, should be disabled after PO activation. The loss of the ability to update the fund, however, is an issue for us. If the batch updater could remain active after PO activation, with only the fund and possibly collection code enabled, that would be ideal but just leaving the batch update option active would give us what we have now.

[Jennifer Pringle (jpringle-u)]

I agree, if we can't update an incorrect fund after a PO has been activated that's definitely a regression.

[Tiffany Little (tslittle)]

+1, glad Christine caught that!

[Tiffany Little (tslittle)]

Per the AIG, we don't consider this particular regression a blocker for Sprint 4 getting into 3.10, but we *do* consider it a blocker for removing the PO/LI dojo interface(s).

[Bill Erickson (berick)]

Rebased branch pushed with Ruth and my sign offs:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1942220-ang-acq-sprint4-sign

I also added 2 commits, one with minor rebase fixes, and a second to update the catalog "View/Place Orders" action on the record detail page so it now goes to the new Angular version of this page -- which I'm assuming we want.

Otherwise, testing looks good on my end.

[Jane Sandberg (sandbergja)]

Merged for inclusion in 3.10. Thanks, Galen, Tiffany, Bill, Andrea, Ruth, and all testers and AIG participants!

I also added two follow-up commits

* Since this development migrates eg2's package-lock.json to lockfileVersion 2, I've taken the liberty of bumping the node version and migrating the other package-lock.json files. Without this change, whenever I run `npm i`, I get the message: "This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!" and the lockfile gets migrated back to lockfileVersion 1.
* Fixed a few issues identified by the new linter

[Jane Sandberg (sandbergja)]

I opened bug 1991487 to capture Christine's report in comment #8.