| 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 |
