Evergreen ILS Website

IRC log for #evergreen, 2021-06-15

| 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
01:21 Keith_isl joined #evergreen
06:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:08 rlefaive joined #evergreen
07:18 mantis joined #evergreen
07:21 Dyrcona joined #evergreen
07:24 rjackson_isl_hom joined #evergreen
08:18 dickreckard joined #evergreen
08:27 collum joined #evergreen
08:45 mmorgan joined #evergreen
08:50 Dyrcona We have an extra layer in our hierarchy between the consortium and the system level because the consortium was originally split into two regions and that was carried over from the legacy ILS.
08:52 Dyrcona We've contemplated dropping that level for some time. It looks like it can mostly be done in the database by dropping the two org. units, their org. unit types, updating the depths in the other org. unit types, and then updating the parent_ou on the system org. units.
08:53 Dyrcona After that, run autogen.sh everywhere.
08:53 Dyrcona Has anyone attempted something like this before and, if so, did you encounter any issues?
08:55 rhamby I've not though I've recoemmended to folks in a similar situation.  I don't see any obvious red flags to doing it.
09:02 Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged.
09:03 jeff Dyrcona: we've not attempted something like that. one thing that comes to mind is that certain settings that involve depth may need to be adjusted, as the entire tree will be more shallow than before.
09:05 rfrasur joined #evergreen
09:05 Dyrcona jeff: Good point! I think that may have been why I haven't done it, yet. I noticed some depth settings somewhere and realized I may have to adjust them up or down.
09:05 * Dyrcona makes notes on the CW MARS ticket.
09:06 jeff first thing that came to mind was circ.hold_boundary.hard, but I'd look at any org unit settings with depth or boundary in their name/description.
09:09 Dyrcona Yeahp. I don't think we're using hard boundaries, but there are other places where depth comes into play.
09:20 Keith_isl joined #evergreen
09:26 mmorgan Dyrcona: If you have any hold policies with a transit range, those may need to be adjusted.
09:30 jvwoolf joined #evergreen
09:46 Dyrcona mmorgan: Thanks. I figured I'd have to check the circ and hold matrix tables.
09:49 Dyrcona This seems strange to me. I added 3 new members to the org tree this morning and ran autogen.sh. After that search was sometimes failing with 'can't call method opac_visible on undefined value.' After restarting services, those problems went away. I suspect it was related to autogen.sh and the JS fieldmapper being out of sync, but I don't have any proof.
09:49 Dyrcona i did restart apache2.
09:51 Keith-isl joined #evergreen
10:00 * Dyrcona makes notes to restart services after adding new org. units.
10:19 alynn26 joined #evergreen
10:43 csharp_ Dyrcona: also perms set at specific depths
11:14 jeff and data columns like action.hold_request.selection_depth
11:16 mmorgan joined #evergreen
11:20 Dyrcona yeahp. It's all of the fields that require adjustment that have held this little project off.
11:51 jihpringle joined #evergreen
12:03 csharp_ I would appreciate experienced eyes on my branch for bug 1932051
12:03 pinesol Launchpad bug 1932051 in Evergreen "AngularJS Add to Item Bucket Generating too many simultaneous requests" [High,New] https://launchpad.net/bugs/1932051 - Assigned to Chris Sharp (chrissharp123)
12:19 jeffdavis http://paste.evergreen-ils.org/10163
12:20 jeffdavis Dyrcona: ^ those are the things we adjusted when adding a new level to our org tree recently, you'd probably need to make comparable adjustments if you're dropping a level. Some of the org settings may be Sitka-specific.
12:32 collum joined #evergreen
12:37 jeffdavis I'm seeing the issue that was supposed to be fixed by bug 1902965 on a server with current master, trying to determine if there's something weird about my install.
12:37 pinesol Launchpad bug 1902965 in Evergreen 3.6 "MARC Editor XSS vulnerability" [Critical,Fix released] https://launchpad.net/bugs/1902965
12:49 Dyrcona jeffdavis: I didn't see it with a title yesterday on current master. Any particular field?
12:50 jeffdavis Just adding "><script>alert('uh oh')</script> to 245$a. This was Bootstrap OPAC specifically, TPAC was fine. I'm encouraged that you didn't run into it. :)
13:01 Dyrcona Hmm. I didn't have the first > in my example. I'll try that again and get back to you.
13:02 jeffdavis you need opening-quote plus angle bracket for this attack:  "<
13:03 jeffdavis rather ">
13:03 jeffdavis I should read what I type before I hit Enter
13:24 jvwoolf joined #evergreen
13:52 jvwoolf1 joined #evergreen
14:08 Dyrcona Bmagic: RE the trouble you reported with parsing MARC records last week, I heard today that OCLC has an issue that they're generating corrupted MARC records sometimes with cat express. I'm also told that they're working on it.
14:11 Bmagic Dyrcona: interesting!
14:16 dickreckard joined #evergreen
14:17 rhamby yeah, someone mentioned it on the evergreen catalogers list last week, what they reposted from oclc wasn't much just "catexpress and connexion are having issues and we're working on it" if I remember the essence correctly
14:18 terranm joined #evergreen
14:19 jeff the example I saw was a bad dictionary, failing to account for multibyte UTF-8 characters -- the LDR indicated it was MARC8, but it was not.
14:19 jeff possibly a bad assumption somewhere.
14:19 jeff rather, the LDR indicated it was MARC8, but the bytes on disk in the Export.dat file were UTF-8.
14:20 jeff replacing the two bytes for the one or two UTF-8 encoded characters with a single byte character made things align again.
14:21 Bmagic That reminds me: I had to disable the symspell stuff on the one production machine running 3.7.0. The CPU on the DB went from 22 -> 0.1 after updating the YAOUS. Queries were lasting a long time ( > 5 minutes each) when attempting to lookup symspell suggestions. That was after already disabling the triggers on metabib to prevent the new tables from getting any new things.
14:21 jeff the symptoms included: for a single record file, yaz-marcdump failed to parse because it couldn't find the expected characters at the end of the file (they had been "pushed out" by the failure to count the multibyte characters as multibyte.
14:22 Bmagic jeff: makes sense
14:23 jeff and the records looked okay until you got to the first multibyte character, which was not displayed correctly (because the LDR indicated MARC8 but the bytes were UTF-8), and then everything after that appeared shifted/truncated by one character. Then, after you hit the second (of a total of two) multibyte character, things were shifted/truncated by two.
14:31 miker Bmagic: did you see my DYM optimization bug fix? probably relevant to your interests
14:33 Bmagic miker: no! I'll go check
14:36 Bmagic interesting, just update the function. I'll try that
15:08 jihpringle joined #evergreen
15:41 eady joined #evergreen
15:49 dickreckard joined #evergreen
16:03 jwoodard joined #evergreen
16:12 mantis left #evergreen
16:19 Keith_isl joined #evergreen
17:18 mmorgan left #evergreen
17:21 jvwoolf1 left #evergreen
17:23 sandbergja joined #evergreen
17:46 dickreckard joined #evergreen
17:48 pinesol [evergreen|Galen Charlton] LP#1930933: fix issue with over-escaping in search results title attributes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=fdd6ece>
17:52 jeffdavis pinesol++
17:53 jihpringle joined #evergreen
18:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:15 jihpringle joined #evergreen

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