| Time |
Nick |
Message |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:28 |
|
rjackson_isl_hom joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 08:25 |
|
rfrasur joined #evergreen |
| 08:32 |
|
mantis1 joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 09:06 |
|
JBoyer joined #evergreen |
| 09:18 |
|
jvwoolf joined #evergreen |
| 10:30 |
|
Keith-isl joined #evergreen |
| 10:35 |
|
rjackson_isl_hom joined #evergreen |
| 10:40 |
|
rjackson_isl_hom joined #evergreen |
| 11:42 |
|
Christineb joined #evergreen |
| 11:51 |
miker |
@later tell Dyrcona no, currently not possible to say "ORDERY BY ... NULLS LAST" but ... it would be nearly trivial to add a peer to "direction" called, say, "nulls" that checks for "first" or "last" values and does that |
| 11:51 |
pinesol |
miker: The operation succeeded. |
| 12:05 |
mmorgan |
phasefx: re: cover image uploader discussion yesterday. Here's a public link to some images: |
| 12:06 |
mmorgan |
https://drive.google.com/drive/folders/1_SrHH7GZPVwdhCZLquVmn9cw3q3saxco?usp=sharing |
| 12:06 |
mmorgan |
On my test system, of the six files, beebe and the two starting with test all work, cones and the two starting with LOT fail. |
| 12:28 |
|
Lew70 joined #evergreen |
| 12:36 |
|
jvwoolf left #evergreen |
| 12:44 |
|
rjackson_isl_hom joined #evergreen |
| 13:10 |
|
jihpringle joined #evergreen |
| 13:31 |
|
Dyrcona joined #evergreen |
| 13:32 |
Dyrcona |
miker: That's what I was thinking. I'll implement it and open a Lp bug when/if the mood strikes. |
| 13:53 |
|
jihpringle joined #evergreen |
| 14:19 |
Keith-isl |
Afternoon, folks! Bit of a long shot, but out of curiosity, does anyone have any sites that are using Chromebooks for circulation workstations? I don't have one to play with, and a migrating site is curious about any considerations for using them (especially when it comes to printing). |
| 14:20 |
jeff |
you will not be able to run Hatch on a Chrome OS device. |
| 14:20 |
jeff |
I would not expect a happy printing experience to a receipt printer. |
| 14:21 |
csharp_ |
Keith-isl: we have a few libraries piloting Chrome OS for circ stations - I can get you a contact if you want |
| 14:21 |
jeff |
For a library that does no receipts, hold slips, or transit slips, or does a few but is okay with a printer prompt and printing them on the default printer (say, letter sized paper to a network printer that the Chrome OS device can print to), great. |
| 14:22 |
jeff |
Also, keep in mind that since you don't have Hatch, your workstation association is going to be per-user-per-device. |
| 14:22 |
Keith-isl |
jeff Yeah, lack of Hatch was my first red flag. :\ I've bypassed Hatch and just used silent printing in Chrome to do things, but that doesn't feel like a great strategy. |
| 14:22 |
jeff |
there will be no "this device is always workstation XYZ no matter what user logs in" |
| 14:23 |
jeff |
while we've brainstormed a bunch of printing options that involve networked receipt printers or an intermediate host that Evergreen can send the job to without needing Hatch, I'm not aware of any implementations of that kind of thing yet. |
| 14:23 |
Keith-isl |
csharp_ That would be fantastic if you could pass along |
| 14:28 |
Keith-isl |
I salute any soul brave enough to risk the sanity hit of considering any network receipt printer related options. :) |
| 14:32 |
jeff |
yeah... they're neat when they work, but the number of network receipt printers that I can say I'm a fan of is... zero. |
| 14:32 |
Keith-isl |
I treat them with the same appreciation and wariness as a coiled rattlesnake. |
| 14:35 |
Keith-isl |
Could you elaborate more on the workstation association aspect of Hatch? I know that a lot of workstation information is saved in Hatch, but I'm not sure I'm aware of the implications of a Hatch-ed vs. Hatch-less workstation. In my angled viewpoint, different Windows logins wouldn't preserve workstation information even if Hatch was installed, yeah? |
| 14:36 |
Keith-isl |
For Chromebooks I'm assuming it would be similar - each user is essentially logging into their own Chrome profile that would have a different set of workstation(s) saved. |
| 14:37 |
jeff |
If you set up Hatch so that it stores settings in %ProgramData%, on a Windows workstation any users logging in to the staff client in a browser that has the Hatch browser plugin enabled should be presented with a list of workstations that all other users on that machine see. If they're creating a new workstation, it should default to the Windows name of the computer (because Hatch supplies this data). |
| 14:37 |
jeff |
Whatever default workstation is set, will be used by default. |
| 14:38 |
jeff |
Since a Chrome OS device will not have Hatch the Java application installed, all information on workstations will be stored in the browser local storage for each user. |
| 14:38 |
jeff |
If you are logging in to a specific Chrome OS device for the first time, you will have no workstations registered. |
| 14:40 |
Keith-isl |
That's interesting - I didn't realize that Chrome could store workstations across different Windows logins. |
| 14:40 |
jeff |
On subsequent logins, you'll have the workstations that you've configured under your Chrome OS account... unless the Chrome OS device is configured to NOT store/preserve local profile data, in which case you'll need to re-register a workstation each and every time you log in to Evergreen after logging into Chrome OS. |
| 14:40 |
jeff |
Yes, that's one of the primary advantages of Hatch, other than the printing aspects. |
| 14:41 |
jeff |
(at least, as I see it) |
| 14:41 |
Keith-isl |
I always just assumed Hatch provided some level of protection against staff blowing away workstations by clearing the entire cache. |
| 14:42 |
jeff |
but you may still have to go out of your way to make it work. I think the hatch.properties file TRIES to store settings in %ProgramData%\Hatch by default, but I know at one point the permissions on that file weren't correct, and the hardcoded default was to store in the user profile. |
| 14:43 |
Keith-isl |
+++ I have learned much this day. Thank you! |
| 14:44 |
jeff |
Also, something you'll run into in a mixed Chrome OS / Chrome on other operating systems environment: if your users have the Hatch browser plugin installed and enabled, trying to log in to Evergreen on Chrome OS (where Hatch the Java app is not installed) will likely fail / lead to partially-loaded staff interfaces with Hatch-related errors in the browser console. |
| 14:44 |
jeff |
I think (but can't recall if we've tested) that the Hatch extension being installed/enabled is something that syncs by default when you're logged into Chrome with sync enabled. |
| 14:45 |
Keith-isl |
Oh yeah, we've definitely run across that before with new Windows machines and users logging into Chrome accounts before installing the Hatch Windows app. >< |
| 14:45 |
jeff |
The long term solution there is to have the Hatch browser extension fail more gracefully when Hatch the Java app isn't available. |
| 14:49 |
Keith-isl |
Yeah, that would be ideal - the Hatch extension breaking things if it can't communicate with the Java app has been a source of many tickets. |
| 16:18 |
* Dyrcona |
dislikes some of the choices made in BOOPAC. It's more difficult to customize than was TTOPAC. |
| 16:19 |
|
jihpringle joined #evergreen |
| 16:24 |
Dyrcona |
Adding 856 subfield 3 to the record summary is going to require major surgery, as an example. |
| 16:56 |
Keith-isl |
Did we miss the opportunity to retroactively name the Template TOolkit OPAC "TTOOPAC?" |
| 16:56 |
Keith-isl |
I feel like an opportunity was missed. |
| 16:56 |
mmorgan |
:) |
| 16:56 |
Keith-isl |
"I'm telling you, TTOOPAC is still alive out there." |
| 17:02 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:29 |
|
jihpringle joined #evergreen |
| 20:49 |
|
JBoyer joined #evergreen |
