| Time |
Nick |
Message |
| 00:44 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 07:53 |
|
rfrasur joined #evergreen |
| 08:13 |
|
remingtron__ joined #evergreen |
| 08:13 |
|
Dyrcona joined #evergreen |
| 08:16 |
|
remingtron joined #evergreen |
| 08:24 |
|
jvwoolf joined #evergreen |
| 08:31 |
|
mantis joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:37 |
|
alynn26 joined #evergreen |
| 08:58 |
|
dbwells_ joined #evergreen |
| 09:38 |
|
jvwoolf joined #evergreen |
| 09:55 |
|
sandbergja joined #evergreen |
| 09:58 |
|
sandbergja_ joined #evergreen |
| 11:23 |
Bmagic |
hey yall - trying to get the Evergreen server z39.50 to scope to a certain system. I thought that a new xml clause in the dgo.conf would do it. Introducing a new external facing "database" name complete with a child element like this: <zurl>http://localhost/opac/extras/sru/SYSTEMNAME/holdings</zurl> |
| 11:25 |
Bmagic |
The z39.50 server and simple2zoom daemons are running and responding. The trouble is: it seems to be providing results for the whole consortium and not just the one specified SYSTEMNAME (actor.org_unit.shortname) |
| 11:26 |
berick |
Bmagic: maybe you have to set a depth value as well? |
| 11:27 |
Bmagic |
not seeing an entry in that xml block for depth |
| 11:27 |
berick |
i mean in the URL |
| 11:29 |
Bmagic |
got an example of what you mean? |
| 11:30 |
Bmagic |
like th is: <zurl>http://localhost/opac/extras/sru/SYSTEMNAME/holdings?depth=1</zurl> ? |
| 11:31 |
berick |
Bmagic: i'm just guessing. a lot of the supercat-ish URLs have a depth option |
| 12:04 |
jeffdavis |
<zurl>http://localhost/opac/extras/sru/SYSTEMNAME/holdings</zurl> works here, we don't do anything else to scope results that I know of |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:28 |
Bmagic |
jeffdavis: using exactly that, I did a test query against the whole DB (Defined like this: <zurl>http://localhost/opac/extras/sru</zurl> ) - then did the exact same query against the SYSTEMNAME DB - with exactly the same result set. Furthermore, I grabbed the control number from the output and looked that bib up in the database, there were no holdings for my SYSTEMNAME on that bib |
| 12:33 |
jeffdavis |
Bmagic: does the Evergreen search string generated for your SYSTEMNAME search contain site:SYSTEMNAME as a search param? |
| 12:34 |
Bmagic |
would that be spit out STDOUT from simple2zoom? |
| 12:35 |
jeffdavis |
it would be in the EG logs |
| 12:36 |
Bmagic |
checking |
| 12:37 |
Bmagic |
it sure does |
| 12:38 |
Bmagic |
site(SYSTEMNAME) |
| 12:40 |
jeffdavis |
And yet EG is ignoring that search param |
| 12:42 |
jeffdavis |
If you take the same EG search string and run it directly (rather than via Z39.50/SRU), are the results scoped correctly? |
| 12:42 |
Bmagic |
openils.search.biblio.multiclass.query HASH(0x627b920), eg.title:"goblet of fire" && eg.author:rowling site:SYSTEMNAME, 1 |
| 12:42 |
Bmagic |
seems legit to me |
| 12:43 |
Bmagic |
using the http://www.loc.gov/z3950/test.html tool |
| 12:48 |
Bmagic |
that last "1" at the end is depth? |
| 12:55 |
Bmagic |
jeffdavis: I think the issue is that lookup tool |
| 12:55 |
Bmagic |
it must cache or something |
| 12:56 |
Bmagic |
I used my perl tool, and got my scoped results! sorry for the confusion |
| 13:00 |
jeffdavis |
Glad it's working as intended! |
| 14:00 |
|
sandbergja joined #evergreen |
| 15:16 |
* Dyrcona |
thinks we need a Perl patron load script to better handle errors. I'm sure the original author of the SQL script never imagined a library would leave and come back. |
| 15:38 |
mmorgan |
What's the best way to handle this situation: |
| 15:38 |
mmorgan |
An item is in transit to fill a hold at a different library, but delivery is suspended, so the owning library wants to get it out of transit and make it available for their local patrons. |
| 15:39 |
mmorgan |
They can retarget the hold, and cancel the transit, but then it needs to be checked in again to clear the cancelled transit status. |
| 15:40 |
mmorgan |
If there's a local hold, the item will stay home, but if there is no local hold, it will go in transit again. I know they can use the suppress holds and transits checkin modifier, but that will miss the local holds. |
| 15:40 |
mmorgan |
Has anyone found a good way to handle this without jumping through so many hoops? |
| 15:41 |
Bmagic |
we haven't |
| 15:41 |
alynn26 |
nope |
| 15:46 |
jeff |
you can update selection_depth and retarget holds to avoid the problem of having items be captured and placed in transit to fill holds that can't be filled because of lack of delivery service. |
| 15:47 |
jeff |
not very simple if you have some libraries with delivery and some without, though. |
| 15:47 |
* mmorgan |
was hoping to avoid messing with holds and rules. |
| 15:48 |
jeff |
make a new age hold protection rule and set it on all the copies at the library in question? |
| 15:49 |
mmorgan |
I was hoping I was missing something obvious, but guess not :-( |
| 15:49 |
jeff |
might not. |
| 15:49 |
jeff |
we're going to be putting our holds back into "in transit" status and resetting notifications. i'm looking to see how tricky that's going to be. |
| 15:50 |
mmorgan |
jeff: age hold protection works off of create date or active date, so might work for newer stuff. But still needs to be set in all items, and some of them have age protection settings already... |
| 15:50 |
jeff |
we will then scan the items to re-print a new slip, trigger new notification, etc. |
| 15:51 |
jeff |
mmorgan: yeah, you'd have to preserve and restore any existing ahp settings you cared about. |
| 15:52 |
mmorgan |
jeff: You mean you're putting holds that are currently on the hold shelf into transit status? |
| 15:53 |
jeff |
mmorgan: right. the end result will be as if they had all been checked in with "capture local holds as transits" |
| 15:55 |
mmorgan |
Okay, I get it. So the goal is to resend notifications to patrons when libraries are ready to start checking them out. |
| 15:57 |
mmorgan |
We are resending notifications for items that have been on the hold shelf since libraries closed with a trigger that uses the hold_request.shelf_expires_soon hook. |
| 15:58 |
mmorgan |
When a library tells us they're ready, that is. |
| 15:59 |
jeff |
we want the holds to not show up as "ready for pickup", and we want the library to be able to control how many patrons start coming their way / start calling to schedule curbside pickups. |
| 15:59 |
mmorgan |
Makes sense! |
| 15:59 |
jeff |
also, we're re-printing hold slips without aliases on them during the time we're doing curbside. |
| 15:59 |
jeff |
so touching each item isn't an additional step/burden. |
| 16:00 |
|
mantis left #evergreen |
| 16:00 |
jeff |
we have another set of (ILL/MeLCat) items waiting on the shelf which won't be re-processed, we'll just reset and re-send notifications for them. |
| 16:01 |
jeff |
for those, we're giving staff a list to make sure the items are still there... before we (re)notify about something that's stuck in some bin somewhere far far away. |
| 16:17 |
|
jihpringle joined #evergreen |
| 16:18 |
jeff |
I think we're also going to modify our holds pull list reports to give ourselves the option of printing just items for patrons who already have an item on the shelf. Probably depend on how many items that turns out to be. |
| 16:19 |
* mmorgan |
is wondering about applying a transit range of system to all the hold policies in the db.... |
| 16:19 |
jeff |
(wouldn't affect targeting / queue position, just trying to catch items on the pull list already for patrons who we know we're about to have come pick up soon) |
| 16:20 |
jeff |
mmorgan: if you update the policies, keep in mind that you'll also need to update and potentially retarget existing outstanding uncaptured holds. selection_ou and selection_depth are fields on the hold request. |
| 16:21 |
mmorgan |
jeff++ |
| 16:21 |
mmorgan |
I thought there must be a flaw in my logic :) |
| 16:55 |
mmorgan |
jeff: So I'm testing adding transit ranges to hold policies, and am not seeing that holds get a selection_depth. The transit range added to hold policies applies to holds placed prior to the rule change. |
| 16:56 |
mmorgan |
Is selection_depth only used set by boundaries? |
| 16:56 |
mmorgan |
s/used// |
| 16:57 |
jeff |
hard boundary is what ends up in selection_depth, i think. |
| 16:57 |
jeff |
i don't know if there are other circumstances where something else influences selection_depth |
| 16:57 |
mmorgan |
Ok, transit range in a hold policy looks to be consulted on the fly. |
| 16:58 |
jeff |
now i'm curious to look into transit range more closely. |
| 17:00 |
jeff |
ah yes, we use this. |
| 17:08 |
jeff |
i think that transit_range would be consulted at targeting and capture time, but I might be misreading in a hurry. |
| 17:11 |
mmorgan |
Judging by behavior, it appears to happen at capture time. Hold copy map includes items outside the transit range, though, so maybe it's not consulted at targeting? |
| 17:12 |
|
alynn26_away joined #evergreen |
| 17:15 |
jeff |
well, in a different way at targeting time. i meant it would affect "current copy" / "best hold". |
| 17:16 |
jeff |
but i wasn't thinking about hold copy maps. |
| 17:19 |
* mmorgan |
needs to sign off, brain needs a recharge. Will revisit this on Monday. Good weekend #evergreen! |
| 17:19 |
mmorgan |
jeff++ |
| 17:19 |
|
mmorgan left #evergreen |
| 17:52 |
|
alynn26 joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:01 |
|
sandbergja joined #evergreen |
| 19:02 |
|
sandbergja joined #evergreen |
| 20:05 |
|
jvwoolf joined #evergreen |
