Evergreen ILS Website

IRC log for #evergreen, 2015-10-20

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
02:45 tsbere__ joined #evergreen
06:40 rlefaive joined #evergreen
07:44 mrpeters joined #evergreen
07:56 rjackson_isl joined #evergreen
08:00 ericar joined #evergreen
08:03 rlefaive joined #evergreen
08:03 kmlussier @quote random
08:03 pinesol_green kmlussier: Quote #29: "<Rogan_> Apparently I'm a trouble maker or busy body or something." (added by gmcharlt at 02:28 PM, July 11, 2012)
08:05 jboyer-isl joined #evergreen
08:10 ericar joined #evergreen
08:12 collum joined #evergreen
08:12 Callender joined #evergreen
08:36 mmorgan joined #evergreen
08:41 rlefaive joined #evergreen
08:47 Dyrcona joined #evergreen
09:03 Dyrcona Kernel updates. Back in a mo'.
09:05 Dyrcona joined #evergreen
09:19 maryj joined #evergreen
09:21 ericar_ joined #evergreen
09:38 yboston joined #evergreen
09:41 mmorgan1 joined #evergreen
09:42 mmorgan1 left #evergreen
10:00 * mmorgan wrestles with migrating to a new workstation. Never have been very good at deciding what to keep and what to toss.
10:03 jeff $HOME/from-old-machine/from-older-machine/f​rom-even-older-machine/super-important.txt
10:04 * mmorgan has folders much like that :)
10:12 Dyrcona For me, it's easy these days: duplicity restore url://for-remote/backup-folder ./
10:13 jeff very handy.
10:52 Christineb joined #evergreen
11:15 rlefaive joined #evergreen
11:17 jwoodard joined #evergreen
11:20 dbs jeff++
11:50 rlefaive joined #evergreen
12:05 jihpringle joined #evergreen
12:09 kitteh_ joined #evergreen
12:10 ldw joined #evergreen
12:31 bmills joined #evergreen
12:40 ldw joined #evergreen
12:45 kmlussier It's funny seeing the kind of results you get when you type "test search" into a catalog search box.
13:00 bshum ericar++ kmlussier++ # seeking workflow feedback to figure out the steps to reach an error
13:05 mmorgan2 joined #evergreen
13:07 mmorgan joined #evergreen
13:23 rlefaive joined #evergreen
13:23 bshum mmorgan: Shots in the dark sometime hit things
13:24 * mmorgan often relies on that fact ;-)
13:25 kmlussier mmorgan: Yeah, I think you hit the mark that time. Her screenshot doesn't show a Billing Type.
13:26 bshum mmorgan++
13:26 kmlussier mmorgan++
13:28 mmorgan kmlussier types faster than me (or maybe gets to the point faster!)
13:29 mmorgan kmlussier++
13:30 kmlussier I'm learning to get right to the point in my e-mails. It's a very difficult lesson for a wordy person such as myself.
13:31 * kmlussier will be sending an e-mail to the list later today that I'm sure will take me way too much time to write.
13:33 * mmorgan runs off for a bit, looking forward to kmlussier's email
13:38 graced_ joined #evergreen
13:54 kmlussier bshum / mmorgan: I'm wondering if it's a permission issue. Maybe staff don't have permission to view the billing type?
13:54 bshum kmlussier: Could be.
14:21 bshum kmlussier: Maybe the wrong depth?
14:21 bshum Like they have the view billing type at library, not cons level
14:21 * kmlussier checks her email
14:22 kmlussier bshum: Yeah, sounds right to me. Do you want to take a turn now?
14:22 bshum I just packed my laptop away.
14:22 bshum I'm on my phone now.
14:23 kmlussier bshum: If you don't get to it, I can send something in a bit.
14:24 mmorgan2 joined #evergreen
14:26 mmorgan joined #evergreen
14:32 remingtron_ joined #evergreen
14:33 bshum kmlussier: It's okay, I just type slowly.
14:39 bshum phasefx++
14:39 kmlussier phasefx: Ah! I hadn't thought about checking specifically for the Misc billing type.
14:40 kmlussier phasefx++
14:42 phasefx basically need an otherwise visible billing type with an id >= 100
14:43 phasefx Misc gets id = 101
14:47 bmills joined #evergreen
14:47 mmorgan phasefx++ bshum++ kmlussier++
14:48 bshum "global administrator" != superadmin=true ?
14:48 kmlussier I'm afraid if I respond to the latest email, I won't be nice.
14:48 Bmagic uuuuuggg, another "why did this item get routed to A when there are holds at B?" - I spend so much time on these questions. Anyone have suggestions to answer these questions easily? In this case, there is a proximity adjustment for the system to "0". And Best sort order is FIFO
14:49 phasefx no telling what's been altered over there
14:49 bshum phasefx: True that
14:49 bshum :(
14:50 sandbergja joined #evergreen
14:50 bshum Bmagic: Holds are always fun to explain.  For varying levels of "fun" (or crying, or pain)
14:50 bshum I find those end up being too situational to concisely explain 100% of the time with a simple answer.  It almost always depends on the item, the patron, and the libraries involved.
14:51 bshum Unless you live in an awesome system where you've got one or two hold rules.
14:51 bshum You can have X, but you can't have Y.
14:51 Bmagic bshum: yeah no kidding. In this case, the item didn't fill a hold, it's going back home, but it's in the hold_copy_map for a dozen other unfilled holds.
14:51 bshum Done, period.
14:52 tsbere Bmagic: If you are in FIFO mode then was the hold at A older than the hold at B?
14:53 Bmagic tsbere: the item didn't fill a hold
14:54 tsbere Bmagic: Ahhh. Do you have any settings for stalling set?
14:54 Bmagic tsbere: it was directed to go home for some reason, when it could have clearly filled other holds (it's in the hold_copy_map for a dozen other holds)
14:54 bmills joined #evergreen
14:54 Bmagic stalling, hmm, let me see
14:54 tsbere Bmagic: Also, are any of those holds for patrons that have hit blocks?
14:56 Bmagic ill check
14:56 * tsbere loves answering "why didn't it fill this other hold?" with "Because someone at your library flagged them with a 'block everything' penalty a few days ago"
14:56 bshum It's not holds go home right?
14:56 Bmagic right, it's FIFO
14:56 bshum There's a YAOUS for that which will send a copy to home
14:57 Bmagic I am tempted to check it in at it's destination and see if it triggers a capture
14:57 Bmagic but I don't want the database mess afterwards
14:57 bshum Is it in transit_item or hold_transit_item?
14:57 bshum Maybe you can trace the hole that way
14:57 Bmagic tsbere: no on the penalities, they are in good standing
14:58 bshum *hold
14:58 Bmagic bshum: transit_copy not hold_transit_copy
14:59 Bmagic so, it's not filling a hold, it just going home
14:59 Bmagic is there a DB function I can call to see if the copy will fill one of these holds
15:00 bshum Was the copy in any previous bad statuses that wouldn't target to holds?  Like damaged, etc.
15:00 bshum Perhaps it's being sent home because it was marked damaged, and then checked in
15:00 Bmagic bshum: no, it was checked out, and returned
15:00 tsbere Bmagic: Actually, what is the destination status on the transit?
15:00 Bmagic the transit_copy table says it was "reshelving"
15:01 tsbere Bmagic: And if you use the action.hold_request_permit_test function you can see what it returns
15:01 tsbere Though you have to pull the pieces out yourself to pass in
15:02 tsbere Bmagic: Also, I suppose a good question would be "were those holds placed BEFORE or AFTER the transit started?"
15:02 Bmagic before
15:02 Bmagic im testing the function
15:06 Bmagic tsbere: I have a success='t' from that query
15:06 Bmagic does that mean it should have filled the hold that I simulated?
15:06 tsbere Possibly, if the hold was in a valid state at the time to accept the copy
15:12 Bmagic thanks all - I have recommended aborting the transit and checking it back in. I really should have filled one of those holds
15:12 Bmagic /I/It
15:13 jboyer-isl tsbere: Wouldn't that function return success = t even if holdable = f? As in, "I successfully found a match and they can't have it." I haven't looked at it in some time though.
15:17 tsbere jboyer-isl: That is a good point...
15:17 tsbere Bmagic: See jboyer-isl's comment just now
15:17 Bmagic I see
15:18 Bmagic so, there is some question about asset.copy.holdable ? and/or asset.copy_location.holdable?
15:18 tsbere Bmagic: The config.hold_matrix_matchpoint row, actually.
15:19 Bmagic it gave me the matchpoint ID, I suppose I need to look at that row
15:19 tsbere yea
15:19 Bmagic holdable='t'
15:28 jboyer-isl Still a good thing to know when calling that function, but a bummer that it's not the end of your search. :-/
15:29 tsbere Bmagic: Outside of checking the copy and/or location holdable flags, or perhaps checking the copy's auditor to see if those were changed before/after it went into transit, I am running low on ideas
15:46 Bmagic tsbere: yeah, right now, im calling it a fluke
15:47 Bmagic if they abort the transit and check it back in, and it still doesnt fill one of those holds, I'm going to be concerned
16:08 jlitrell joined #evergreen
16:17 pastebot "Bmagic" at 64.57.241.14 pasted "Checkin that should fill a hold but it goes home first" (2245 lines) at http://paste.evergreen-ils.org/17
16:17 Bmagic tsbere ^^
16:18 tsbere Bmagic: I am not going to be able to figure anything out from that at this point in the day.
16:18 Bmagic hehe, no biggie, I am just starting to look at it myself
16:20 Bmagic tsbere: it looks like it didnt try to fill any of the holds that it should have tried. It's only trying all of the holds outside of the system which of course cannot be filled because of age based hold protection
16:21 tsbere Bmagic: Ahhh! It timed out/ran out of holds that it was looking for and gave up. I have seen that before with age protection.
16:21 Bmagic another clue: hold stalling interval of 2 days
16:21 tsbere That just means that any hold placed in the last 2 days likely wouldn't trigger
16:21 Bmagic does "hold stalling interval of 2 days" mean it wont try to fill holds that are newer than 2 days?
16:22 tsbere within the stalling period means "only pull list or checked in at pickup library"
16:23 Bmagic ok, so the issue is that there are more holds than it allows for when checking for fulfillment?
16:31 jboyer-isl This reminds me of something we ran into when we tested FIFO holds here a few years ago. The gist is that the opportunistic targeter only looks at X holds, and if none of the first X holds returned are for the current branch it gives up. We had huge blockbuster items with tons of holds going back on the shelf at checkin because of the FIFO setting. It's been years since I looked at it, but I don't know if it's changed that much internally since then.
16:34 mmorgan joined #evergreen
16:40 mmorgan Bmagic: Did you figure out your hold thing? It looks to me like your item is age protected.
16:40 mmorgan age_protect=2
16:41 Bmagic it is protected, and it sounds like it's a bug or something. Where it gives up looking for more holds after failing on many other unfillable holds
16:43 mmorgan So there are holds at home that it's not filling?
16:44 Bmagic mmorgan: yep, there are fillable holds but it doesnt check them because there are too many other holds that it wont fill!
16:47 Bmagic And I'm not sure really what to do about it
16:49 * mmorgan rereads backscroll.
16:50 mmorgan So the item is checked in at org 156, and its circ_lib is 161.
16:50 Bmagic yes
16:51 Bmagic and there are holds in the system that this item will fill, if it would just try
16:51 mmorgan And it wants to go home to 161 rather than filling a hold at 156?
16:52 Bmagic but instead it tries to fill all of the unfillable holds first and gives up after like 40 other holds
16:52 Bmagic The hold that it should fill is not at 156, it's another branch in the same system
16:53 Bmagic mmorgan: one example hold that it could fill has a pickup_lib of 157 (same system). Testing to see if the copy will fill it by calling  action.hold_request_permit_test function  tells me that it will fill it
16:55 Bmagic I am sure it's by design, to keep the staff user waiting less for the checkin to finish
16:56 mmorgan Hmm. But what's the point of less waiting if the hold that should get filled doesn't get filled?
16:56 Bmagic it does seem like the code could prioritize/sort the resulting hold requests by proximity or something so that it wouldn't waste time attempting to fill unfillable hold requests
16:57 mmorgan Is this a new problem? We've been using age protection for quite some time and I don't think we've ever seen this particular issue.
16:57 Bmagic I believe I have discovered this before. And now Im rediscovering it
16:57 Bmagic I do not believe I created a LP on it before though
16:59 mmorgan What's the proximity setting on your age hold protection rule?
16:59 Bmagic mmorgan tsbere: are the hold sorted at all when attempting to fill them? It seems like they should already be sorted in the order dictated by "Best sort order",weighting etc
17:01 * mmorgan is not sure exactly how the sorting works with all the bits and pieces.
17:02 Bmagic mmorgan: proximity is set to 2
17:04 Bmagic which is why all of those hold attempts fail, but the system never gets to filling one of the holds where the proximity is < 2 because it goes through all of those other ones first for some reason
17:06 mmorgan Gotcha. Does sound like a bug. Maybe you're hitting a threshold in the number of holds that we aren't.
17:07 Bmagic CALL: open-ils.storage open-ils.storage.action.hold​_request.nearest_hold.atomic 156, Fieldmapper::asset::copy=ARRAY(0xa21fb90), 100, 2 days, 0
17:07 Bmagic does that 100 mean limit 100?
17:10 * mmorgan isn't sure about that.
17:10 mmorgan But is your age protection interval 2 days? If so, the item shouldn't be protected anymore.
17:12 Bmagic age protection ID 2 means 6 months
17:12 Bmagic line 531 in action.pm contains the query that is probably introducing this bug
17:13 mmorgan ok, gotcha. Out of ideas and time for today. Gotta run for now.
17:14 Bmagic mmorgan++ tsbere++ bshum++ thank you for your time!
17:15 mmorgan left #evergreen
17:27 Bmagic https://bugs.launchpad.net/evergreen/+bug/1508208
17:27 pinesol_green Launchpad bug 1508208 in Evergreen "Checkin age based hold protected item may not fill fillable holds" [Undecided,New]
18:04 jeff so, now's as good a time to ask again as any other: anyone know offhand why we put ineligible-due-to-age-hold-protection copies in ahcm?
18:59 dMiller_ joined #evergreen
19:28 miker Jeff: I don't believe we do that test in the targetter. /me imagines the "but the age protection expired this morning at 10 am" tickets
19:29 * miker disappears
20:01 jeff miker: easy fix there -- only include those copies that will be eligible within the next 24h or so ;-)
20:01 jeff (and yes, I realize I'm saying "easy" with something to do with holds...)
23:58 bmills joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat