Hatch 2.12 Omnibus

[Bill Erickson]

As I'm working through various Hatch features and repairs, the code is becoming more entangled. Going to combine it all into one bug, one EG branch, and one Hatch branch. This should speed up development and testing.

https://bugs.launchpad.net/evergreen/+bug/1640255 (native messaging)
https://bugs.launchpad.net/evergreen/+bug/1642761 (print settings UI)
...

Rebased branches en route.

[Bill Erickson (berick)]

Hatch working branch:

http://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/collab/berick/lp1646166-native-messaging-2.12-omnibus

Evergreen working branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1646166-hatch-2.12-omnibus

The EG branch requires the Hatch branch.

[Bill Erickson (berick)]

Adding Hatch Windows Installer to the omnibus: https://bugs.launchpad.net/evergreen/+bug/1489919

[Bill Erickson (berick)]

As a heads up, I'm unable to print html content via Hatch after rebase to origin/master. Diagnosing..

[Bill Erickson (berick)]

Rebased to master and force-pushed to same branch.

Branch includes a fix for the remote html print issue in the previous comment. In summary, we want to avoid inserting the print CSS when printing remotely.

The commit includes some egPrint refactoring to create more obvious separation between remote vs. in-browser printing. Functionality should be the same w/ one exception, in the in-browser print code, I modified it to fail when the print CSS fails to load, w/ the assumption that printing w/o the print CSS (which would be the print data, plus the rest of the page) is probably not what the user wants.

[Bill Erickson (berick)]

Pushed a commit to the Hatch repo making OpenJDK the default Java handler for Linux. I went through various tests, including HTML printing, and everything seems to be OK using OpenJDK / OpenJFX.

With respect to Windows, the main barrier for using OpenJDK will likely be the installation. Red Hat maintains a Windows build, but I have not tested it: https://developers.redhat.com/blog/2016/06/27/openjdk-now-available-for-windows/

[Mike Rylander (mrylander)]

Bill,

Just to clarify one point about local printing, we recently made it possible to use CTRL-p to print the full page. There are bootstrap-in-chrome usability issues ATM, but being able to print what's on the screen was seen as important. We did that by lazily loading the print media css when using angular to print, and then unloading the css after the print is believed to be complete. Did that get reverted with this?

And, thanks for beating on printing!

[Bill Erickson (berick)]

Hey Mike, the code is all still there, I just had to rearrange it some so that parts of it (the CSS injection) did not apply when using Hatch. I can confirm control-p still prints content from the page and not the print div when control-p is used, consistent w/ webby.

The only change I made is when we attempt to use the print div (i.e. not control-p) from the browser, printing will fail if the print CSS cannot be found. In theory, this is a change that should go unnoticed.

[Bill Erickson (berick)]

Merged updates from master and pushed a commit to the EG Hatch branch:

1. Hatch now supports a al carte features instead of requiring all-or-none functionality. Supported features currently include printing, settings, and offline. (Note: offline handling pending merge of offline UI code).

2. Adds support for on-call setting keys. On-Call keys are those that can be set/get/remove'd from localStorage when Hatch is not availalable, even though Hatch is configured as the primary storage location for the key in question.

The initial target use case for on-call keys are those that allow the user to login and perform basic admin tasks (like disabling Hatch) even when Hatch is down. AKA Browser Staff Run Level 3.

3. egHatch no longer automatically falls through to local requests when a Hatch request fails. With the exception of on-call keys (above), either Hatch is used or local requests are used, depending on the configuration. The goal is to prevent any unintended and confusing blending of local and remote data. In other words, if Hatch is broken, it needs to be fixed or disabled for regular work flow to continue.

4. Hatch now has a dedicated UI under workstation administration.

5. Workstation admin splash page rearranged to take advantage of more horizontal space and avoid pushing so many options down the page.

[Bill Erickson (berick)]

Pushed commit to EG branch with "Copy Local Storage Settings To Hatch" and "Copy Hatch Settings To Local Storage" options in the Hatch admin UI. This is useful when first enabling or disabling settings storage in Hatch and as a testing/debug tool.

We may want to force "Copy Local Storage Settings To Hatch" when Hatch settings storage is enabled, or at least suggest it via confirmation dialog.

The operations in both direction are destructive, replacing any matching keys at the destination with values from the source.

[Bill Erickson (berick)]

Pushed a commit to the Hatch branch to support a new hatch.properties file for setting configuration values. Includes the ability to override the default data storage directory. Other settings will likely follow.

[Kyle Huckins (khuckins)]

Pushed a branch for the Hatch Windows installer here: http://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/collab/khuckins/lp1646166-windows-installer

The installer code will live in installer/windows, and instructions on requirements and how to compile in either Windows or Linux environments have been included in installer/windows/README.adoc

[Bill Erickson (berick)]

I have tested and signed-off on Kyle's (squashed) Windows installer code. I have merged the windows installer code into the Hatch working branch (collab/berick/lp1646166-native-messaging-2.12-omnibus).

Two important things to know about the current version of the Windows installer.

1. It makes no attempt to install a JRE. It only warns when it cannot find one. A JRE version 1.8 or higher (openjdk/openjfx, oracle, etc.) must be installed by the user.

2. The installer does not add the extension to the browser. That part must also be done manually.

I also pushed an updated to the INSTALL.adoc file so that the Windows installer is now the presumed installation method on Windows.

[Bill Erickson (berick)]

Just a heads up, I'm experiencing intermittent content script injection failures in Windows. I'm researching now and trying an alternate injection process that looks promising. More details soon.

[Bill Erickson (berick)]

Content script issues resolved by replacing our use of declarativeContent, which loads content scripts based on the content of the page, with a more traditional "content_scripts" configuration in the extension's manifest.json file. With content_scripts, we can configure the content script to be inserted before the DOM is rendered, ensuring it's always available to egHatch once loaded. Also, unlike declarativeContent, it loads consistently on windows/linux/mac.

Another side effect of this change is the user no longer has to interact with the extension to enable the permissions. They are enabled at extension install time.

I tested the new code on a variety of Chrome installs across OSes, with and without a google login. Broader testing required.

[Bill Erickson (berick)]

Attaching a copy of the Hatch Windows installer built from the latest code for convenience. Note that there are other steps in addition to just running the installer. See INSTALL.adoc for details.

Also note commits were pushed to both EG and Hatch branches for the changes mentioned in my previous comment.

[Bill Erickson (berick)]

With Kyle's help on the installer, I believe both code branches are ready for final review, testing, and sign-off. Adding pullrequest.

The EG code also has a number of UI improvements for those not using Hatch. For example, it better clarifies in some cases (e.g. print config) where Hatch is required and whether it's connected.

After this round of code is solidified, we can discuss packaging the extension for browser deployment w/o requiring dev tools.

[Bill Erickson (berick)]

Posting an updated Windows installer which includes fixes for removing hard-coded Java paths in the Windows bat file and fixes an issue where printColor and printQuality params were jumbled during printing.

[Bill Erickson (berick)]

Pushed a fix to the EG Hatch branch to fix Hatch printing when no content type is explicitly specified. It was defaulting to "html", when it should have defaulted to "text/html". This fixes problems raised in IRC over printing Items Out and Transit Slips.

[Bill Erickson (berick)]

Note to testers: Hatch will not render & print images served from non-trusted SSL hosts. (Presumably it would not load any such remote content...). Since Hatch fetches the content, and not the browser, clicking through SSL warnings in the browser has no effect.

If using a valid/trusted SSL cert is not an option, using 'http://' image, etc. links in print templates will also work. This produces a mixed-content warning in the JS console for me (in Chrome), but otherwise works fine.

There are other options that include mucking around in Java's cert handling, but I'd prefer to avoid those if possible.

[Mike Rylander (mrylander)]

Just as a PSA, here's how you can have all the good, real, valid, and (perhaps most importantly) free SSL certs you need:

https://letsencrypt.org/

[Bill Erickson (berick)]

Fixed another thinko in the Hatch java code. Fix pushed. Updated installer attached:

[Kathy Lussier (klussier)]

This branch is making a lot of progress.

I've verified that I can copy over local settings to the hatch storage and vice versa.

When I tell the client to store local settings in hatch, the workstation successfully uses the settings that are stored in hatch. When I remove that checkmark, the workstation returns to using the settings that are stored in the browser.

I can select printers to be used by default and those that should be used for receipts.

I have tested printing Items Out, Patron Bills, Holds and Transit slips, the holds pull list, and the holds shelf. In each case, the system prints to the default printer unless I choose to force a printer context through the receipt template.

All of the above looks great!

The problem I'm finding is that in many cases, the printout is either formatted improperly or is missing information that is included in the receipt template.

I have created a folder in Google drive with PDFs showing the printout both when hatch is used for printing and a companion printout for when hatch is not handling printing. I also included a doc with the Console message when hatch is handling the printing.

The folder is at https://drive.google.com/drive/folders/0B74gDMUDwDXqaC1UUDRQeXpNZGc?usp=sharing

I didn't test every interface with a receipt template, but here are my findings from a few interfaces:

The Holds Pull List and Holds Shelf are not printing out in the tabular format. Looking at the console messages, it appears to be trying to print in a tabular format, but it prints in one long paragraph.

The Bills receipt isn't printing anything beyond the 'Welcome' message in the header.

The holds slip prints the item barcode, but, otherwise, does not print the other bib, patron, and transaction information that should be in the receipt.

Thanks for all of your work on this Bill!

[Bill Erickson (berick)]

Thanks for the excellent documentation, Kathy.

I traced the problem back to how the Hatch code was extracting the compiled HTML content from the DOM. In some cases, particularly when print templates don't have a single root element or the root element contains id, style, etc. attributes, the final print content may be missing key elements.

Fix pushed to the EG working branch.

[Bill Erickson (berick)]

... Bills list, holds pull list, hold shelf, and checkin transit slips all print as expected for me in Hatch (and non-Hatch) now.

[Kathy Lussier (klussier)]

Many thanks for all of your work on hatch, Bill! The printing looks much better now.
I've signed off on the Evergreen branch and merged it to master for inclusion in 2.12.

[Kathy Lussier (klussier)]

And Bill has reported that the hatch branch has been merged to the hatch master repo.