| Time |
Nick |
Message |
| 00:39 |
|
yboston joined #evergreen |
| 01:31 |
|
yboston joined #evergreen |
| 03:31 |
|
yboston joined #evergreen |
| 05:33 |
|
yboston joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2020-09/2020-09-21_04:00:29/test.49.html> |
| 06:10 |
|
yboston joined #evergreen |
| 06:24 |
|
oleonard joined #evergreen |
| 06:34 |
|
tlittle joined #evergreen |
| 06:55 |
|
agoben joined #evergreen |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 08:11 |
|
yboston joined #evergreen |
| 08:12 |
|
mantis1 joined #evergreen |
| 08:27 |
|
mmorgan joined #evergreen |
| 08:41 |
|
Dyrcona joined #evergreen |
| 08:46 |
|
yboston joined #evergreen |
| 08:56 |
|
alynn26 joined #evergreen |
| 08:59 |
|
terranm joined #evergreen |
| 09:01 |
|
yboston joined #evergreen |
| 09:17 |
|
dbwells joined #evergreen |
| 09:17 |
|
nfBurton joined #evergreen |
| 09:22 |
tlittle |
Is anyone familiar with how acq direct charge prorating works? We haven't been using it that much so I haven't looked too hard at it before. We have a library who used a cataloging prorated direct charge, and there's no fund debit in the acq.invoice_item table for it. So...how is that billing the funds if there's no fund debit(s)? |
| 09:28 |
|
collum joined #evergreen |
| 09:30 |
|
rfrasur joined #evergreen |
| 09:33 |
|
yboston joined #evergreen |
| 09:37 |
Dyrcona |
Huh. So updating records with located URIs appears to be faster on Pg 10 than on Pg 9.6, and Pg 12 is an order of magnitude slower than Pg 10 for that. I have not tried Pg 11. |
| 09:38 |
Dyrcona |
Looks like we've got fun times ahead! |
| 09:38 |
rhamby |
ug. not happy to hear that about pg 12. |
| 09:41 |
rhamby |
hmmm pg 12 has a performance hit on inserts with btree indexes from what I'm reading, I wouldn't expect as dramatic a difference as you're seeing though |
| 09:45 |
|
yboston joined #evergreen |
| 09:57 |
|
jvwoolf joined #evergreen |
| 10:02 |
|
yboston joined #evergreen |
| 11:17 |
|
sandbergja joined #evergreen |
| 11:29 |
terranm |
rhamby++ for first signoff during bug squashing week |
| 11:31 |
terranm |
And csharp++ for authoring the first patch that got signed off during bug squashing week |
| 11:37 |
|
oleonard joined #evergreen |
| 11:40 |
csharp |
yay |
| 11:50 |
* gmcharlt |
claims 1236 |
| 11:53 |
pinesol |
[evergreen|Chris Sharp] LP#1788260 - Break out in-house-use non-cat circulations. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1fead69> |
| 11:53 |
pinesol |
[evergreen|Galen Charlton] LP#1788260: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5d404e8> |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:09 |
|
rjackson_isl_hom joined #evergreen |
| 12:23 |
|
khuckins joined #evergreen |
| 12:25 |
|
mrisher joined #evergreen |
| 12:25 |
|
mrisher joined #evergreen |
| 12:31 |
|
collum joined #evergreen |
| 13:00 |
|
sandbergja joined #evergreen |
| 13:55 |
|
jihpringle joined #evergreen |
| 14:42 |
|
jihpringle joined #evergreen |
| 14:43 |
Bmagic |
troubleshooting z39.50 responses from Evergreen. Can I expect it to return bibs that only have copies attached that are in a status (on order) with property: OPAC visible: true, is_available: false |
| 14:44 |
Bmagic |
A library who is using Ingram's Z39.50 tool to lookup their copies in Evergreen, expect to see results in the Ingram search tool, but are not finding them. My theory is that the copies need to be in a different status? |
| 14:55 |
Dyrcona |
Bmagic: Off the top of my head, I think it has to be opac visible, but let me double check. |
| 14:58 |
Bmagic |
Dyrcona: Thanks for checking into that. in this example, the copies are opac_visible but are NOT is_available. The shelving location is opac_visible, holdable, circulate. All "true" |
| 15:00 |
Dyrcona |
Bmagic: zstyle search is a wrapper around regular search. It looks like the "staff" modifier should be applied. Not sure how is_available applies, but the opac visible won't matter. |
| 15:01 |
Bmagic |
The staff modifier should* be applied? Meaning, the code looks like it is invoking a staff search? |
| 15:02 |
Dyrcona |
Yes, that's correct. It is the open-ils.search.biblio.zstyle.staff call. |
| 15:07 |
Bmagic |
Thanks |
| 15:08 |
Bmagic |
Though, if that's the case, then it should be returning these results. I'll look deeper. Dyrcona++ |
| 15:11 |
Bmagic |
weird that there is a method registration for non-staff z39.50 searches |
| 15:11 |
Bmagic |
looks like Z3950.pm only calls the staff one |
| 15:13 |
Dyrcona |
Bmagic: I have a patch that I apply to Z39.50: working/collab/dyrcona/supercat-unquote-z3950 |
| 15:13 |
Dyrcona |
Yeah, pretty much. There's a bit of extra magic that goes on, though. |
| 15:14 |
Bmagic |
interesting |
| 15:15 |
Bmagic |
That is another thing I was trying to accomplish. Wanting the Z39.50 service to do an ISBN search for a type 7 |
| 15:15 |
Bmagic |
<map use="7"><index>eg.isbn</index></map> |
| 15:15 |
Bmagic |
seems to work |
| 15:15 |
Dyrcona |
Yeah, that should work. |
| 15:17 |
Bmagic |
you patch makes the search engine treat a phrase as quoted? Under those conditions? |
| 15:17 |
Bmagic |
you/your |
| 15:18 |
Bmagic |
And just so I understand the idea: You want the results to only show where a "phrase" is matched and not individual words? |
| 15:18 |
Dyrcona |
Bmagic: The opposite, actually. Our state ILL system sends over "=" searches when everyone expects it to act like an "all" search. |
| 15:19 |
Dyrcona |
It looks like the other ILS systems in the state handle it that way. It might help your situation. I don't really know. |
| 15:19 |
Bmagic |
more tools in my chest, thanks! |
| 15:24 |
Dyrcona |
Also, remote z39.50 ends up going through SuperCat. I always forget that. I think the zstyle search is only used by Evergreen, itself, now that I think about it some more. |
| 15:30 |
Dyrcona |
Bmagic ^^ |
| 15:31 |
Bmagic |
oh! |
| 15:31 |
Bmagic |
that chagnes everything |
| 15:34 |
Dyrcona |
Yeah, unfortunately, it does. |
| 15:44 |
|
mantis1 left #evergreen |
| 16:05 |
Bmagic |
Dyrcona: I converted my Z39.50 lookup into a URL: example http://hostname.com/opac/extras/sru/SYSTEM_SHORTCODE/holdings?version=1.2&operation=searchRetrieve&query=eg.isbn%20%3D%200062938010&startRecord=1&maximumRecords=0 |
| 16:05 |
Bmagic |
and I do get resutls. So, I think* if the remote tool is using the right ISBN number, it should also get results |
| 16:08 |
|
collum_ joined #evergreen |
| 16:11 |
Dyrcona |
Bmagic: OK. Assuming it is using the ISBN.... |
| 16:25 |
|
sandbergja joined #evergreen |
| 16:38 |
JBoyer |
doing a quick rebuild of acorn and butternut because oops. |
| 16:39 |
mmorgan |
JBoyer: What, no zucchini? |
| 16:41 |
JBoyer |
Not my favorite, no. I was reminded that pumpkins are also squash though, so keep an eye out for next time. ;p |
| 16:41 |
mmorgan |
JBoyer++ |
| 17:22 |
|
mmorgan left #evergreen |
| 17:24 |
Bmagic |
What do folks do when approving an address throws a database contraint error? ERROR: update or delete on table "usr_address" violates foreign key constraint "actor_usr_billing_address_fkey" on table "usr" |
| 17:27 |
Bmagic |
probably should be a bug |
| 17:54 |
Bmagic |
Turned out I had to uncheck the boxes for "Mailing" and "Physical" on the pending address, then save the patron, then come back and approve the pending addresss |
| 18:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2020-09/2020-09-21_16:00:04/test.49.html> |
| 20:08 |
|
mrisher joined #evergreen |
| 20:41 |
|
sandbergja joined #evergreen |
| 20:46 |
|
sandbergja joined #evergreen |
| 22:14 |
|
sandbergja joined #evergreen |
| 23:24 |
|
sandbergja joined #evergreen |
