Evergreen ILS Website

IRC log for #evergreen, 2020-04-08

| 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
00:22 dbwells joined #evergreen
02:45 JBoyer joined #evergreen
04:39 bshum joined #evergreen
05:04 alynn26 joined #evergreen
05:08 alynn26_away joined #evergreen
06:37 JBoyer joined #evergreen
06:58 rfrasur joined #evergreen
07:30 rjackson_isl_hom joined #evergreen
08:29 Stompro joined #evergreen
08:29 stompro_ joined #evergreen
08:30 mantis1 joined #evergreen
08:35 mmorgan joined #evergreen
08:36 Dyrcona joined #evergreen
08:56 Dyrcona It looks like the new EDI order pusher leaves the messages with a different status than the previous one did after various failures. I'll have to update my fixes.
09:03 sandbergja joined #evergreen
10:01 jvwoolf joined #evergreen
10:04 jvwoolf1 joined #evergreen
10:07 Stompro joined #evergreen
10:08 sandbergja joined #evergreen
10:08 Dyrcona joined #evergreen
10:09 Stompro Good morning!  Another holds question.  If I set our hard boundary to 2, that should limit targeting of new holds to the pickup location only?  And then update action.hold_request(selection_depth) to match for all existing holds?  Then retarget everything?
10:19 phasefx Stompro: if you have just one hard boundary for the whole org hierarchy, I think so.  You may end up with some unfillable holds
10:26 Dyrcona I think it depends on your hierarchy, too, doesn't it?
10:26 Dyrcona If you have an extra layer like we do...
10:29 mmorgan So the hard boundary of 2 would correspond to proximity between pickup library and copy circ library?
10:30 mantis3 joined #evergreen
10:30 phasefx I think it's an actual depth and not a node traversal count
10:31 phasefx maps to selection_depth
10:36 Dyrcona Oh... Does the new edi_order_pusher set events to invalid when there's a failure....
10:37 Dyrcona *grumble*
10:42 Dyrcona *grumble*
10:45 Stompro phasefx, I think we are ok with holds sitting around until delivery starts again, we just want to avoid stuff showing up on the pull list to go in transit.
10:46 mmorgan Somewhat related question: Do Closed Dates do anything beyond adjusting due dates and hold shelf expiration dates, preventing fines from accruing (optionally) and preventing hold targeting (optionally)?
10:48 mmorgan We are thinking of marking libraries closed, even when they are open in order to use the setting to only target for pull list items for pickup at the item's circ library.
10:48 mmorgan To accomplish what Stompro is looking to do.
10:54 Dyrcona There's no harm in ignoring things on the pull list.
10:55 phasefx shame suppress holds and transits are bundled as a checkin modifier
10:56 Dyrcona And, for the logs: The new edi_order_pusher.pl does not use action_trigger.event. The invalid event is an artifact of running both the old and the new pusher.
10:56 mmorgan Dyrcona: No harm in ingnoring them, true, but better if staff don't have to weed through to find the local ones.
10:57 phasefx mmorgan: Stompro: could maybe use the Suppress Hold Transits Group library setting
10:57 phasefx well...
10:57 phasefx I think the holds would still capture maybe
10:58 * mmorgan was not aware of that option, will take a look.
11:10 sandbergja joined #evergreen
11:19 mmorgan phasefx: Re: Suppress Hold Transits Group, the hold does capture. It switches the pickup lib to the checkin lib, NOT what we want :-(
11:19 phasefx :-(
11:19 phasefx mmorgan++
12:04 jihpringle joined #evergreen
12:08 rfrasur joined #evergreen
12:12 berick anyone know of any EG sites that use bibliocommons (besides KCLS)?  encountered an issue updating to 3.4 and wanted to give them a heads up.
12:13 berick and confirm
12:14 jeff berick: GRPL
12:16 Dyrcona joined #evergreen
12:16 Dyrcona *grumble*
12:25 jihpringle berick: we have libraries using bibliocommons and we're planning to upgrade from 3.3 to 3.5
12:27 berick arg, got distracted
12:27 berick thanks jihpringle, jihpringle
12:28 berick ... jeff
12:28 berick an IDL change added to 3.4 broke BC's data extraction
12:28 * berick finds commit
12:30 berick https://git.evergreen-ils.org/?p=E​vergreen.git;a=commitdiff;h=c7727d​4966d63a14419c2a8e9df5cabf11f76ee3
12:30 pinesol berick: [evergreen|Jeff Davis] LP#1715767: Allow others to use my account (privacy waiver) - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c7727d4>
12:30 scpl_shardina joined #evergreen
12:31 berick the way the waiver_entries field was added to the actor.usr class in the IDL (in the middle of the fields), it messed up BC
12:31 berick it's not an EG problem
12:31 berick an integration problem
12:31 berick locally I bumped the waiver_entries field down to the bottom of the fields list
12:32 berick I'll open an LP to suggest the same
12:33 berick so we don't have EG sites shuffling to fix it in different ways
12:34 scpl_shardina Is there an error log that can help figure out a MARC Batch Import issue? The upload works, but the Enqueue Progress bar doesn't start, and I don't know what in particular is causing the issue - something in the server setup, issues with my import file, user error, etc.
12:35 mrisher joined #evergreen
12:36 Stompro joined #evergreen
12:38 JBoyer_ joined #evergreen
12:39 dbs scpl_shardina: Did you set the queue to import non-matching records, or some other option for actually importing the queue?
12:39 dbs (I know it sounds like a basic question, but i often trip myself up over that when I haven't done a batch import for a long time)
12:40 scpl_shardina Oh even if it's basic it can trip me up with marc records! Yep, non-matching is selected. And I have a Merge Profile that has the tags in the incoming records in the Replace Specification.
12:43 scpl_shardina I'm using records exported from Horizon with this application: https://github.com/jrochkind/traject_horizon and I'm wondering if it's an encoding issue or something along those lines.
13:07 scpl_shardina The xml files I'm getting from that exporter do look correct, though. Hmm...
13:08 jihpringle scpl_shardina: are you trying to load items at the same time?
13:08 scpl_shardina Just bibs
13:11 jihpringle I'd recommend splitting your file in half and trying to load each half.  If there's a particular record causing issues than only one of the new files will load
13:11 scpl_shardina Good call! I'll give that a shot.
13:27 jvwoolf joined #evergreen
13:33 scpl_shardina No luck. I think my files are good format-wise, I converted the marc files from that exporter using the python script in Ch. 25 and they look just fine. The data and use case is a little odd, they're all newspaper articles from our community resources db (I'm investigating Evergreen as a replacement for this since it can't transfer to our new ILS). I do see some obsolete marc fields in there, would that matter or would Evergreen import those
13:33 scpl_shardina even though they're outdated?
13:47 sandbergja joined #evergreen
14:13 jeffdavis I think obsolete fields are unlikely to be a problem, but malformed MARC could be.
14:20 jeff is the file upload path somewhere that Apache can't reach, like /tmp?
14:20 jeff if Apache is using systemd PrivateTmp, which is likely is by default.
14:20 jeff you can change the path in your opensrf.xml file and restart services.
14:21 jeff if that isn't helpful, it would be interesting to see the input marc file if you can share it.
14:21 jeff i worry when i see someone say "using the python script" in the docs, since I've had issues with at least one variation of that.
14:22 jeff (long ago, not sure if fixed, don't remember details but could look given more time later)
14:30 scpl_shardina Is that the path under the acq_order_reader tag in opensrf.xml?
14:32 jeff scpl_shardina: it's under ...open-ils.vandelay/app_s​ettings/databases/importer
14:33 jeff (probably the only <importer> element in the file)
14:33 jeff there's a multi-line comment containing the text: temporary location for MARC import files
14:33 jeff (in a stock/example config file)
14:33 scpl_shardina Found it! Yep, that's set to /tmp
14:34 Dyrcona joined #evergreen
14:40 Christineb joined #evergreen
14:51 sandbergja joined #evergreen
14:52 scpl_shardina Hmm, well at least I changed the way it's breaking now :) Since opensrf is the apache user set in envvars, I changed the upload directory to a dir in /home/opensrf, figuring apache could access that. Now I get error 403 when I try to upload.
14:54 scpl_shardina It wouldn't even error out before, just silently failed, so that's at least a lead!
14:56 rhamby “I have not failed. I’ve just found 10,000 ways that won’t work.” - Thomas Edison
14:56 rhamby "Then he found one that did but never paid me for it." - (parahprased) Nikola Tesla
14:57 Dyrcona :)
14:59 scpl_shardina Changed it to a temp dir in /openils and the Enqueue Progress bar completes now!
14:59 scpl_shardina Import Progress does not, however.
15:00 Dyrcona scpl_shardina: I have it set to /openils/var/tmp which doesn't exist by default, but is easily created.
15:01 Dyrcona I don't use the import method much, but you could search the logs for open-ils.vandelay
15:02 Dyrcona That's the import service name. If the back end is throwing errors, you should find something that way.
15:08 scpl_shardina Getting somewhere: var/log/osrfsys.log:[2020-04-08 14:05:45] open-ils.vandelay [WARN:6140:Application.pm:624:1586372733615616] open-ils.vandelay.bib.process_spool: Use of uninitialized value within %record_types in string eq at /usr/local/share/perl/5.28.1/O​penILS/Application/Vandelay.pm line 316.
15:08 scpl_shardina var/log/osrfsys.log:[2020-04-08 14:05:45] open-ils.vandelay [ERR :6140:Vandelay.pm:322:1586372733615616] In process_spool(), type was bib and leader type was q ; not currently supported
15:14 jeff can you share the input file? I asked above, but not sure if you saw.
15:14 jeff I can't guarantee time to look at it myself before this evening, but that's probably the next step.
15:16 Dyrcona Well, I just checked the LoC site and a q in leader 06 is not valid.
15:19 * jeff nods
15:20 scpl_shardina Yeah, this is weird old data we inherited from previous employees! I should be able to share the files, I'm going to test a few more things first. I'm still not totally sure if this is even a good use case for Evergreen, the way Horizon did community resources seems kind of iffy to begin with, but I'm curious to see what it will look like if I can get it loaded in.
15:20 Dyrcona Oh! These are Horizon community resources records.... Don't bother.
15:21 jeff oh, this is MARC Community Information, not bibliographic data. Yeah, hence the q.
15:21 jeff http://www.loc.gov/marc/community/eccihome.html
15:21 Dyrcona When my previous employer migrated from Horizon to Evergreen in 2012 we decided to stop supporting it. The consensus among librarians was that there were better sources for this type of data.
15:22 Dyrcona Evergreen also doesn't support the format.
15:22 scpl_shardina Ok! I'm kind of learning on the job as far as MARC goes to begin with, this is all great to know
15:22 jeff So, after evaluating those records, if you decide to keep them you may end up needing to convert them a bit, at a minimum the leader, but likely more. It'll depend on what's in them and what you want to keep and how you want to share it.
15:23 scpl_shardina I actually was just able to get a few to process! I removed the q and z from the leader.
15:24 scpl_shardina But yeah, at this point it may be simpler to translate this all into something I can just throw in a MySQL database and work on a web front end from there, there aren't that many fields being used.
15:25 jeff Many options.
15:25 scpl_shardina Still for sure going to keep diving into Evergreen though, just for the learning experience, I really like the system so far. I'll just transfer over our main ILS database and not the comres stuff.
15:32 Dyrcona scpl_shardina: Good luck! I've done a Horizon to Evergreen migration, so if you have questions, I might be able to help.
15:33 scpl_shardina Thanks for all the help! I'm sure I'll be back with more questions at some point, but for data that the system was actually built for :)
16:19 Bmagic I'm messing with config.record_attr_definition. I added two new rows. It doesn't seem that the old XUL interface for coded_value_map will provide me those new options until some cache has been expired? There are references to cache in DB functions. Is that memcached or something else?
16:19 mantis3 left #evergreen
16:48 pastebot joined #evergreen
16:54 jeffdavis Bmagic: I don't think Postgres is memcached-aware. Looks like metabib.compile_composite_attr and related functions are using this: https://www.postgresql.org/​docs/9.6/plperl-global.html
16:55 jeffdavis (...not memcached-aware by default, there are ways to make use of it)
17:07 mmorgan left #evergreen
18:27 jihpringle joined #evergreen
20:30 JBoyer joined #evergreen
21:09 sandbergja joined #evergreen
22:20 JBoyer joined #evergreen
23:16 mrisher joined #evergreen
23:46 jvwoolf joined #evergreen

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