| Time |
Nick |
Message |
| 02:13 |
|
troy__ joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
agoben joined #evergreen |
| 08:41 |
|
kmlussier joined #evergreen |
| 08:44 |
csharp |
JBoyer++ # bug 1741309 |
| 08:44 |
pinesol_green |
Launchpad bug 1741309 in Evergreen "Hatch: Installer does not grant proper file permissions" [Undecided,Confirmed] https://launchpad.net/bugs/1741309 |
| 08:45 |
|
Dyrcona joined #evergreen |
| 08:53 |
|
mmorgan joined #evergreen |
| 09:13 |
|
rlefaive joined #evergreen |
| 09:23 |
Dyrcona |
Is it just me, or is it cold in here? |
| 09:23 |
kmlussier |
Dyrcona: It's cold in here. |
| 09:23 |
|
yboston joined #evergreen |
| 09:29 |
* mmorgan |
hopes it is at least in the double digits :) |
| 09:30 |
|
bos20k joined #evergreen |
| 09:57 |
Dyrcona |
kmlussier: Heat's broken. |
| 09:57 |
* Dyrcona |
overheard something about a leak. |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:20 |
|
bos20k joined #evergreen |
| 10:28 |
|
mmorgan joined #evergreen |
| 10:38 |
|
mmorgan1 joined #evergreen |
| 10:58 |
Bmagic |
when taking advantage of lost.auto how should the delay and max_delay be set? |
| 11:12 |
Bmagic |
I think I might have answered my own question. The delay is how long to wait after the first event? Meaning, when something is automatically marked lost, the AT engine doesn't just immediately fire lost.auto stuff? |
| 11:13 |
berick |
yeah, the delay is how long to wait after the event is created before firing |
| 11:14 |
mmorgan |
So, delay = How long after the item is marked lost should the notice should be generated? |
| 11:14 |
Bmagic |
berick: I see, so I wouldn't find any rows for that event_def in action_trigger.event until after the delay is met? |
| 11:14 |
berick |
particularly useful for grouped events where you want, say, all overdue notices to a single patron to be handled via a single email instead of multiple emails. |
| 11:15 |
berick |
Bmagic: no, the rows would be there |
| 11:15 |
berick |
mmorgan: yep |
| 11:15 |
Bmagic |
I don't have the rows |
| 11:15 |
Bmagic |
The lost.auto and the marklost triggers are on different granularity, does that matter? |
| 11:16 |
berick |
granularity has no effect on when a non-passive event is created, only when it fires. |
| 11:18 |
|
Christineb joined #evergreen |
| 11:18 |
Bmagic |
the code that executes the marklost trigger, should be responsible for creating the lost.auto rows then? |
| 11:19 |
berick |
to cover the obvious things, is the lost.auto def active and its owner org unit is sufficiently broad in scope? |
| 11:19 |
berick |
Bmagic: yes, MarkItemLost is responsible for creating lost.auto action_trigger.event rows |
| 11:19 |
Bmagic |
berick: yes owners are equal |
| 11:20 |
berick |
Bmagic: and the lost items in question are owned within the same org scope? |
| 11:20 |
berick |
(i think "owned", i could be wrong about the scoping there) |
| 11:22 |
Bmagic |
berick: I am trying a couple of things. Thanks for giving some ideas |
| 11:38 |
Bmagic |
berick: open-ils.trigger [WARN:12506:Application.pm:624:] open-ils.trigger.passive.event.autocreate.batch: Use of uninitialized value in string ne at /usr/local/share/perl/5.22.1/OpenILS/Application/Trigger.pm line 429. |
| 11:39 |
Bmagic |
it looks like that might be why it's not creating the rows? |
| 11:42 |
berick |
lost.auto events are created via open-ils.trigger.event.autocreate |
| 11:42 |
berick |
AKA create_active_events_for_object() |
| 11:42 |
berick |
different sub |
| 11:43 |
berick |
Bmagic: just to confirm, items are being marked as lost, right? it's just the notifications (lost.auto) that's not working? |
| 11:43 |
Bmagic |
correct |
| 11:44 |
mmorgan |
Bmagic: What's your current delay set at? |
| 11:44 |
Bmagic |
I think I might be onto something. I just discovered something in the message template (not template) |
| 11:44 |
Bmagic |
weird that it wouldn't make the rows anyway because it shouldn't be reacting to them until after the delay |
| 11:52 |
Bmagic |
berick: Trigger.pm create_batch_events function looks like it will only create the lost.auto events with matching granularity? for my $def ( @$defs ) { next if ($granularity && $def->granularity ne $granularity ); ......... |
| 11:53 |
berick |
Bmagic: that's only true if a granularity is specified in the API call |
| 11:53 |
berick |
in this case, no granularity is specified |
| 11:53 |
berick |
$ses->request('open-ils.trigger.event.autocreate', 'lost.auto', $circ, $circ->circ_lib); |
| 11:53 |
Bmagic |
darn |
| 11:54 |
Bmagic |
those warnings are not important then> |
| 11:54 |
berick |
are you seeing open-ils.trigger.event.autocreate with 'lost.auto' as a param in the logs? |
| 11:54 |
berick |
Bmagic: they probably aren't a problem |
| 11:54 |
|
khuckins joined #evergreen |
| 11:55 |
Bmagic |
I'm not seeing a call to that API at all |
| 11:56 |
Bmagic |
the event that is responsible for MarkItemLost is triggered with custom filters if that matters |
| 12:02 |
berick |
if MarkItemLost runs, then so should lost.auto. |
| 12:04 |
berick |
i hesitate to bring this up, because I have no explanation, but we had problems in the past with lost.auto. i eventually commented out that line of code since we weren't using it. |
| 12:07 |
mmorgan |
We don't use lost.auto either, FWIW |
| 12:07 |
berick |
every now and then the mark-lost events would get backed up, they couldn't finish. my theory is that creating events while firing events is causing problems. commenting out the line fixed the problem for us. |
| 12:12 |
Bmagic |
berick: ok, I believe I might have found an issue with the originating MarkItemLost trigger and not the lost.auto, testing my theory now |
| 12:12 |
berick |
*nod* |
| 12:14 |
berick |
ah, never thought 41° could feel this good |
| 12:15 |
berick |
web team gurus, i have updated Hatch: https://evergreen-ils.org/downloads/Hatch-Installer-0.1.4.exe |
| 12:17 |
|
sandbergja joined #evergreen |
| 12:18 |
|
jihpringle joined #evergreen |
| 12:21 |
Bmagic |
berick: that was it. lost.auto created the rows just fine. The issue is a conflict between this patch: https://bugs.launchpad.net/evergreen/+bug/1331174 and https://bugs.launchpad.net/evergreen/+bug/1661754 |
| 12:21 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] |
| 12:21 |
pinesol_green |
Launchpad bug 1661754 in Evergreen 2.11 "Staff users should be prevented from marking a Long Overdue item Lost" [Undecided,Fix released] |
| 12:22 |
Bmagic |
The former is code that allows items to turn from long overdue into lost |
| 12:22 |
Bmagic |
and the latter prevents items from becoming lost from long overdue! |
| 12:23 |
Bmagic |
It boiled down to one line in AssetCommon.pm if ($copy->status == $args{status} || $copy->status == $args{alt_status}); |
| 12:27 |
berick |
Bmagic: yay. so set_item_lost was failing? |
| 12:27 |
Bmagic |
it wasn't failing per se, it was doing exactly what we programmed it to do: stop execution if the status=4 or status=16 |
| 12:27 |
berick |
well, failing to mark the item lost? |
| 12:28 |
Bmagic |
the or status=16 was introduced after I wrote our patch, I commented on the bug (still unmerged code) |
| 12:28 |
Bmagic |
berick: right, failing to mark it lost |
| 12:29 |
Bmagic |
but now it's working with my hack. I just deleted || $copy->status == $args{alt_status} from that line |
| 12:31 |
mmorgan |
Bmagic: If I recall correctly, lp 1661784 only prevented long overdues from being marked lost in the staff client. |
| 12:31 |
Bmagic |
It makes sense that we wouldn't want the staff to mark things lost that are already "long overdue" - but I can argue that we WOULD want that under some conditions. Those conditions are not well defined |
| 12:31 |
mmorgan |
oops. lp 1661754 |
| 12:31 |
pinesol_green |
Launchpad bug 1661754 in Evergreen 2.11 "Staff users should be prevented from marking a Long Overdue item Lost" [Undecided,Fix released] https://launchpad.net/bugs/1661754 |
| 12:32 |
Bmagic |
mmorgan: yep, that is exactly right. In our case, we have things going to long overdue in a shorter interval than lost. We want things to transition twice. Once to long overdue where the patron receives penalties but not bills, then finally lost where bills occur |
| 12:33 |
Bmagic |
which is what bug 1331174 does |
| 12:33 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 12:33 |
* mmorgan |
nods |
| 12:57 |
jeff |
hrm. interesting. |
| 13:25 |
|
mmorgan1 joined #evergreen |
| 13:59 |
|
slink-lib joined #evergreen |
| 14:24 |
kmlussier |
Bah! LP timeouts. |
| 15:08 |
|
rlefaive joined #evergreen |
| 15:09 |
kmlussier |
miker: Under what circumstances should biblio.record_entry.vis_attr_vector be populated? Is it just used for records with Located URIs? |
| 15:10 |
miker |
kmlussier: luris and if the bib has a source |
| 15:10 |
miker |
kmlussier: btw, I'm preparing a server for more in-depth testing |
| 15:10 |
kmlussier |
miker: Any source or just transcendent sources? |
| 15:10 |
miker |
I was piggybacking on another so want to eliminate any confusion |
| 15:11 |
miker |
any source |
| 15:26 |
|
Christineb joined #evergreen |
| 15:39 |
Bmagic |
I have this title level hold that will NOT include a copy that it should be including. The logs show that it's being processed but bails out early due to Recall threshold was not set; bailing out on hold 940867 processing. - Weird because this hold is for sure not 'R' |
| 15:39 |
Bmagic |
so the question is, under what circumstances can a hold be treated as a Recall when it's not set that way in action.hold_request ? |
| 15:41 |
berick |
Bmagic: what's the actual hold targeter message? |
| 15:41 |
Bmagic |
berick: open-ils.storage [INFO:5762:action.pm:1645:1515443335182130] Recall threshold was not set; bailing out on hold 940867 processing. |
| 15:43 |
berick |
Bmagic: that just means no targetable copies were found and we tried to recall, but you're not set up for that. |
| 15:43 |
berick |
i think you can ignore the call message |
| 15:44 |
Bmagic |
Ah, hmmm, dead end then |
| 15:44 |
berick |
Bmagic: curious that you're getting logs from the storage hold targeter, though. thought you were using the new targeter. |
| 15:44 |
Bmagic |
berick: I am manually running this hold with srfsh |
| 15:44 |
Bmagic |
request open-ils.storage open-ils.storage.action.hold_request.copy_targeter "", 940867 |
| 15:45 |
Bmagic |
I suppose I shouldn't be using that call..... |
| 15:45 |
berick |
i mean, they should behave the same, but yeah better to compare apples |
| 15:45 |
Bmagic |
what would be my srfsh call? |
| 15:46 |
berick |
open-ils.hold-targeter open-ils.hold-targeter.target {"hold":<id>} |
| 15:46 |
berick |
I think |
| 15:47 |
Bmagic |
working |
| 15:48 |
Bmagic |
well, it worked |
| 15:49 |
Bmagic |
it reduced the number of copies in hold_copy_map, but it should* be adding a copy |
| 15:49 |
Bmagic |
I am staring at a row in asset.copy that truely should be included |
| 15:49 |
Bmagic |
truely/truly |
| 15:51 |
Bmagic |
The copy is holdable/opac_visible and the location likewise. Running action.hold_request_permit_test manually results in success=true |
| 15:52 |
kmlussier |
Bmagic: Mint condition is true? Did it just recently move out of a non-holdable status? |
| 15:53 |
Bmagic |
oh man, I was just looking at that! |
| 15:53 |
* Dyrcona |
thinks we could probably do away with mint condition. |
| 15:53 |
kmlussier |
Does anyone use it? |
| 15:53 |
Bmagic |
The JSON query mentions that in the DB lookup for potiental copies |
| 15:53 |
Dyrcona |
Strike the "probably" in that. |
| 15:54 |
Dyrcona |
kmlussier: We could open a Lp bug with a patch and see who complains, though it might have to wait until it goes in before anyone notices. :) |
| 15:55 |
Bmagic |
well, the other copes in the hold_copy_map have the same value in mint_condition so that can't be it |
| 15:55 |
kmlussier |
Dyrcona: Well, we could send a message to the list first just to be safe. |
| 15:56 |
Bmagic |
the copy status is "canceled transit" |
| 15:56 |
Bmagic |
which is the only difference between the 3 copies that are in hold_copy_map and the one that I want it to find.... |
| 15:58 |
berick |
Bmagic: are you wondering why it's not in the copy map or why it's not targeted for pulling? |
| 15:59 |
Bmagic |
I should think that the hold targeter would pick this copy up and put it in hold_copy_map |
| 15:59 |
Bmagic |
once that happens, then it would get targeted for current_copy for sure |
| 15:59 |
Bmagic |
I am going to update status=0 and see what happens |
| 15:59 |
berick |
well it won't get targeted for current copy in that status |
| 16:01 |
berick |
in the 'canceled transit' status, i mean |
| 16:01 |
Dyrcona |
Does canceled transit keep it from the copy map? |
| 16:01 |
* Dyrcona |
has not looked, but it would appear so. |
| 16:02 |
berick |
in my test db, 'canceled transit' is marked as holdable |
| 16:03 |
Dyrcona |
ok |
| 16:04 |
Dyrcona |
It's holdable in my production database for the sake of the logs. |
| 16:06 |
Dyrcona |
Maybe copy_active being false is Bmagic's issue? |
| 16:12 |
berick |
for copy map, holdable=true is the only factor for the status |
| 16:49 |
Bmagic |
sorry, had a phone meeting, I'm back |
| 16:53 |
berick |
neat, I have [ import egCoreMod from './services/core.js'; ] working via webpack (in a very limited scope) |
| 16:58 |
Bmagic |
changing to status=0 didn't do anything |
| 16:59 |
berick |
copy location? |
| 17:06 |
|
mmorgan left #evergreen |
| 17:23 |
Bmagic |
berick: the copy location is holdable and in fact the exact same location as the other 3 copies that are getting into the hold_copy_map |
| 17:24 |
berick |
Bmagic: k. ain't that, then |
| 17:24 |
Bmagic |
There has to be something different about this copy. Looking at all of the other copies next to it, shows all columns the same except the circ lib |
| 17:24 |
Bmagic |
and status is different. The three that made it are "on order" and this one is "Available" |
| 17:25 |
Bmagic |
one of the 3 copies that are "good" shares the same circ_lib as the copy that is "bad" |
| 17:25 |
Bmagic |
Call number ID's are different |
| 17:27 |
Bmagic |
looking at the line up of call number rows, I detect nothing other than the label not being "ONORDER" |
| 17:27 |
Bmagic |
oh em gee |
| 17:28 |
Bmagic |
I can't believe I didn't check this - friggin parts |
| 17:33 |
Bmagic |
the items were on order, and the holds are placed during the order process on the bib. Without having cataloged the items, they don't know what the parts are going to be. Now that they cataloged it, they assigned it a part which breaks any title level holds |
| 17:33 |
Bmagic |
title level holds without parts at least |
| 17:33 |
Bmagic |
This being a DVD seasons should have tipped me off at the beginning. I think I am starting to loose my mind |
| 17:40 |
csharp |
Bmagic++ # you're not alone ;-) |
| 17:41 |
Bmagic |
csharp berick: I can't find the bug, but it should be one. It seems like someone should have reported this. Patron hold notification preferences do not populate the checkboxes on existing accounts? |
| 17:41 |
Bmagic |
in webby I mean |
| 17:41 |
csharp |
hmm - I haven't seen that reported here |
| 17:41 |
Bmagic |
it's easy to confirm |
| 17:41 |
Bmagic |
pull up any random patron who has some hold notification preferences |
| 17:42 |
csharp |
I'll sic terran on it tomorrow ;-) |
| 17:42 |
Bmagic |
and you will see the boxes check in xul but not in webby |
| 17:42 |
csharp |
our office closed today due to 1) football 2) Trump and 3) weather |
| 17:42 |
Bmagic |
lol |
| 17:42 |
csharp |
well, really, the whole city shut down |
| 17:42 |
Bmagic |
I pick 3 |
| 17:43 |
csharp |
all metro area schools closed because of the threat of freezing rain (more like drizzle in real life) |
| 17:43 |
csharp |
and all state offices closed because of that and the game |
| 17:43 |
csharp |
and Trump coming to town |
| 17:44 |
Bmagic |
Ah! I thought it was just Trump (in general) |
| 17:45 |
csharp |
heh - yeah maybe |
| 17:45 |
csharp |
I heard a rumor that the administration reserved 250 hotel rooms right outside my neighborhood |
| 17:45 |
csharp |
but I never saw that confirmed anywhere |
| 17:45 |
Bmagic |
get your camera ready |
| 17:46 |
Bmagic |
I tacked it on bug 1361258 |
| 17:46 |
* csharp |
hopes to run into Sarah Huckabee Sanders at Target later :-) |
| 17:46 |
pinesol_green |
Launchpad bug 1361258 in Evergreen "Patron registration form does not set notification preferences" [Undecided,Confirmed] https://launchpad.net/bugs/1361258 |
| 18:30 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 19:27 |
troy__ |
i'm trying to pass a user object to an opensrf call, can anyone tell me if this is the right format? |
| 19:27 |
troy__ |
https://www.irccloud.com/pastebin/kRthpHfD/ |
| 19:29 |
troy__ |
for open-ils.circ.checkout.permit |
| 19:29 |
troy__ |
was looking at this a while ago but got distracted with other work ;) |
| 22:22 |
|
jonadab joined #evergreen |
| 22:34 |
|
jonadab joined #evergreen |
