| Time |
Nick |
Message |
| 05:12 |
|
sleary joined #evergreen |
| 07:17 |
|
kworstell-isl joined #evergreen |
| 07:45 |
|
BDorsey joined #evergreen |
| 08:12 |
|
sleary joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:23 |
|
mantis1 joined #evergreen |
| 09:42 |
|
kworstell_isl joined #evergreen |
| 10:05 |
|
dguarrac joined #evergreen |
| 10:11 |
|
Guest82 joined #evergreen |
| 10:11 |
Guest82 |
Hello and good bye. :) |
| 10:12 |
|
sleary joined #evergreen |
| 10:15 |
|
kworstell-isl joined #evergreen |
| 10:35 |
|
BDorsey joined #evergreen |
| 10:35 |
|
redavis joined #evergreen |
| 10:44 |
|
sleary joined #evergreen |
| 10:51 |
|
redavis_reloaded joined #evergreen |
| 11:27 |
|
Christineb joined #evergreen |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:07 |
|
smayo joined #evergreen |
| 12:10 |
|
BDorsey joined #evergreen |
| 12:16 |
|
jihpringle joined #evergreen |
| 13:01 |
|
dmoore joined #evergreen |
| 13:02 |
Dyrcona |
Grr. I hit this 'ERROR: retention_interval requires max_delay' on one event but not others. |
| 13:02 |
Dyrcona |
They all have the same retention_interval so it must be something about the hook, I guess. |
| 13:04 |
Dyrcona |
Hrm... It says the hook is passive, but I'm copying values from another event with the same hook, and it doesn't have a max_delay.... |
| 13:06 |
Dyrcona |
And the hook doesn't exist.... |
| 13:06 |
* Dyrcona |
checks for typos. |
| 13:07 |
Dyrcona |
OK. It's an odd one: au.sms_text.test. That dot between text & test is usually a comma, and I should have copy and pasted instead of typing. |
| 13:07 |
Bmagic |
:) |
| 13:34 |
|
LindaJansova joined #evergreen |
| 13:36 |
* Dyrcona |
is having one of "those" days where the brain and fingers cannot get it together. typos-- |
| 13:38 |
Dyrcona |
@decide Monty Python or Stanely Kubrick |
| 13:38 |
pinesol |
Dyrcona: go with Stanely Kubrick |
| 13:38 |
Dyrcona |
pinesol: You have a very dark sense of humor. |
| 13:38 |
pinesol |
Dyrcona: As great as you are man, you'll never be greater than yourself. |
| 13:39 |
Dyrcona |
berick: Have you got a suggestion for running test SMS messages through the XML notice generator? I was thinking of running it once per minute, but I guess I'll have to check with Unique support about what they might expect. |
| 13:40 |
Dyrcona |
@decide underscore or comma |
| 13:40 |
pinesol |
Dyrcona: go with underscore |
| 13:41 |
Dyrcona |
pinesol++ |
| 14:15 |
berick |
Dyrcona: yeah just depends on how often UMS checks for files. i'm not sure. our most frequently run notice is locker-checkout-email every 5 minutes |
| 14:16 |
berick |
i'm sure i asked a while back but don't remember how often they check .. be good to know |
| 14:18 |
Dyrcona |
berick: Thanks! I'm considering which template to use. It should probably be simple. |
| 14:19 |
berick |
oh, there's a FOR_TEXT flag in generate-notices.sh .. should just work |
| 14:19 |
berick |
we send SMSs too |
| 14:19 |
Dyrcona |
Yeah, I've added that. |
| 14:21 |
Dyrcona |
I'm looking at curbside. (We have one library, at least, still using it.) I might need some new templates. |
| 14:21 |
Dyrcona |
Maybe not. |
| 14:39 |
Dyrcona |
"1, 2, 5!" |
| 14:49 |
Dyrcona |
hmm.. Don't think sending test SMS is gonna work this way. The staff client expect an almost immediate response. With NOOP_True, it will always report success won't it? |
| 14:51 |
Dyrcona |
Eh, no.... There's no template output, so the staff client will always report failure. Staff will not like that. |
| 14:59 |
berick |
Dyrcona: oh you're trying to use open-ils.actor.event.test_notification ? |
| 15:00 |
berick |
yeah that would take some changes to tie-in a 3rd party sms generator |
| 15:00 |
Dyrcona |
berick: No, the staff client uses it. I'm just trying to figure out how that would work. |
| 15:01 |
berick |
right, yeah, it should basically work, but like you said, the UI will not get the output it may currently be expecting |
| 15:01 |
Dyrcona |
That's the conclusion I'm coming to, unless we hack the staff client. |
| 15:02 |
Dyrcona |
It looks like it might only fire 1 event, even if two are configured... I should test that, though. |
| 15:02 |
Dyrcona |
I'll enable my test event and see what happens on a test system. |
| 15:07 |
Dyrcona |
With both events active, neither got created. |
| 15:11 |
Dyrcona |
The default event from Evergreen by itself works. My custom event does not. The latter reports a failure and the event fails to get created. I'll check if the validation needs anything, but I think the validator is NOOP_True. |
| 15:12 |
Dyrcona |
Huh... I wonder if I'm looking at the correct database... |
| 15:14 |
Bmagic |
anyone seen this: overdues get account_adjusted when going lost, then lost is returned and they are generated again but this time over the max limit by exactly two rows. |
| 15:14 |
Bmagic |
so if it's a 10 dollar max, the re-genreation will go up to 10.40 *20 cents a day) |
| 15:15 |
Dyrcona |
Bmagic: That sounds familiar and sound like the thing that adjustment was supposed to fix, but that has been a long time. |
| 15:16 |
Dyrcona |
And... duh! My events were getting created. I was looking on id = 524 or id = 529 and should have event_def not id. |
| 15:16 |
Bmagic |
Dyrcona++ # sharp eyes |
| 15:17 |
Bmagic |
so, my thing is a bug? |
| 15:17 |
Dyrcona |
Bmagic: Could be. There might already be a Lp about it. I know lost items and restored fines are tricky. |
| 15:18 |
Dyrcona |
Computers are bad at math, honsetly....Perl is even worse. |
| 15:18 |
Dyrcona |
@who is the typo maven |
| 15:18 |
pinesol |
book` is the typo maven. |
| 15:18 |
Dyrcona |
Nah, that should be me. |
| 15:18 |
Bmagic |
found this one https://bugs.launchpad.net/evergreen/+bug/1741929 |
| 15:18 |
pinesol |
Launchpad bug 1741929 in Evergreen "Overdue fines not adjusted correctly on backdated lost items" [Undecided,Confirmed] |
| 15:19 |
Dyrcona |
Was the checkin backdated? |
| 15:20 |
Bmagic |
I'm checking on that. Is there a way to tell in the db? |
| 15:20 |
Dyrcona |
Gimme a sec.... |
| 15:20 |
mmorgan |
Bmagic: checkin_time vs. checkin_scan_time |
| 15:21 |
Dyrcona |
mmorgan++ I was just about to say that. |
| 15:21 |
mmorgan |
But that bug sounds different than what you're describing |
| 15:21 |
Bmagic |
ha! so that's what that column is for |
| 15:21 |
mmorgan |
:) |
| 15:21 |
Bmagic |
nope, not backdated |
| 15:22 |
Dyrcona |
On my events thing: with both events enabled only 1 fires. In any case the event that fires is set to complete, so we can't use this as-is for test text messages. |
| 15:22 |
Bmagic |
Dyrcona: that's what I was thinking |
| 15:22 |
Bmagic |
(on your thing) |
| 15:23 |
Dyrcona |
Yeah, I just had to run it to make sure. |
| 15:23 |
Dyrcona |
My test system does fire my test event with both enabled, but that's probably just "luck." |
| 15:30 |
mmorgan |
Bmagic: Is the max_fine in the circ properly set to 10? |
| 15:30 |
Bmagic |
mmorgan: yes |
| 15:30 |
Bmagic |
technicall 10.00 |
| 15:31 |
* mmorgan |
nods |
| 15:31 |
Bmagic |
I could see maybe going over by one because the compare logic checks after it applies the 20 cents. But two loops? it should have broken out of the loop if the total was greater than 10 |
| 15:31 |
mmorgan |
Sounds like a bug, but I don't see one. Is the ou setting circ.lost.generate_overdue_on_checkin set to true? Still should exceed the max, but that could be a factor. |
| 15:32 |
mmorgan |
*NOT exceed |
| 15:36 |
Bmagic |
another clue I just noticed: the timestamp on the first billing line for the re-generation batch, is dated exactly one day after the old batch of overdues stopped. So it would seem that the logic is setup to re-generate the overdues starting at the day after the LOST billing was created, and walking through the days up to today (the day the item was returned) - ignoring the max_fine ? |
| 15:37 |
Bmagic |
according to the setting English: "Enabling this setting causes retroactive creation of not-yet-existing overdue fines on lost item checkin, up to the point of checkin time (or max fines is reached)." |
| 15:39 |
mmorgan |
Bmagic: Found bug 1786312. Was the due date on the circ extended? |
| 15:39 |
pinesol |
Launchpad bug 1786312 in Evergreen "Extending circ due date can result in exceeding max fines" [Undecided,Confirmed] https://launchpad.net/bugs/1786312 |
| 15:39 |
Bmagic |
hmm |
| 15:41 |
Bmagic |
when you extend a due date, the code updates due_date in action.circulation? |
| 15:41 |
Bmagic |
if that's the case, then no, I don't think this example was extended because due_date - xact_start = 21 days, which is what it says it was suppose to be |
| 15:41 |
mmorgan |
Bmagic: Yes, when you edit a due date (as opposed to renewing) |
| 15:42 |
mmorgan |
Ok, then that's not it. Incidentally, there's a pullrequest on that bug from 2022 :-( |
| 15:42 |
Bmagic |
darn, I was hoping that was the bug for this issue |
| 15:42 |
Bmagic |
oh man, we're really slacking on pull requests |
| 15:43 |
mmorgan |
Any of the billings voided? |
| 15:43 |
mmorgan |
just grasping at straws... |
| 15:44 |
Bmagic |
good thought: none are voided |
| 15:45 |
Bmagic |
maybe daylight saving time was a factor.. these overdues spanned March 10th |
| 15:46 |
mmorgan |
Oh, good thought. |
| 15:46 |
mmorgan |
Or timezone? |
| 15:46 |
Bmagic |
actually, that might be it |
| 15:46 |
mmorgan |
Or both? |
| 15:46 |
Bmagic |
because the billing_ts skipped march 10th |
| 15:47 |
Bmagic |
there are exactly 50 20 cent billings for the original generation of the fines, adding up to 10 bucks, but it took an extra day to get there, because it skipped march 10th! |
| 15:49 |
* mmorgan |
is glad we are (mostly) fine free! |
| 15:49 |
Bmagic |
and* leap year is in there |
| 15:50 |
Bmagic |
so that's two odd days in the history... 2 days * 20 cents is 40 cents, and that's the descrepancy I'm looking for |
| 15:50 |
Bmagic |
it was a freak gasoline fight accident |
| 15:51 |
mmorgan |
Was the eclipse and solar flare in there too? ;-) |
| 15:51 |
Dyrcona |
March 10th... That was time change day, yeah? Does the fine generator run at 2:00 am. I saw errors in our logs from that day saying '2:00 am doesn't exist.' |
| 15:52 |
Bmagic |
yep, I had to Google it but yeah, March 10th was DS Spring forward |
| 15:53 |
Dyrcona |
I don't know where this '2:00 doesn't exist' nonsense comes, but Vixie cron never had a problem with it. |
| 15:53 |
Bmagic |
really? that's some funky log message |
| 15:53 |
Dyrcona |
It's not exactly that, but it amounts to that. |
| 15:53 |
Bmagic |
the gen fines crontab: 30 7-20 * * * |
| 15:54 |
Bmagic |
something about our "1 second before midnight" sql logic is scratching my head righ tnow |
| 15:54 |
Dyrcona |
I'm not sure this is the fine generator either. I think that gets calculated with the checkin. |
| 15:54 |
mmorgan |
Maybe pinesol was writing logs that day. |
| 15:54 |
Dyrcona |
It's probably safe to blame systemd. Why not? |
| 15:59 |
Bmagic |
man, what a weird deal |
| 16:25 |
jeffdavis |
We've had issues in the past with fine generation and DST. I don't have details ready to hand though. |
| 16:32 |
|
smayo joined #evergreen |
| 17:03 |
|
mantis1 left #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
