| Time |
Nick |
Message |
| 02:29 |
|
jeff_ joined #evergreen |
| 05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:02 |
|
gmcharlt joined #evergreen |
| 06:54 |
|
Callender joined #evergreen |
| 07:36 |
|
collum joined #evergreen |
| 07:56 |
|
rjackson-isl joined #evergreen |
| 08:02 |
|
jboyer-home joined #evergreen |
| 08:08 |
|
ericar joined #evergreen |
| 08:21 |
|
akilsdonk joined #evergreen |
| 08:22 |
|
mrpeters joined #evergreen |
| 08:23 |
|
kmlussier joined #evergreen |
| 08:23 |
|
Shae joined #evergreen |
| 08:32 |
|
remingtron joined #evergreen |
| 08:39 |
|
tspindler joined #evergreen |
| 08:51 |
|
kbeswick joined #evergreen |
| 09:20 |
|
yboston joined #evergreen |
| 09:48 |
kmlussier |
Good morning all! |
| 09:51 |
jeff |
morning! |
| 09:53 |
kmlussier |
I'm curious abotu berick's code at bug 1308239. We had tinkered with the idea of using precats for ILL's from our statewide system, but in my testing, I found that Evergreen won't allow me to check out an existing precat. |
| 09:53 |
pinesol_green |
Launchpad bug 1308239 in Evergreen "Support targeting and fulfillment of precat copy holds (for ILL)" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1308239 |
| 09:53 |
kmlussier |
I'm wondering if that code would fix that issue. |
| 09:54 |
jeff |
I'm pretty sure we've had libraries that used precats for ILL, but I'm not certain of their workflow. They may not have been capturing and using the system for notification -- they might just have been calling the patron then checking out the item as a pre-cat (using the originating library's barcode, which is one of the reasons they moved away from that). |
| 09:54 |
jeff |
Sorry, that doesn't help much. |
| 09:55 |
* csharp |
is pretty sure PINES libraries use precats for ILL too |
| 09:55 |
jeff |
Won't let you check out an existing precat? As in, it steps you through the "not cataloged or mis-scanned, circ as pre-cat?" workflow again? |
| 09:55 |
kmlussier |
jeff: Yes, exactly. |
| 09:55 |
kmlussier |
I had the precat in the system, I tried using the same barode again to check out, and I got the usual "not cataloged" response. |
| 09:56 |
|
krvmga joined #evergreen |
| 09:56 |
jeff |
I have interest in that feature / bugfix. I'm not grabbing the bug now, but will try to review when I can. |
| 09:56 |
kmlussier |
Our preference is to use precats, because the alternative is to use brief bib records that automatially deleted when the item is returned. But then it fills up the database with all of these deleted bib records. |
| 09:56 |
jeff |
kmlussier: That behavior is surprising, but I haven't tested it. |
| 09:57 |
krvmga |
we just upgraded to 2.5 and i'm getting complaints about the labeling of icons in search returns. i've been looking around but i can't see where to fix/alter the labels. anyone know off hand? |
| 09:57 |
jeff |
Yeah, we do that now with NCIP. It's not ideal compared with precats. |
| 09:57 |
jboyer-home |
I don’t know if ILL handling is consistent across Evergreen Indiana, but I know at my previous library they used the OCLC ILL number as the barcode, so there wasn’t a problem with re-using barcodes like that, then to keep things tidy the pre-cats are deleted later. |
| 09:57 |
kmlussier |
jeff: We do that now too, but since we're moving to a new statewide system soon, it's a good time to change things. :) |
| 09:57 |
eeevil |
kmlussier: berick's code allows holds on precats ... the UI-level popup you're getting would not be gone, IIRC, but automated process that don't use the UI would be allowed to do their thing |
| 09:58 |
kmlussier |
eeevil: OK, thanks for the info! |
| 09:58 |
eeevil |
kmlussier: IOW, that change is intended for automated workflows, not human ones |
| 09:59 |
kmlussier |
eeevil: Well, our workflow starts off automated. The holds would be placed by an automated process. But, in the end, a human needs to check out the material to the patron. |
| 09:59 |
kmlussier |
Until we get circ robots. |
| 09:59 |
eeevil |
that should work fine |
| 10:00 |
eeevil |
because the "is this on the hold shelf?" check would push past the roadblock you're hitting |
| 10:00 |
kmlussier |
eeevil: Ah, ok. That sounds promising. |
| 10:01 |
eeevil |
but you have to target and capture the hold for that to happen .. that change allows an automated process to do exactly that |
| 10:01 |
jeff |
In our statewide system, since the holds are broker-mediated (DCB-3 NCIP application profile, iirc), the checkouts are not done in the Evergreen staff client, they're performed in the DCB client. |
| 10:01 |
|
BigRig joined #evergreen |
| 10:24 |
|
rfrasur joined #evergreen |
| 10:35 |
jboyer-home |
OPAC Fun: When doing an advanced search, can you enter terms in a single Author search field that are in the 100 and 700 and get results? |
| 10:36 |
kmlussier |
jboyer-home: My guess is no. |
| 10:36 |
jboyer-home |
I’m seeing an example where you can either search for the 100 author in one field, and then AND the 700 author in another search field. |
| 10:37 |
jboyer-home |
kmlussier: that’s what I was thinking too, but I didn’t know how the query parser broke down (or doesn’t) what you enter into each field. |
| 10:37 |
rjackson-isl |
Are you referrinf to the Derek Benz Lewis search? It gets nothing |
| 10:37 |
kmlussier |
Actually, I think two of the MassLNC consortia have a custom index that combines all authors into one index, so it would probably work in that instance. |
| 10:38 |
jboyer-home |
rjackson-isl: Yes. I knew it didn’t work, I didn’t know if that was expected. |
| 10:40 |
jboyer-home |
kmlussier: Was that done to address a lot pf patron confusion, or as an experiment in opac improvement, or ? |
| 10:41 |
kmlussier |
jboyer-home: We actually did it because we preferred one author facet on the search results screen instead of segmenting them into different types of facets. But I guess it has other positive side effects. |
| 10:42 |
kmlussier |
jboyer-home: If I understand eeevil's comments here correctly - https://bugs.launchpad.net/evergreen/+bug/1169693/comments/2 - you would need to turn on combined indexes to get that search to work. But combining indexes caused some other problems with relevance. |
| 10:42 |
pinesol_green |
Launchpad bug 1169693 in Evergreen "keyword relevancy ranking in 2.4" (affected: 1, heat: 6) [Medium,Fix released] |
| 10:43 |
kmlussier |
That is, we didn't want to segment the facets into different types of authors. |
| 10:45 |
jboyer-home |
We’ll probably skip combining them if there’s any change to relavancy, but I don’t think anyone that doesn’t catalog has ever cared about the difference between personal corporate and other, so we may look into one big author index. |
| 10:45 |
jboyer-home |
Thanks kmlussier! |
| 10:49 |
krvmga |
we just upgraded to 2.5 and i'm getting complaints about the labeling of icons in search returns. i've been looking around but i can't see where to fix/alter the labels. anyone know off hand? |
| 10:52 |
kmlussier |
krvmga: I don't know of an easy way to do that. IIRC, the icon labels don't leverage the labels used in Coded Value Maps. |
| 10:52 |
kmlussier |
But here's looking forward to 2.6 where you can call the icons anything you want. :) |
| 10:53 |
krvmga |
kmlussier: yes, i'm looking forward to 2.6. in the meantime, i'm getting emails "this is confusing" "this release is a step backward" and so on. |
| 10:54 |
krvmga |
kmlussier: i'm thinking of removing the labels entirely for the time being. |
| 10:54 |
krvmga |
kmlussier: the display of the labels, that is |
| 10:56 |
kmlussier |
krvmga: It looks like NOBLE successfully changed theirs. Maybe you can send the question their way. |
| 11:04 |
|
vlewis joined #evergreen |
| 11:21 |
|
ktomita joined #evergreen |
| 11:21 |
kmlussier |
krvmga: I'm looking at some old commits, and I think I was wrong when I said that the icons aren't looking at the Coded Value Map labels. I think they do. |
| 11:22 |
kmlussier |
krvmga: However, I think C/W MARS adjusted the values for the Coded Value Maps, not the labels, because you went live on tpac before the labels were available. So you might want to try adding those labels and see if it works. |
| 11:23 |
kmlussier |
krvmga: And a little birdie tells me that after you add those labels, you'll need to reload apache on all of your brick heads, doing a rotation. |
| 11:24 |
krvmga |
kmlussier: thanks. i'll check it out. |
| 12:02 |
|
RoganH joined #evergreen |
| 12:16 |
|
hbrennan joined #evergreen |
| 12:42 |
|
ldw joined #evergreen |
| 12:42 |
ldw |
dge |
| 12:43 |
ldw |
That is three letters from my password. Not sure what was going on with my cursor focus there. |
| 12:44 |
kmlussier |
ldw: You're not the first person to share his password with the #evergreen channel. :) |
| 12:51 |
|
krvmga_ joined #evergreen |
| 12:56 |
* tsbere |
would be shocked if ldw is the last to do that |
| 12:57 |
ldw |
I will probably do it again at some point :) |
| 13:04 |
|
RoganH joined #evergreen |
| 13:07 |
|
rfrasur_ joined #evergreen |
| 13:25 |
|
kbeswick joined #evergreen |
| 13:38 |
krvmga_ |
i'm sure there's a perfectly logical explanation for this but when i search on a thirteen digit isbn in the opac, the record i'm looking for comes up but, when i look at the marc, the isbn is not there. how did that happen? |
| 13:39 |
jeff |
krvmga_: this is when performing an identifier search, or a keyword search? |
| 13:39 |
krvmga_ |
jeff: it works the same way both as a keyword search and in numeric search for isbn |
| 13:40 |
jboyer-home |
krvmga: It’s not there in any form, or there’s only a 10 digit ISBN? |
| 13:40 |
jboyer-home |
Because I think the indexes normalize the ISBNs to 13 digits for simplified searching. |
| 13:40 |
krvmga_ |
jboyer-home: not there at all |
| 13:41 |
jeff |
there is intentional logic to enable searching for isbn10 or isbn13, even if the record doesn't contain the one used in the search. i thought it might only affect the identifier indexes, though. |
| 13:41 |
jboyer-home |
I see. Whichcraft it is. |
| 13:41 |
jeff |
krvmga_: cached search and recently modified record? |
| 13:41 |
krvmga_ |
actually, i lied. there's a ten digit isbn there but it's slightly different from the one i searched for |
| 13:41 |
krvmga_ |
ends in a zero instead of a one |
| 13:42 |
jboyer-home |
The last digit can be different (It’s a check digit, and will almost never be the same in a 10 and it’s associated 13) |
| 13:42 |
jeff |
there are some places where an isbn with an invalid check digit will have its check digit "corrected" during normalization/indexing. that could explain what you're seeing. |
| 13:42 |
krvmga_ |
jboyer-home: i did not know that. this is fascinating information. |
| 13:42 |
jeff |
krvmga_: can you link to the record and to the search? |
| 13:43 |
krvmga_ |
jeff: i knew there was a logical explanation soewhere. |
| 13:43 |
jboyer-home |
I talked a lot with our cataloger when “the big switch” was coming. It was interesting. |
| 13:43 |
krvmga_ |
http://bark.cwmars.org/eg/opac/record/2596995?query=9780394826141;qtype=keyword;locg=1;expand=marchtml#marchtml |
| 13:43 |
krvmga_ |
you can see that the ten digit isbn is there, except ending in 0 |
| 13:44 |
jeff |
you can calculate an isbn13 for every isbn10, and yes, the check digit will (almost?) always change. you can also calculate the isbn10 for half of the isbn13 namespace, and we haven't started using the second half yet -- at least, I don't think we have... |
| 13:45 |
krvmga_ |
jeff++ |
| 13:45 |
krvmga_ |
jboyer-home++ |
| 13:48 |
jcamins |
jeff: I've seen non-convertable isbn13s. |
| 13:48 |
jeff |
krvmga_: i see both the isbn10 0394826140 and its isbn13 counterpart 9780394826141 as "invalid" isbns on that record (they're in subfield z) -- that doesn't seem to mesh with what you were reporting -- that the isbn searched didn't show up at all in the record |
| 13:48 |
jeff |
jcamins: starting with 979? |
| 13:49 |
jcamins |
jeff: yep. |
| 13:49 |
jcamins |
I don't know if they were real ISBNs, of course. |
| 13:49 |
jcamins |
In fact, I suppose all else being equal, I can probably assume they were fake. |
| 13:51 |
jcamins |
jeff: looks like it might've been real. It was a French book. |
| 13:51 |
jeff |
looks like France, the Republic of Korea, and Italy are starting to live in 979 |
| 13:53 |
krvmga_ |
jeff: i was wrong and misread the record. the ten digit isbn was there, just with a different check digit. when i was scanning i was looking for the same last number. |
| 13:53 |
jeff |
krvmga_: aha |
| 13:53 |
jeff |
krvmga_: both both the ten and thirteen are there. |
| 13:54 |
krvmga_ |
jeff: since we started talking about it, one of our catalogers overlaid the record. :) |
| 13:54 |
krvmga_ |
she just told me. |
| 13:55 |
jeff |
the perils of testing theories on live systems. :-) |
| 14:00 |
|
DPearl1 joined #evergreen |
| 14:00 |
|
tspindler joined #evergreen |
| 14:01 |
|
krvmga_ joined #evergreen |
| 14:04 |
|
kbeswick_ joined #evergreen |
| 14:07 |
jeff |
Business::ISBN does the right thing and returns undef when you call as_isbn10 on a 979 isnb13 :-) |
| 14:13 |
jeff |
OpenILS::WWW::AddedContent::Amazon might fail on the 979 isbn13s, but probably not in a way that impacts anything else. |
| 14:19 |
|
bmills joined #evergreen |
| 14:23 |
|
tspindler left #evergreen |
| 14:23 |
|
tspindler joined #evergreen |
| 14:35 |
|
kmlussier joined #evergreen |
| 14:38 |
kmlussier |
jeff/krvmga: By default, the 10/13 digit ISBN conversion is only with the identifier search, but C/W MARS has a custom index to do the conversion for a keyword search too. |
| 14:40 |
jeff |
kmlussier++ thanks! |
| 15:14 |
|
akilsdonk_ joined #evergreen |
| 15:57 |
|
dreuther joined #evergreen |
| 16:10 |
kmlussier |
It's as quiet as a library in here today. |
| 16:17 |
rangi |
not this library http://www.tetakere.org.nz/ |
| 16:18 |
kmlussier |
Truth be told, I don't think I've ever worked in a quiet library. |
| 16:18 |
rangi |
*nod* |
| 16:19 |
kmlussier |
rangi: Is that your public library? |
| 16:19 |
rangi |
thats where Koha started |
| 16:19 |
rangi |
and Kete |
| 16:19 |
kmlussier |
Nice! |
| 16:19 |
rangi |
it didnt look like that back then though :) |
| 16:20 |
rangi |
more like this http://www.tetakere.org.nz/horowhenuas-history/ |
| 16:20 |
rangi |
they fundraised as a community, bought the supermarket next door, and took over that |
| 16:21 |
rangi |
they now have a massive youth space, complete with a recording studio |
| 16:21 |
rangi |
https://www.youtube.com/watch?v=lUdgF73bx7Q and even a sonata :) |
| 16:21 |
rangi |
the whole district has a pop of 30k .. its quite an amazing story really |
| 16:25 |
kmlussier |
I love seeing libraries that do so much to engage with their communities. Almost makes me wish I were working in a library again. Almost. |
| 16:32 |
|
tspindler left #evergreen |
| 16:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
phasefx2 |
bbl |
| 17:18 |
jeffdavis |
When upgrading a standalone db server from 2.4->2.6, it looks to me like there are no new dependencies that need to be installed. Can anyone confirm that? |
| 17:20 |
bshum |
jeffdavis: I haven't found anything specific yet. Though I think I did find that one of the upgrade scripts required an extra deb than before for me to run it on a fresh standalone DB. |
| 17:22 |
bshum |
jeffdavis: libxml-libxslt-perl was the package I needed to add on our fresh DB - http://irc.evergreen-ils.org/evergreen/2014-05-24#i_100892 |
| 17:23 |
jeffdavis |
thanks bshum! |
| 17:23 |
bshum |
But that was on a fresh DB build with 14.04. On our older servers, I didn't have to install any extra dependencies for quite some time now. |
| 17:23 |
bshum |
Probably since 2.3ish or whenever Rose::URI got added. |
| 17:28 |
jeffdavis |
We're sticking with our old db server for this weekend's upgrade, so we should be ok there (and that specific package is already installed). Thanks again. |
| 17:28 |
jeffdavis |
Now back to figuring out why reingest generated 600GB of WAL xlog in 4 hours. :S |
| 17:35 |
|
Wyuli joined #evergreen |
| 17:50 |
Wyuli |
My Google-Fu must be getting weak; re-installing Evergreen client v.2.5.2 on a staff computer, and not finding a handy way to enable developer options. (Mostly, I just want the handy Clear Cache button) |
| 17:51 |
Wyuli |
Am I missing something painful(ly obvious)? |
| 17:53 |
bshum |
Wyuli: I'm not 100% sure on this (it's been awhile, since I looked) but I think the Clear Cache button and other dev options only appear on the client if it's built with the debug enabled. |
| 17:53 |
bshum |
By default, I don't think most clients would ship that way. |
| 17:56 |
bshum |
I think you can still clear cache via the admin -> for developers menu option |
| 17:56 |
bshum |
If you have the permission for the staff user account for debug options. |
| 17:58 |
Wyuli |
Ah, that will do it! |
| 17:58 |
Wyuli |
bshum++! |
| 18:02 |
bshum |
Yeah, in the past, I think the debug options were always present at the login screen for the staff client. But more recently (probably since 2.2ish) that has not been the case. |
| 18:02 |
bshum |
It looks like one could add them during client building by passing "make devbuild" as one of the options during the creation of the client. |
| 18:02 |
bshum |
But you may not be digging that deep at options. |
| 18:03 |
bshum |
For the logs: http://wiki.evergreen-ils.org/doku.php?id=mozilla-devel:building_the_staff_client#developer_build |
| 18:03 |
bshum |
That variable pulls in an extra file during build for external/developers.js and that file seems to contain pref options for the staff client that add the debug options to the client. |
| 18:04 |
bshum |
So I imagine one could also modify their own client with the about:config and set the prefs to enable debug options in their client. |
| 18:10 |
kmlussier |
bshum: Aren't you supposed to be on vacation? :) |
| 18:10 |
bshum |
kmlussier: I got distracted, but I'll disappear again shortly :) |
| 18:11 |
kmlussier |
@dessert bshum |
| 18:11 |
* pinesol_green |
grabs some Pecan Pie for bshum |
| 18:12 |
bshum |
I think I'm actually going to get chocolate fudge cake tonight. |
| 18:13 |
* bshum |
is heading to the cheesecake factory later in a bit to meet up with his folks |
| 19:22 |
|
kmlussier joined #evergreen |
| 23:39 |
|
serflog joined #evergreen |
| 23:39 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 23:41 |
|
pinesol_green joined #evergreen |
| 23:43 |
|
csharp joined #evergreen |
