| Time |
Nick |
Message |
| 00:46 |
|
sandbergja joined #evergreen |
| 03:24 |
|
sandbergja joined #evergreen |
| 05:31 |
|
rfrasur joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 08:00 |
|
Dyrcona joined #evergreen |
| 08:11 |
|
rfrasur joined #evergreen |
| 08:32 |
|
jvwoolf joined #evergreen |
| 08:39 |
|
mantis1 joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:50 |
|
jvwoolf joined #evergreen |
| 09:00 |
|
remingtron joined #evergreen |
| 09:40 |
|
sandbergja joined #evergreen |
| 09:50 |
|
jvwoolf joined #evergreen |
| 09:52 |
|
rjackson_isl joined #evergreen |
| 10:16 |
mmorgan |
Anybody heard of a situation where Chrome on two different workstations shows a different due date for the same checkout? |
| 10:17 |
mmorgan |
The due date in the db is 2020-01-02 00:59:59-05 (another story there), one workstation showed 1-01-2020, another showed 1-02-2020. |
| 10:18 |
mmorgan |
Much cache clearing, restarting, etc., did not change what was displayed. |
| 10:18 |
mmorgan |
The actual due date should have had the timestamp of midnight, but wondering what would cause the different display. |
| 10:19 |
miker |
mmorgan: yes. Most likely, either the client computer timezones are different, or the timezone library setting for the workstations on the two computers are different |
| 10:23 |
* mmorgan |
can ask the library to check the timezone, but still wonders why timezone would cause the due date to display as earlier than it actually is. Is there a bug? |
| 10:23 |
* mmorgan |
goes to look |
| 10:24 |
JBoyer |
mmorgan, the item was likely checked out on a machine with a different timezone set or incorrect timezone ou setting. |
| 10:25 |
JBoyer |
I'm assuming the one that shows the date as 2020-01-01 has the problem, since it's in the same timezone as the circ (on that machine, it IS due at 23:59:59, because it's not in GMT-5) |
| 10:29 |
* mmorgan |
attempts to process that with insufficient caffeine |
| 10:30 |
miker |
mmorgan: for when you are appropriately caffeinated: https://bugs.launchpad.net/evergreen/+bug/1705524 |
| 10:30 |
pinesol |
Launchpad bug 1705524 in Evergreen "Honor timezone of the acting library where appropriate" [Wishlist,Fix released] |
| 10:31 |
miker |
(main takeaway, a top level lib.timezone YAOUS may help prevent this in the future) |
| 10:31 |
miker |
if you don't have that set already |
| 10:33 |
JBoyer |
mmorgan What I mean is that I think the machine that shows it due on the first is in Central Time. That timestamp in Central Time is 2020-01-01 23:59:59-06, but in Eastern Time it's 2020-01-02 00:59:59-05 |
| 10:34 |
JBoyer |
But like miker mentioned, just setting the timezone OU to America/New_York at the top consortium level should make this situation a lot harder to encounter. :) |
| 10:34 |
JBoyer |
(I'm not going to say impossible, because come on, computers.) |
| 10:35 |
mmorgan |
Ok, getting it, so the db stores the due date in in Eastern Time. If we set the ou setting at Consortium, it will override whatever timezone setting the workstation has? |
| 10:35 |
JBoyer |
It should, yes |
| 10:36 |
mmorgan |
Ok, thanks! |
| 10:36 |
miker |
well, the problem is the initial checkout set the due date in central time (or whatever) |
| 10:36 |
JBoyer |
Yeah, the only way to fix that circ is to just nudge the time by hand, but that setting will stop new ones from showing up. |
| 10:37 |
mmorgan |
Ok, gotcha, I know I have to fix circs. |
| 10:37 |
miker |
so that circ is probably going to be wonky regardless. but(!), that setting should make the display /consistent/ for the circ, even if everything shows jan 2 |
| 10:37 |
* mmorgan |
goes to get caffeine and follow up with the library |
| 10:37 |
mmorgan |
miker++ |
| 10:37 |
mmorgan |
JBoyer++ |
| 10:44 |
* Dyrcona |
looks at db upgrade from 3.2.8 to 3.4.1 and that aged money billing and aged money payment looks like it might cause some issues similar to the fixes for auto_renewal. |
| 10:52 |
* Dyrcona |
thinks it might not be so bad after all, but it remains to be seen. |
| 11:14 |
* mmorgan |
is still wondering about poprel if miker has any more insight since http://irc.evergreen-ils.org/evergreen/2019-12-11#i_430114 |
| 11:19 |
miker |
mmorgan: I won't have time today to really dig into it, but I'll be looking at search stuff next week, so I'll be in the right brain space then (sorry) |
| 11:22 |
mmorgan |
Ok, thanks! will keep poking test systems in the meantime |
| 12:08 |
|
Christineb joined #evergreen |
| 12:10 |
mantis1 |
Got a question regarding Hatch. My supervisor got an email from an employee asking how to enable the Hatch extension on her browser on her Mac and she led her to these instructions: https://git.evergreen-ils.org/?p=working/Hatch.git;a=blob;f=INSTALL.adoc;h=2de29bb97135142c4a014fcbf32ef04287e01871;hb=ff8eafb089f61930cdf34c374020c1d3eacbd9fb Thinking about it, most library staff who need to enable Hatch on Macs probably wo |
| 12:10 |
mantis1 |
to execute these instructions without some guidance or having someone familar with git to do it. Has anyone found an alternative that has helped? |
| 12:14 |
|
sandbergja joined #evergreen |
| 12:16 |
berick |
mantis1: i'm not aware of any work done to improve the install process for Hatch on macs (or linux). i agree there is much room for improvement there. |
| 12:17 |
mmorgan |
mantis1: Does the employee really need to be using hatch? Will printing through the browser suffice? |
| 12:22 |
mantis1 |
mmorgan: The employee definitely has that option, but I don't know the reasons why she asked if there was some sort of Hatch installer for Mac. |
| 12:22 |
mantis1 |
Luckily we have the browser system that's reliable, but we would like to know if there are any further developments we don't know about or possible alternatives besides a browser. |
| 12:25 |
|
sandbergja_ joined #evergreen |
| 12:28 |
mmorgan |
mantis1: berick provided some pointers here: http://irc.evergreen-ils.org/evergreen/2019-05-08#i_405323 You may have seen that already. |
| 12:32 |
mantis1 |
mmorgan: thank you very much for the link! |
| 12:32 |
mmorgan |
yw! |
| 13:02 |
|
collum joined #evergreen |
| 13:37 |
|
khuckins joined #evergreen |
| 13:41 |
pinesol |
[evergreen|Lynn] Docs: Glossary Added - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5609fc4> |
| 13:41 |
pinesol |
[evergreen|lfloyd] Docs: Added linkages, and additonal terms. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fec9789> |
| 14:30 |
|
sandbergja_ joined #evergreen |
| 15:03 |
remingtron |
alynn26++ abneiman++ sandbergja++ #docs glossary |
| 15:05 |
alynn26 |
Take it apart, add to it. Enjoy it, |
| 15:08 |
|
mmorgan1 joined #evergreen |
| 15:26 |
|
mantis1 left #evergreen |
| 16:00 |
abneiman |
alynn26++ # yay glossary |
| 16:01 |
abneiman |
sandbergja++ #endless patience with git lessons :) |
| 16:42 |
|
mmorgan joined #evergreen |
| 16:46 |
|
cesardv joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:34 |
jeffdavis |
too early to be definitive, but it's looking like >90% reduction in open-ils.actor.ou_setting.ancestor_default.batch requests with the fix for bug 1848550, very encouraging |
| 17:34 |
pinesol |
Launchpad bug 1848550 in Evergreen "Cache settings more aggressively in web client" [Undecided,New] https://launchpad.net/bugs/1848550 |
| 18:00 |
pinesol |
News from qatests: Failed Building the AsciiDoc output formats <http://testing.evergreen-ils.org/~live/test.81.html#2019-12-12T18:00:15,895945080-0500 -0> |
| 18:06 |
|
cmalm joined #evergreen |
| 18:09 |
|
remingtron joined #evergreen |
| 20:39 |
|
sandbergja joined #evergreen |
