| Time |
Nick |
Message |
| 07:24 |
|
rjackson_isl_hom joined #evergreen |
| 07:43 |
|
mantis1 joined #evergreen |
| 07:48 |
|
BDorsey joined #evergreen |
| 07:52 |
|
rfrasur joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 09:00 |
|
dguarrac joined #evergreen |
| 09:06 |
|
jvwoolf joined #evergreen |
| 11:42 |
jvwoolf |
Anybody know off the topc of your head how a hold can end up with a status of "Wrong Shelf?" |
| 11:54 |
jeff |
sure thing! |
| 11:57 |
jvwoolf |
jeff: Can you tell me how? I'm scratching my head. |
| 11:58 |
jeff |
sorry, delayed. :-) a hold is in that status when its pickup library has changed after it has been captured and "available" at a different library. |
| 11:58 |
jeff |
it's literally "this hold has a current_shelf_lib different from its pickup_lib" |
| 11:59 |
jeff |
(and it will fire even if the item would not normally be considered "available", so disregard my mention of "available" above) |
| 12:00 |
jvwoolf |
So it's just that someone went in and changed the pickup library on the hold after capturing it? |
| 12:01 |
jeff |
yes, though it doesn't have to be the same person that captured it. |
| 12:01 |
jvwoolf |
Doesn't make too much sense in the holds I'm looking at. All the patrons' other holds have the same pickup library as the current one |
| 12:01 |
jvwoolf |
Unless someone changed the pickup library by mistake, captured the hold, and then changed it back to what it originally was I suppose... |
| 12:02 |
jeff |
unless you're auditing action.hold_request, you'll likely need to consult logs for more info. |
| 12:03 |
jeff |
one log message that could help looks like this: |
| 12:03 |
jeff |
$logger->info("updating pickup lib for hold ".$hold->id." while on holds shelf"); |
| 12:04 |
jvwoolf |
jeff++ |
| 12:08 |
jeff |
I believe the "Wrong Shelf" hold status is designed to be noticed if staff are viewing the hold shelf in the staff client, especially the "show clearable holds" part. In our environment, we'd likely use a report for that, similar to how we report on cancelled holds on shelf. |
| 12:11 |
jeff |
I'm not sure without some more digging/testing how the hold would behave, but I think everything would stop regarding that hold and copy until the copy was checked in, at which point it would go in transit to the new pickup_lib. |
| 12:13 |
jvwoolf |
I think I figured out what might be going on |
| 12:13 |
jvwoolf |
Someone is trying to filter the pull list by pickup library, but they're changing the pickup library for the holds on the list instead |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:18 |
jeff |
ouch. |
| 12:20 |
jeff |
we don't have the UPDATE_PICKUP_LIB_FROM_HOLDS_SHELF permission assigned to any groups in our system, so we're safe there. |
| 12:21 |
jvwoolf |
Hm, I didn't know that was a permission |
| 12:22 |
jvwoolf |
But if they're getting changed from the pull list before the hold is captured, doesn't seem like that would help in this situation |
| 12:57 |
|
mantis2 joined #evergreen |
| 13:32 |
mmorgan |
jvwoolf: I think the Wrong Shelf situation can only arise when the pickup lib is changed after the item is already on the holds shelf. |
| 13:39 |
jvwoolf |
mmorgan: Yes, what I'm saying is that the pickup library was changed from the pull list, and then someone noticed the error and changed it back to what it should have been while it was on the shelf |
| 13:41 |
mmorgan |
Ah. Ok, my Friday brain is with you now. So that permission wouldn't help. :-( |
| 13:50 |
|
BDorsey joined #evergreen |
| 14:06 |
|
BAMkubasa joined #evergreen |
| 14:07 |
BAMkubasa |
Friday afternoon inquiry for you... I use the actor.org_unit_descendants function all the time to select anything in all the branches under a system, for example: circ_lib in (select id from actor.org_unit_descendants(512)) |
| 14:08 |
BAMkubasa |
Do any of you know of such a function that would allow me to get the name or shortname of a parent OU? |
| 14:09 |
BAMkubasa |
Like: actor.tell_me_the_parent_shortname(nn) |
| 14:10 |
BAMkubasa |
I always pull in actor.org_unit as branch, then another instance as system, link them by branch.parent_ou, but I think to myself someone smarter than me has got to have gotten tired of doing this |
| 14:12 |
mmorgan |
BAMkubasa: I see there's an actor.org_unit_ancestors() |
| 14:12 |
mmorgan |
I get the appropriate shortnames with this: select shortname from actor.org_unit_ancestors(5) |
| 14:15 |
mmorgan |
Also, I get the shortname of just the parent with this: select shortname from actor.org_unit_ancestor_at_depth(5,1) |
| 14:16 |
BAMkubasa |
hmm, trying to figure out the syntax for calling that within a select statement |
| 14:17 |
BAMkubasa |
so like select username, dob, system_name_of(home_ou) from actor.usr |
| 14:25 |
mmorgan |
BAMkubasa: Something like this? |
| 14:25 |
mmorgan |
select usrname, dob, (select shortname from actor.org_unit_ancestor_at_depth(home_ou,1)) as system_name from actor.usr |
| 14:26 |
BAMkubasa |
YOU! |
| 14:26 |
BAMkubasa |
Looks like that did it mmorgan |
| 14:26 |
mmorgan |
Yay! |
| 14:26 |
BAMkubasa |
awesome, thank you so much. That's been annoying me for far too long |
| 14:27 |
mmorgan |
Glad to help! |
| 14:27 |
* mmorgan |
finds a lot of tips for complex queries buried in the eg code :) |
| 17:03 |
|
jvwoolf left #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:17 |
|
dguarrac joined #evergreen |
| 17:19 |
|
dguarrac left #evergreen |
| 17:30 |
jeff |
why oh why do I have one circulation with a due_date of 2022-08-21 00:59:59-04? :-P |
| 17:31 |
jeff |
in theory it should be 2022-08-20 23:59:59-04 |
