| Time |
Nick |
Message |
| 02:13 |
|
sandbergja joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:54 |
|
agoben joined #evergreen |
| 07:15 |
|
JBoyer joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:36 |
|
sandbergja joined #evergreen |
| 07:37 |
|
collum joined #evergreen |
| 08:02 |
|
Dyrcona joined #evergreen |
| 08:23 |
|
bos20k joined #evergreen |
| 08:39 |
Dyrcona |
Ooh... segaults in liboils_pcrud.so |
| 08:40 |
Dyrcona |
segfaults, even... |
| 08:52 |
|
mmorgan joined #evergreen |
| 09:13 |
|
aabbee joined #evergreen |
| 09:15 |
|
bos20k joined #evergreen |
| 09:22 |
|
jvwoolf joined #evergreen |
| 10:27 |
|
khuckins joined #evergreen |
| 10:57 |
|
khuckins joined #evergreen |
| 11:39 |
dbs |
Dyrcona: oh that's not good. |
| 11:39 |
Dyrcona |
I'm going to look into it more, later. |
| 11:40 |
Dyrcona |
I have it on all but 1 brick drone a few times over the past week or so. |
| 11:42 |
JBoyer |
mmorgan, back to that auto_rewals_remaining A/T filter, did you apply that to checkout.due in action_trigger_filters.json? now that I look at that seems like it can have unintended consequences for non-auto renewal events. |
| 11:45 |
mmorgan |
JBoyer: No, I added it to a custom filter for autorenewals. Only some of our libraries are participating in autorenewals right now, so the custom filter runs the trigger only for those libraries. |
| 11:47 |
JBoyer |
Ah, ok. (we're in the same boat here, some do, some don't.) The latest circ I have with a null in that field is from before we upgraded to a version with autorenewals though, are you seeing new circs generated with a null in that field? |
| 11:52 |
mmorgan |
JBoyer: Yes, there are new circs with NULL in the auto_renewal_remaining field. |
| 11:53 |
JBoyer |
Oh, I just did a simple update config.rule_circ_duration set max_auto_renewals = max_renewals as part of that upgrade, that's why we don't see them. |
| 11:53 |
mmorgan |
These are circs that get a duration rule where max_auto_renewals is not set. |
| 11:55 |
mmorgan |
Ah ok, I only updated the duration rules where max_renewals > 0, and the library opted in. |
| 11:57 |
JBoyer |
Once it fast-path's the ar_remaining =0 case it may be quick enough to set all of the nulls to 0 so users get a full report of their autorenewal results. |
| 12:01 |
mmorgan |
Sure, quick enough, but I would still opt to not send autorenewal failure messages for items where renewals are never allowed anyway. |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:02 |
JBoyer |
Makes sense. |
| 12:02 |
berick |
another option would be to check auto_renewal=true to determine whether a notice should be sent |
| 12:03 |
berick |
then we could make auto_renewal_remaining non-NULL, defaulting to 0 |
| 12:03 |
jeff |
For some libraries that are using auto renewal notices to completely replace courtesy/overdue notices, that wouldn't be desired. |
| 12:03 |
jeff |
er, s/overdue/pre-overdue/ |
| 12:03 |
JBoyer |
Yeah, we do like sending failure notices, even if things never autorenew. :) |
| 12:03 |
jeff |
(nobody replacing overdue notices with autorenew notices that I'm aware of, just pre-overdue) |
| 12:03 |
JBoyer |
(they're generally mixed notices anyway, most things do autorenew here) |
| 12:04 |
Dyrcona |
We're doing autorenew and courtesy notices. I'm not sure how much discussion there was on the issues. |
| 12:05 |
Dyrcona |
I'll have to check for null in autorenew... I think I took care of that in my "activation" script, but.... |
| 12:05 |
mmorgan |
berick: So checking auto_renewal = true, wouldn't that miss the legitimately failed autornewals? Those with 0 autorenewals remaining? |
| 12:06 |
Dyrcona |
After lunch...and maybe after I finish fiddling with "stuck" purchase orders. |
| 12:06 |
mmorgan |
... 0 autorenewals remaining when the renewal attempt was made, that is. |
| 12:07 |
Dyrcona |
Really, there ought to be a way to totally skip autorenew for some items, like those with hourly loan rules. |
| 12:07 |
berick |
mmorgan: if auto_renewal=true and ar_remaining=0, send a notification only, via separate A/T trigger. |
| 12:07 |
Dyrcona |
mmorgan: Depends on whose values for true. |
| 12:07 |
mmorgan |
Dyrcona: That's what I assumed NULL would do. |
| 12:08 |
Dyrcona |
Something I've learned: Never assume. Always verify. |
| 12:08 |
berick |
then in the main trigger, limit to ar_remaining > 0 |
| 12:08 |
jeff |
Side effect would be that you'd no loonger be able to do it with a single notice? |
| 12:08 |
berick |
jeff: true |
| 12:09 |
Dyrcona |
Since what I'm working on involves "resetting" action trigger events. I'm of a frame of mind to pitch it all. :) |
| 12:09 |
Dyrcona |
But that's another rant for another time and place. :) |
| 12:10 |
jeff |
Dyrcona: pitch A/T, or did I misinterpret you? :-) |
| 12:10 |
Dyrcona |
You did not misinterpret me.... And, maybe not so much pitch as reimplement. There are a number of aspects that leave much to be desired. |
| 12:11 |
Dyrcona |
And, maybe I'm not to be taken too seriously on the matter at the moment. :) |
| 12:12 |
* jeff |
nods |
| 12:12 |
mmorgan |
berick: So wouldn't auto_renewal be true only if a previous autorenewal happened? You could have a circ with auto_renewal = FALSE and auto_renewal_remaining > 0 |
| 12:14 |
|
Christineb joined #evergreen |
| 12:14 |
berick |
mmorgan: right. are you thinking a manual renewal may have been done along the way? |
| 12:14 |
berick |
hm, yeah,i guess that could happen |
| 12:15 |
berick |
so maybe we do need auto_renewal_remaining to be NULL-able for maximum clarity. |
| 12:15 |
berick |
in which case, i revert back to my comments from the LP |
| 12:26 |
mmorgan |
berick: Yes, other types of renewals can happen to the autorenewable items, especially since this is a new feature and only used by some libraries. |
| 12:26 |
* mmorgan |
goes to read comment |
| 12:31 |
|
sandbergja joined #evergreen |
| 12:35 |
|
collum joined #evergreen |
| 13:49 |
|
BAMkubasa joined #evergreen |
| 13:51 |
BAMkubasa |
I'm looking at the action.hold_request table. capture_time is the time a book is brought back and checked in for the hold. Is fulfillment_time the time the book is checked in at the pickup library and available on the hold shelf? |
| 13:54 |
mmorgan |
BAMkubasa: capture_time is the time the hold grabs onto that item. shelf_time is when the item is checked in at the pickup library and becomes available for the patron on the holds shelf. |
| 13:54 |
mmorgan |
fulfillment_time is when the held item is checked out to the patron. |
| 13:55 |
BAMkubasa |
Thanks! |
| 13:58 |
jeff |
there are interesting complexities in some of those dates. are you doing anything specific with the data? |
| 14:00 |
BAMkubasa |
I'm trying to run some annual numbers to look at how many hold requests there were, how many were captured but not checked out, how many were cancelled, and also looking at how many were fulfilled within the same system versus outside the system |
| 14:02 |
jeff |
got it! the only thing that comes to mind there is that holds which are cancelled but then later "un-cancelled" don't generally have any indication in the database that they were ever cancelled. |
| 14:02 |
jeff |
but that's probably a small enough number that you won't need to worry about it. |
| 14:02 |
jeff |
("probably") |
| 14:03 |
BAMkubasa |
another question, action.hold_request has current_copy, if that changes as items aren't pulled from the shelf, or if a system retargets the hold, that current_copy just gets updated to the latest targeted copy? |
| 14:05 |
BAMkubasa |
it would be interesting to see if there are outliers who seem to re-target holds a lot, or aren't very contentious about their pick lists |
| 14:05 |
|
khuckins joined #evergreen |
| 14:06 |
mmorgan |
BAMkubasa: Yes, current_copy is the currently targeted copy, and that will change as the hold gets retargeted. |
| 14:08 |
* mmorgan |
thinks it would be difficult/impossible to tell who is manually retargeting. |
| 14:08 |
Dyrcona |
BAMkubasa: action.hold_copy_map has a "list" of copies eligible to fill action.hold_request entries. There is a hold targeter process that you should run from time to time to keep these up to date. |
| 14:12 |
BAMkubasa |
Thanks Dyrcona! Interesting |
| 14:15 |
pinesol |
[evergreen|Jane Sandberg] LP1830432: Make the org-family-select reusable - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a449066> |
| 14:15 |
pinesol |
[evergreen|Jane Sandberg] LP1830432: Make sure that unit tests have an org unit selected - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=00854e3> |
| 14:15 |
pinesol |
[evergreen|Bill Erickson] LP1830432 Uniqify reported org IDs / sandbox tweaks - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4cd71ff> |
| 14:15 |
pinesol |
[evergreen|Jane Sandberg] LP1830432: Use a stub callback with registerOnTouched - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ae4cbb> |
| 14:15 |
pinesol |
[evergreen|Bill Erickson] LP1830432 Org family renders checkboxes horizontally - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c20fa9d> |
| 15:40 |
|
sandbergja joined #evergreen |
| 15:48 |
|
jihpringle joined #evergreen |
| 16:05 |
|
sandbergja joined #evergreen |
| 16:11 |
|
sandbergja joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
jamesrf joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 18:12 |
|
Dyrcona joined #evergreen |
| 18:14 |
* Dyrcona |
is feeling contrary, but refrains from saying what he really thinks. |
| 18:20 |
* Dyrcona |
decides to reboot the laptop. |
| 18:34 |
|
kenstir joined #evergreen |
| 20:30 |
|
sandbergja joined #evergreen |
| 21:37 |
|
sandbergja joined #evergreen |
| 22:32 |
|
sandbergja joined #evergreen |
