Time |
Nick |
Message |
00:35 |
|
aliceR joined #evergreen |
06:36 |
|
eeevil joined #evergreen |
06:36 |
|
mtate joined #evergreen |
06:37 |
|
phasefx joined #evergreen |
06:37 |
|
TaraC joined #evergreen |
06:37 |
|
Callender joined #evergreen |
06:38 |
|
graced joined #evergreen |
07:39 |
|
rjackson-isl joined #evergreen |
07:53 |
|
remingtron joined #evergreen |
07:59 |
|
jboyer-isl joined #evergreen |
08:00 |
|
kmlussier joined #evergreen |
08:18 |
|
mrpeters joined #evergreen |
08:22 |
|
akilsdonk joined #evergreen |
08:25 |
|
Shae joined #evergreen |
08:40 |
kmlussier |
Happy Monday everyone! |
08:47 |
|
mmorgan joined #evergreen |
09:20 |
|
mdriscoll joined #evergreen |
09:22 |
dbwells |
kmlussier: I am still getting "You mentor application for this program is awaiting admin approval" :( |
09:24 |
kmlussier |
dbwells: Thanks for letting me know. I was wondering about that since I hadn't heard from marina. |
09:25 |
kmlussier |
dbwells: I need to leave for a meeting fairly soon. What I'll do is put the applications into a Google doc and share it with all of you so that you can have some time to review them. |
09:25 |
dbwells |
Sounds like a plan, thanks. |
09:25 |
jeff |
kmlussier: happy monday! |
09:33 |
dbs |
kmlussier++ |
09:33 |
dbs |
<-- same situation as dbwells |
09:34 |
dbs |
discrimination against Dans, clearly. |
09:34 |
dbwells |
well, I can't blame them |
09:35 |
dbs |
"Are you _sure_ you want Dan (Scott|Wells) as a mentor? _Really_?" |
09:36 |
dbwells |
:D |
09:38 |
kmlussier |
LOL - I suspect it's happening to anyone who created their account Friday, not just the Dans. |
09:45 |
|
yboston joined #evergreen |
09:53 |
* berick |
changes his name to Dan |
10:05 |
kmlussier |
dbs, dbwells, berick: Before I disappear for the day, did you get the notification from Google for the shared OPW Applications folder? |
10:06 |
berick |
kmlussier: yes, thanks |
10:06 |
dbwells |
kmlussier: Yes |
10:07 |
kmlussier |
Great! I'll see you all tomorrow. |
10:48 |
|
RoganH joined #evergreen |
11:01 |
|
dreuther joined #evergreen |
11:04 |
|
ericar joined #evergreen |
11:08 |
|
Dyrcona joined #evergreen |
11:25 |
|
aliceR joined #evergreen |
11:30 |
|
krvmga joined #evergreen |
11:30 |
krvmga |
i've found a little bug but i'm not quite sure how to describe it. |
11:31 |
krvmga |
this is in the opac, eg 2.5 |
11:31 |
krvmga |
if your search returns an item that has exactly 10 copies and you look at the item record |
11:31 |
krvmga |
you see the 10 copies and, under it "Next 10 .." and "Show more copies" |
11:32 |
krvmga |
if you click on "Next 10", you get the record but with no copies listed. |
11:32 |
krvmga |
if you click on Show more copies, the link "Next 10 >>" goes away |
11:32 |
krvmga |
if you'd like to see this in action, here's a search in our catalog |
11:32 |
krvmga |
http://bark.cwmars.org/eg/opac/record/2084863?query=loeb%20livy;qtype=keyword;locg=1;copy_offset=0;copy_limit=0 |
11:33 |
krvmga |
i want to put this on launchpad. how would you describe it? |
11:33 |
Dyrcona |
I think that, or something very much like it, may have already been submitted on Launchpad. |
11:33 |
krvmga |
Dyrcona: if that's so, my day just got simplified :) |
11:34 |
krvmga |
i found it on launchpad |
11:35 |
krvmga |
https://bugs.launchpad.net/evergreen/+bug/1274999 |
11:35 |
pinesol_green |
Launchpad bug 1274999 in Evergreen "Next 10 Link erroneously available at the end of holdings in OPAC, intermittent " (affected: 1, heat: 6) [Undecided,Incomplete] |
11:35 |
krvmga |
i'm happy to see Erica Rohlfs also had some difficulty articulating it. :) |
11:36 |
krvmga |
i'll add my example because i can get it to happen every time. (the bug is marked intermittent) |
11:37 |
Dyrcona |
krvmga: You should set it to confirmed, also. |
11:38 |
krvmga |
Drycona: will do. thanks :) |
11:39 |
Dyrcona |
krvmga++ |
11:43 |
|
b_bonner joined #evergreen |
11:50 |
jeff |
Dyrcona: looking at a task here and thinking you may have tackled something similar before. |
11:50 |
Dyrcona |
jeff: Could be. What is it? |
11:50 |
jeff |
Dyrcona: I think the last time I looked, your safari bib load scripts delete-then-create, but some of your backstage scripts overlay existing bibs? |
11:51 |
jeff |
I'm looking to make our e-resource bib loads better, starting with OverDrive, where we have some existing poorer-quality bibs that I'd like to overlay. |
11:52 |
Dyrcona |
jeff: I'm pretty sure it just replaces the MARC field. |
11:53 |
Dyrcona |
Someone on staff here uploads OverDrive records by hand, but the Safari load is probably close to what you want. |
11:53 |
jeff |
boy do i have a lot of git clones in my homedir... |
11:53 |
Dyrcona |
We are planning to expand it into something that we can use for more vendors. |
11:54 |
jeff |
cool. i'll share what i come up with, regardless of if it ends up being based on yours or not. |
11:55 |
Dyrcona |
That reminds me that I was supposed to add a new bib source for electronic database records and change the source on some records in buckets. |
11:55 |
jeff |
bre.source++ |
11:56 |
Dyrcona |
indeed: bre.source++ |
12:01 |
mdriscoll |
jeff: we use marc_stream_importer.pl to load and overlay lots of e-resource records. It honors Vandelay match sets and merge profiles. |
12:05 |
jeff |
mdriscoll: ah! something i had thought of before but not today. thanks! |
12:05 |
jeff |
i was thinking "man, vandelay does a lot of this for me..." |
12:06 |
jeff |
a long long time ago when i was batch loading bibs via the OpenSRF json gateway, I think I stumbled upon an encoding issue where it was impossible to use an unmodified LWP to send marc data to the bib import method. I wonder if that's still the case... |
12:07 |
jeff |
mdriscoll: in your environment, are you just using a local utility script that reads MARC data from files received from a vendor, then streams them to marc_stream_importer.pl? |
12:08 |
berick |
jeff: it can read marc files, too |
12:08 |
berick |
from the file system, i mean |
12:08 |
jeff |
berick: thought that it might -- just reading source again now :-) |
12:11 |
jeff |
--nodaemon and --spoolfile |
12:12 |
mdriscoll |
jeff: what berick said. You specify the marc file on the command line along with queue you want to use (which is associated with a record match set), a bib source, and merge profile. |
12:14 |
mdriscoll |
I use something like this: ./marc_stream_importer.pl --spoolfile mymarc --user xxx --password xxx --source 101 --merge-profile 4 --queue 9670 --auto-overlay-best-match --nodaemon |
12:21 |
jeff |
can anyone (berick?) give an example of why you might choose to use --import-by-queue? |
12:22 |
jeff |
at first glance, it looks like two different strategies for doing the same thing, just one grabs the record ids to import into memory and then imports them, the other lets the vandelay backend worry about handling that? |
12:23 |
jeff |
looks like that came about in commit 580c8a2 |
12:23 |
pinesol_green |
[evergreen|erickson] added option to import records by record list in addition to queue-level imports; eval doesn't like being exited via 'last', rearranged sysread loop to accommodate; changed merge param to merge-profile - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=580c8a2> |
12:24 |
berick |
jeff: that's pretty much it. the script started using queue only, but that doesn't work well in practice if you use the same queue over and over |
12:25 |
berick |
because it can fill up with import failures, then each import takes longer re-trying the failed records |
12:29 |
jeff |
berick: ah, and with --import-by-queue marc_stream_importer.pl never sees the successful/failed record IDs, and thus can't clean them up? |
12:29 |
jeff |
(I think that's what I just read in marc_stream_importer.pl and Vandelay.pm) |
12:30 |
berick |
jeff: yes, that too. i forgot about the cleanup step |
12:31 |
berick |
if you created a new queue w/ each import and wanted to retain everything for your records, by-queue would work well |
12:31 |
berick |
but if you use the same queue over and over and don't need to keep the successful import data around, by-queue is not so good. |
12:33 |
jeff |
remembering a gotcha from previous vandelay match profiles -- at lest when I did this last, there was no matching/duplicate detection performed within the vandelay queue. |
12:33 |
jeff |
for this scenario, i can handle that with some preprocessing. |
12:34 |
berick |
you can link a match set to a queue |
12:37 |
jeff |
which is then performed as records are added to the queue, or which is used by default when importing the contents of the queue? |
12:37 |
* jeff |
looks |
12:38 |
berick |
used when importing the contents of the queue |
12:38 |
berick |
oh, ok, i just re-read what you said |
12:39 |
jeff |
heh |
12:39 |
berick |
that's right, there's no dupe/match detection performed within the queue itself. |
12:39 |
jeff |
match set and merge profile... two different things? |
12:40 |
jeff |
(i think?) |
12:40 |
berick |
yes |
12:41 |
berick |
match set determines if an inbound record matches an in-database record |
12:41 |
berick |
merge profile describes how the inbound record will be merged/overlaid/etc to the matched record. |
12:42 |
jeff |
gracias. |
12:54 |
|
Stompro joined #evergreen |
12:58 |
|
sandbergja joined #evergreen |
13:19 |
|
Shae joined #evergreen |
13:22 |
|
ericar joined #evergreen |
13:36 |
|
kmlussier joined #evergreen |
13:43 |
|
mllewellyn joined #evergreen |
13:45 |
|
mtisi joined #evergreen |
13:52 |
|
mtisi left #evergreen |
13:54 |
|
jeffdavis joined #evergreen |
14:06 |
|
collum joined #evergreen |
14:51 |
Dyrcona |
email-- #minus elebenty! |
14:56 |
Dyrcona |
And, amavis doesn't like emails from the report modules that your report is ready, 'cause no Date: header. |
14:57 |
Dyrcona |
And, supposedly, I run amavisd-release to send the quarantined message anyway, but no... |
15:00 |
|
kmlussier joined #evergreen |
15:40 |
|
kmlussier left #evergreen |
15:43 |
|
TRLibrary joined #evergreen |
16:59 |
|
mdriscoll left #evergreen |
17:05 |
|
mmorgan left #evergreen |
17:09 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:25 |
pinesol_green |
[evergreen|Dananji Liyanage] Docs: Changed 'Importing materials' in the staff client section LP#1371615 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4373455> |
17:53 |
|
kmlussier joined #evergreen |
18:15 |
|
nhilton joined #evergreen |
20:23 |
|
hbrennan joined #evergreen |
20:25 |
hbrennan |
Are these hokey job postings a joke on Rogan, or Rogan's joke on us? |
20:48 |
|
nhilton joined #evergreen |
22:40 |
|
aliceR joined #evergreen |
23:40 |
|
kmlussier joined #evergreen |