Time |
Nick |
Message |
07:06 |
|
kworstell-isl joined #evergreen |
07:43 |
|
kworstell-isl joined #evergreen |
07:44 |
|
BDorsey joined #evergreen |
08:40 |
|
mantis1 joined #evergreen |
08:48 |
|
collum joined #evergreen |
09:04 |
|
dguarrac joined #evergreen |
09:23 |
|
Dyrcona joined #evergreen |
10:13 |
Dyrcona |
Grr. Deleted a file too soon. My brain: "We won't need that...." My brain 15 minutes later: "Well, that was stupid. I want that, now." |
10:20 |
Dyrcona |
Guess I'll do it again in a different database. |
10:24 |
Dyrcona |
Still, 21 out of 29,511 is less than 0.1% failure rate. A person ought to be happy with that, but less than perfection is unacceptable. :) |
10:26 |
Dyrcona |
Since 4 look like dupes, that drops the failure rate to 17 out of 29,511. |
10:30 |
Dyrcona |
Yeah, four are definitely dupes. |
10:34 |
|
stephengwills joined #evergreen |
10:40 |
Dyrcona |
I should have used the --strict option. That would put the bad records in a rejects file. Ah well, guess I'll do that next time. |
10:41 |
Dyrcona |
I suspect encoding issues. It's almost always encoding issues. |
11:30 |
|
jihpringle joined #evergreen |
12:21 |
|
collum joined #evergreen |
12:43 |
Dyrcona |
Um. I have the impression that bugs are missing from Lp, but I shall investigate further. |
12:44 |
|
collum joined #evergreen |
12:45 |
Dyrcona |
Right... I guess I had previously done an advanced search and those parameters were still applied. |
12:47 |
|
jihpringle joined #evergreen |
12:49 |
|
jvwoolf joined #evergreen |
13:08 |
|
mantis1 joined #evergreen |
13:27 |
|
rfrasur joined #evergreen |
13:42 |
JBoyer |
Dyrcona++ # an off-hand comment lead to a test case fix so 3.8.2 can proceed as planned! |
13:43 |
Dyrcona |
JBoyer++ # For realizing the issue was in the concerto data load for Pg 10+ |
14:11 |
miker |
Bmagic: from yesterday, re asset.copy vs serial.unit, if you're gathering data for future loading as part of an expanded data set, you def want to use "SELECT ... FROM ONLY asset.copy ..." because of the inheritance. but, in normal operation, yes, you'll definitely see serial.unit rows "through" the asset.copy table -- that's 100% intended. |
14:14 |
Bmagic |
yep, I did come to the same conclusion, and edited my code with "ONLY" - that seems to have fixed the bug |
14:34 |
|
mantis1 joined #evergreen |
14:51 |
|
mantis1 joined #evergreen |
14:54 |
mantis1 |
Curious if there's a way to show local call numbers when printing a list or basket of items. I know that action is tied to a brief MARC record template by default. Wasn't sure if we have a way to do this with action triggers or something that doesn't involve development. |
15:03 |
Dyrcona |
biblio.record_entry.print and biblio.record_entry.email should both do this. Not sure if those are used by buckets, but looks like they both use a temporary bucket. |
15:04 |
Dyrcona |
mantis1: ^^ Assuming you mean asset.call_number when you say 'local call number.' |
15:07 |
jihpringle |
mantis1: on our OPACs if you set Format to Full in the Print Preview and Format Editor than the local call numbers print, but our OPACs are skinned per library |
15:07 |
jihpringle |
http://docs.libraries.coop/sitka/_batch_actions_through_the_basket.html#_print_from_the_baskets |
15:11 |
pinesol |
News from commits: Forward Port 3.8.2 Upgrade Script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=bebcbf27ba03d2a1a5a8fd1dbebf6fe95e5a6550> |
15:22 |
mantis1 |
jihpringle++ Dyrcona++ |
15:25 |
mantis1 |
of course it was a simple solution lol |
15:25 |
mantis1 |
Thank you! |
16:44 |
|
stephengwills left #evergreen |
19:48 |
|
jihpringle joined #evergreen |