Evergreen ILS Website

IRC log for #evergreen, 2023-01-13

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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=E​vergreen.git;a=commitdiff;h=bebcbf​27ba03d2a1a5a8fd1dbebf6fe95e5a6550>
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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat