| 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/from-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 |
