MARC Batch Edit Angular Port

[Bill Erickson]

Evergreen 3.5 / Wishlist

Port the MARC Batch Edit UI to Angular.

Some API tweaks will be made to support the new UI, e.g. bypassing the server-generated HTML components.

I'd also like to propose a new option to the batch processing API to support processing each record within its own transaction, instead of a single transaction for the batch. I've had cases where long-running updates result in locked rows in the database, preventing other MARC editing actions from completing.

I'm not planning to address all of the bugs related to MARC Batch Edit, since most of them require other back-end changes, but bug #1822376 will be addressed.

[Bill Erickson (berick)]

WIP

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1880726-marc-batch-angular

[Bill Erickson (berick)]

Adding pullrequest. From the release notes:

Ports the MARC Batch Edit interface to Angular. Port includes a new feature (Per-Record Transactions) which allows for large batches to be processed with each bib record in its own transaction. This mitigates potential conflicts with other cataloging activities. This setting is saved in a new workstation preference.

[Jane Sandberg (sandbergja)]

Thanks for demoing this today, Bill. From the demo earlier, I think it looks really good! I'm curious, though: is there any benefit to retaining the old all-in-one-transaction behavior? I'd propose simply using the new per-record transactions always, rather than asking catalogers to choose between the two.

If there are benefits to retaining the old behavior for smaller batches, maybe the API could be smart enough to make the determination of how to handle transactions (if number_of_records_to_change < some_configurable_number_with_a_sensible_default). It just seems to me like an implementation detail that catalogers shouldn't have to learn about or decide on.

[Bill Erickson (berick)]

Jane, I could imagine a future enhancement where we allow batches of records to be updated in a dry-run mode, where the modified records are returned to the UI, then the transaction is rolled back. Beyond that, I don't see any particular value in processing the records in monolithic transaction.

For now, I think it would be fine to assume per-record transactions and hide that option from the UI.

[Mike Rylander (mrylander)]

Bill, do you want to force the record-per-transaction mode? I'm happy to review, but I think you probably already have the "how" in your head for this.

Thanks!

[Bill Erickson (berick)]

I'm on it.

[Bill Erickson (berick)]

Rebased branch with per-transaction updates happening by default under the covers.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1880726-marc-batch-angular-v2

[Mike Rylander (mrylander)]

Thanks, Bill.

I've pushed a signoff branch with a followup commit to make use of the eg.auth.token cookie in preference to the ses cookie, which is itself prefered to the ses CGI parameter. A stale ses cookie was stopping things from working until I deleted it from the browser, so I thought preferring the new cookie name would be good here. Branch at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1880726-marc-batch-angular-v2-signoff-cookie_followup

[Bill Erickson (berick)]

A great addition, thanks Mike. Merged to master for 3.6.