| Time |
Nick |
Message |
| 05:34 |
|
book` joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Log Output: osrfsys.log <http://testing.evergreen-ils.org/~live//archive/2020-09/2020-09-29_04:00:04/test.78.html> |
| 07:00 |
|
agoben joined #evergreen |
| 07:26 |
|
rjackson_isl_hom joined #evergreen |
| 07:28 |
JBoyer |
I think I figured out what's up with the failed log output errors, we were no longer ignoring the intentional error from 08-lp1366964-libdbi-error.t because the statement that's logged changed with the hopeless holds enhancement. |
| 08:02 |
|
mantis1 joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:46 |
|
rfrasur joined #evergreen |
| 09:00 |
|
Dyrcona joined #evergreen |
| 09:02 |
Dyrcona |
This morning's fun: A self check with the timezone set incorrectly has revealed that if a circulation is due between 2:05 AM and 3:05 AM, it will not be auto-renewed with our current delay settings of -1 minute to -23 hours. |
| 09:04 |
Dyrcona |
Also, because we run daily jobs at 3:05 AM. Any other time, it would be a different hour of the day. |
| 09:06 |
Dyrcona |
Those are the default values. Should I bug this? |
| 09:09 |
|
dbwells joined #evergreen |
| 09:14 |
Dyrcona |
I wonder if I should set it to -24 hours or -23:59:00? |
| 09:14 |
Dyrcona |
Probably, the former. |
| 09:15 |
JBoyer |
Dyrcona, sounds like it would benefit from lp1891369 so you could potentially set it to -48 or something like that. |
| 09:16 |
JBoyer |
That way people also aren't stuck waiting until the wee hours the morning their stuff is due to find out whether things are due today or in two weeks... |
| 09:17 |
JBoyer |
uh, bot? bug 1891369 |
| 09:17 |
pinesol |
Launchpad bug 1891369 in Evergreen "Circulation renewals near the due date should be extended" [Wishlist,New] https://launchpad.net/bugs/1891369 |
| 09:22 |
mmorgan |
FWIW we autorenew early in the morning of the due date so patrons don't lose that day. |
| 09:26 |
Dyrcona |
We used the default settings because "works for me." Until someone "decided" that their self check was in the Pacific time zone. |
| 09:27 |
Dyrcona |
I'm gonna bug this. |
| 09:29 |
Dyrcona |
We can at least change the default in 950.data.seed-values.sql. Though I could write an upgrade script with some smarts to it. |
| 09:31 |
* mmorgan |
would say that the autorenewal delay and max validity shoud cover a 24 hour period, but the actual settings should depend on when it runs in cron. Haven't looked at the example cron. |
| 09:32 |
Dyrcona |
mmorgan: It won't matter when it runs. The default values give a 59 minute "dead spot" every day. |
| 09:32 |
Dyrcona |
The dead spot just shifts depending on run time. |
| 09:33 |
Dyrcona |
Or, is it a 61 minute dead spot. I'll have to look at the trigger code and do the math. |
| 09:35 |
mmorgan |
So the default values don't cover a 24 hour period. Does sound bugworthy to me. Though I do wonder how many circs that have a due time other than 23:59:59 would be autorenewable. |
| 09:36 |
Dyrcona |
In our {specific, pathological} case, more than 6 on one day. |
| 09:37 |
Dyrcona |
Pretty much anything checked on this 1 self check at this 1 library. |
| 09:38 |
mmorgan |
But the timezone was an error, right? I was thinking hourly types of loans. |
| 09:38 |
Dyrcona |
I think it would be an issue in a large consortium that spans multiple time zones. |
| 09:38 |
mmorgan |
True! |
| 09:39 |
Dyrcona |
Yeah, hourly loans shouldn't be affected. |
| 09:42 |
Dyrcona |
Now, to ferret out where the delay fields are used in the code. |
| 09:48 |
Dyrcona |
Talk about an obsolete comment: "# we may need to do some work to backport this to 1.2" |
| 09:49 |
Dyrcona |
Yeah, I think the delay should be "-24:01:00" if max_delay is "-00:01:00" |
| 09:50 |
Dyrcona |
I wonder if that syntax works.... I know that's how Pg displays it. |
| 09:52 |
Dyrcona |
Hm... I think just 24 hours is OK.... "between" is inclusive, right? |
| 09:53 |
Dyrcona |
Eh... no....Still need the extra minute for the 59 seconds. |
| 09:54 |
Dyrcona |
Thanks, rubber ducky! |
| 09:56 |
Dyrcona |
I suppose I could run some autorenewals on my test db before I make the change in production. ;) |
| 09:59 |
|
dbwells joined #evergreen |
| 10:05 |
|
stephengwills joined #evergreen |
| 10:05 |
Dyrcona |
Hmm... action_trigger may be slower on Pg 12 than on 9.6, too..... |
| 10:05 |
Dyrcona |
Seems to be taking quite a while to gather the data. |
| 10:06 |
* JBoyer |
returns to read scrollback... |
| 10:08 |
jeff |
scroll, scroll, scroll your... nothing quite IRC or Evergreen-related rhymes with boat... |
| 10:08 |
JBoyer |
mmorgan, Yeah, I imagine nearly everyone renews things in the wee hours of the morning they're due, but if that bug were addressed that would no longer be necessary. :) (There's a similar one about renewing things too soon too that could probably be rolled up together) |
| 10:09 |
Dyrcona |
scroll, scroll, scroll your back... ? |
| 10:09 |
mmorgan |
Quote? |
| 10:09 |
Dyrcona |
Don't mind me. *walks off whistling* |
| 10:12 |
|
terranm joined #evergreen |
| 10:18 |
|
terranm31 joined #evergreen |
| 10:19 |
|
terranm joined #evergreen |
| 10:24 |
jeff |
mmorgan++ works for me! |
| 10:34 |
mmorgan |
scroll, scroll, scroll your @quote random |
| 10:34 |
mmorgan |
nope. |
| 10:40 |
pinesol |
[evergreen|Jason Boyer] LP1849212: (follow-up) Don't use group ids in upgrade scripts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=72c71e7> |
| 11:06 |
Dyrcona |
With about 700 out of about 30,000 autorenewals completed on my test db, I don't see anything crazy, yet. |
| 11:08 |
Dyrcona |
I think I found another machine with the wrong timezone: 2020-09-30 00:59:59-04 |
| 11:09 |
Dyrcona |
I see more from the one that one that is set to Pacific time. The new delay is picking them up. |
| 11:11 |
|
nfBurton joined #evergreen |
| 11:12 |
|
jihpringle joined #evergreen |
| 12:17 |
|
stephengwills joined #evergreen |
| 12:19 |
terranm |
Bug Squashing Week results are at: https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2020-09 --- it was the second most successful bug squashing week we've ever had! (Based on number of patches signed off.) |
| 12:19 |
mmorgan |
terranm++ |
| 12:22 |
|
stephengwills joined #evergreen |
| 12:25 |
agoben |
terranm++ bug_squashers++ |
| 12:25 |
terranm |
bug_squashers++ indeed |
| 12:26 |
terranm |
csharp++ gmcharlt++ Bmagic++ JBoyer++ for providing sandboxes and loading patches! |
| 12:26 |
csharp |
terranm++ # wrangling |
| 12:27 |
terranm |
berick++ for a whopping 9 new commits |
| 12:27 |
csharp |
@who was whopping berick's 9 new commits? |
| 12:27 |
pinesol |
jeff_ was whopping berick's 9 new commits. |
| 12:28 |
csharp |
@praise bug squashers |
| 12:28 |
* pinesol |
I come to praise bug squashers, not to bury them. |
| 12:28 |
csharp |
@blame the bugs |
| 12:28 |
pinesol |
csharp: the bugs was monkeying around too much on the prod servers! |
| 12:28 |
rfrasur |
lol |
| 12:28 |
csharp |
@blame [band] for the bugs caused by [someone] |
| 12:28 |
pinesol |
Single Large Table HAXORED csharp's SERVERZ!!!! for the bugs caused by pastebot |
| 12:43 |
Bmagic |
terranm++ |
| 12:53 |
terranm |
ha! |
| 13:48 |
|
jamesrf joined #evergreen |
| 13:48 |
|
laurie joined #evergreen |
| 13:48 |
|
ejk joined #evergreen |
| 13:48 |
|
Glen joined #evergreen |
| 13:50 |
|
eby joined #evergreen |
| 13:50 |
|
troy__ joined #evergreen |
| 13:53 |
|
jeffdavis joined #evergreen |
| 13:53 |
|
Christineb joined #evergreen |
| 14:00 |
|
kip joined #evergreen |
| 14:31 |
|
collum joined #evergreen |
| 14:42 |
Dyrcona |
Hm. |
| 14:42 |
* Dyrcona |
wonders why exactly half of the events were processed, unless I somehow got two of each event created. |
| 14:45 |
Dyrcona |
Yeahp. That's what happened. The drones from that first a/t runner that I stopped must have kept going. I *think* I have encountered that before. |
| 14:47 |
Dyrcona |
No harm done. Just testing something on a development system. |
| 14:49 |
|
mantis1 left #evergreen |
| 15:04 |
|
terranm joined #evergreen |
| 15:29 |
|
BAMkubasa joined #evergreen |
| 15:31 |
BAMkubasa |
is someone backdates a checkin, the time the item is scanned is action.circulation.checkin_time but the time they backdated the checkin to is action.circulation.stop_fines_time ? |
| 15:32 |
BAMkubasa |
sorry meant: |
| 15:32 |
BAMkubasa |
is someone backdates a checkin, the time the item is scanned is action.circulation.checkin_scan_time but the time they backdated the checkin to is action.circulation.stop_fines_time ? |
| 15:35 |
terranm |
That sounds right |
| 15:36 |
terranm |
mmorgan: Bill's latest update is loaded onto terran-master |
| 15:36 |
mmorgan |
Also, action.circulation.checkin_time would be the backdated date. |
| 15:36 |
mmorgan |
terranm++ Thanks! |
| 15:37 |
terranm |
I only loaded the newest commit on top of the ones that I loaded on Friday, so if there is anything not working I might need to reload them all. Let me know! |
| 15:38 |
BAMkubasa |
Thanks! |
| 16:23 |
|
sandbergja joined #evergreen |
| 16:41 |
|
dbriem joined #evergreen |
| 16:41 |
Bmagic |
If I want to intentionally force Evergreen into the offline mode, what should I need to do. I've tried to edit my hosts file so that the domain name resolves to a bogus IP address. The browser just shows "Connection timed out" instead of the offline page... We are trying to make an offline site while we go offline but want the staff client to still be able to use offline |
| 16:43 |
|
dbriem joined #evergreen |
| 16:46 |
terranm |
Bmagic: I think I'm missing something - if you're going to be offline, it should just go to the offline client automatically. |
| 16:47 |
Bmagic |
that's what I thought too :) - and I've seen it happen but now that I want* it to happen, it won't. What is the magic server response code? 404? |
| 16:47 |
terranm |
Oh, I'm not sure |
| 16:47 |
mmorgan |
Bmagic: Or, can folks go to offline directly via the link? https://<hostname>/eg/staff/offline-interface |
| 16:48 |
terranm |
^ that's what I do when I need to test it |
| 16:49 |
Bmagic |
I want it to go there automatically (like it's suppose to do) - still trying some stuff |
| 16:51 |
Bmagic |
perhaps when I change the hosts file (and the browser needs to recognize) - I need to use the CTRL+SHIFT+R (hard refresh) combo to make the browser re-read the hosts file, I get the connection timed out. Perhaps it's also clearing it's web app cached page for offline? |
| 16:52 |
mmorgan |
berick: One question about bug 1889128, was the intent to clear the patron info after a hold is successfully placed as mentioned in comment #3? |
| 16:52 |
pinesol |
Launchpad bug 1889128 in Evergreen "Angular Staff Catalog: Place Another Hold & Multi-Holds" [Undecided,Confirmed] https://launchpad.net/bugs/1889128 |
| 16:55 |
berick |
mmorgan: hm, kinda seems like it from my reply. is that not the case? |
| 16:56 |
mmorgan |
No, the patron info remains after the hold is placed. |
| 16:58 |
berick |
the LP that won't die! do you agree it should be cleared? i almost think it would make more sense to 'select' the patron barcode in the form so that subsequent scans can easily replace it |
| 16:59 |
berick |
instead of just clearing the data, but i can't really say |
| 16:59 |
berick |
either way i can push a fix soon |
| 17:03 |
mmorgan |
I want to say that the screen should go back to the same state as when the user first selects Place Hold from the catalog. I wonder if terranm can offer an opinion? |
| 17:04 |
terranm |
<reading up> |
| 17:04 |
mmorgan |
My concern with the screen not clearing is the possibility of duplicate holds. This screen is heavily used by staff at our libraries and I feel like it's so close. |
| 17:05 |
terranm |
I would agree that the patron info should be cleared after the successful hold placement. We wouldn't typically place another hold on the same item for the same patron. |
| 17:06 |
terranm |
(Except for the book club exception where we have the dropdown to place multiple holds at once for the same person/title) |
| 17:06 |
mmorgan |
Our use cases are similar, thanks for weighing in terranm! |
| 17:07 |
terranm |
Sure thing! |
| 17:16 |
pinesol |
Showing latest 5 of 9 commits to Evergreen... |
| 17:16 |
pinesol |
[evergreen|Felicia Beaudry] docs: updates to holds documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=da19fc1> |
| 17:16 |
pinesol |
[evergreen|Andrea Buntz Neiman] docs: adding new image files for Hopeless Holds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7f61180> |
| 17:16 |
pinesol |
[evergreen|Angela Kilsdonk] docs: Acquisitions Providers documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d1f4d82> |
| 17:16 |
pinesol |
[evergreen|Angela Kilsdonk] docs: OPAC Email Print documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a5ceafc> |
| 17:16 |
pinesol |
[evergreen|Angela Kilsdonk] docs: Curbside Pickup documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=29b0eff> |
| 17:34 |
|
mmorgan left #evergreen |
| 17:43 |
|
dbriem joined #evergreen |
| 17:53 |
berick |
thanks for feedback terranm and mmorgan |
| 17:53 |
* berick |
push a patch tomorrow |
| 17:53 |
terranm |
Thanks for continuing to chip away at it berick++ |
| 17:55 |
|
Glen joined #evergreen |
| 17:55 |
|
kip joined #evergreen |
| 17:55 |
|
ejk joined #evergreen |
| 17:55 |
|
jamesrf joined #evergreen |
| 17:55 |
|
laurie joined #evergreen |
| 17:56 |
|
eby joined #evergreen |
| 17:56 |
|
troy__ joined #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:24 |
|
rjackson_isl_hom joined #evergreen |
| 19:37 |
|
stephengwills joined #evergreen |
| 19:47 |
|
stephengwills_ joined #evergreen |
| 20:46 |
|
yboston joined #evergreen |
| 22:18 |
|
stephengwills_ joined #evergreen |
| 22:21 |
|
stephengwills_ left #evergreen |
| 22:59 |
|
mrisher joined #evergreen |
