| 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=Evergreen.git;a=commitdiff;h=c7727d4966d63a14419c2a8e9df5cabf11f76ee3 |
| 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_settings/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/OpenILS/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 |
