AngJS Always Tries To Use Hatch For Printing

[Bill Erickson]

Evergreen 3.4+

Part of the code for bug #1830391 moved the "use hatch for printing" check away from local storage and into a workstation setting. Several spots in the AngJS code were not properly updated to reflect the now-asynchronous nature of the test, resulting in all print attempts trying to use Hatch.

Patch forthcoming.

[Bill Erickson (berick)]

Fixes pushed:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1858118-angjs-print-sans-hatch

From commit:

Teach code asking Hatch whether printing is enabled to properly handle the asynchronous response of the setting which now exists as a workstation setting instead of a localStorage setting.

Related, if Hatch is unavailable, use browser printing regardless of the hatch printing workstation setting.

Additionally update the "reprint last" handling to store the last_printed value in localStorage instead of attempting to save its value as a workstation setting.

[Dan Scott (denials)]

Thanks for the quick work, Bill!

My initial test of this branch, applied to a clone of our production instance which is tracking rel_3_4, suggests that it resolves the issues we experienced. I can print call number labels without having to have Hatch installed.

I plan to test this more thoroughly tonight.

[Dan Scott (denials)]

I applied the code to our development 3.4-based server, confirmed that it restores the ability to use browser-based printing, and then applied it to our production 3.4-based server.

I have signed off on this branch at working/user/dbs/lp1858118-angjs-print-sans-hatch-signoff / https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/lp1858118-angjs-print-sans-hatch-signoff

[Galen Charlton (gmc)]

Tested and pushed to master and rel_3_4. Thanks, Bill and Dan!