| Time |
Nick |
Message |
| 00:14 |
|
sandbergja joined #evergreen |
| 01:01 |
|
book` joined #evergreen |
| 02:51 |
|
jamesrf joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
jamesrf joined #evergreen |
| 07:01 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:47 |
|
littlet joined #evergreen |
| 08:35 |
|
bos20k joined #evergreen |
| 08:46 |
csharp |
point of curiosity - came across this Fedora Magazine article on setting up AS2 to transmit EDI orders/invoices |
| 08:46 |
csharp |
https://fedoramagazine.org/manage-business-documents-with-openas2-on-fedora/ |
| 08:47 |
csharp |
don't know if that has any applicability to Evergreen, but it caught my eye |
| 08:54 |
|
Dyrcona joined #evergreen |
| 09:11 |
|
mmorgan joined #evergreen |
| 09:23 |
|
yboston joined #evergreen |
| 09:27 |
JBoyer |
So I have an installation of the latest 3.3 and I'm seeing a problem loading the reporter. Can someone else with a 3.3 install try loading the reporter? |
| 09:28 |
JBoyer |
For some reason the call to open-ils.actor.user.perm.highest_org.batch is being given the home_ou, not the user id. (the two IDLs were out of sync, but now they're the same and still no joy.) |
| 09:31 |
jeff |
depending on which was out of sync, you might need to run autogen to correct the js fieldmapper bits? |
| 09:35 |
JBoyer |
I wondered about that. as soon as it's ready again I'll see if that was it. |
| 09:37 |
Dyrcona |
JBoyer: Is this Pg 10? |
| 09:38 |
JBoyer |
Dyrcona, It was initially, but I've since backed this machine down to 9.6 (on 18.04) |
| 09:39 |
JBoyer |
and it appears that syncing IDLs and re-running autogen did not help... :-/ |
| 09:39 |
JBoyer |
TO the debugger! D: |
| 09:39 |
Dyrcona |
JBoyer: OK. I asked because I seem to recall perm.highest_org needed a patch for Pg 10. |
| 09:40 |
Dyrcona |
If you don't get to it, I'll search Lp after I finish what I'm working on. |
| 09:47 |
|
mdriscoll joined #evergreen |
| 09:48 |
JBoyer |
It's something IDL related, I just can't tell why. With the debugger paused in the reports initialization calling USER.id() is home_ou, active() is user id, home_ou is first_given_name, it's bananas. |
| 09:51 |
mmorgan |
I have a number of rows in action_trigger.event for a certain definition in various states that I don't want to run. Can I just set the state on these to complete? Or is there something else that needs to be done to keep them from processing? |
| 09:53 |
Dyrcona |
mmorgan: You can set them to complete or error. If the state is anything other than "pending," I don't think they'll actually run again unless forced to. |
| 09:53 |
JBoyer |
invalid also works. |
| 09:55 |
|
sandbergja joined #evergreen |
| 09:56 |
Dyrcona |
JBoyer: I think I confused highest_org with something else earlier. |
| 09:56 |
mmorgan |
Ok, thanks. I think I'll go with invalid:) |
| 09:56 |
csharp |
JBoyer: I had a similar issue that we've fixed by removing the reports fm_IDL.xml and symlinking it to the conf fm_IDL.xml |
| 09:56 |
JBoyer |
eg_org_top sounds familiar. |
| 09:57 |
csharp |
obviously not a choice for those in different locales |
| 09:57 |
remingtron |
csharp: symlink, clever! |
| 09:57 |
csharp |
also, a dirty hack that I feel gross even suggesting :-/ |
| 09:58 |
remingtron |
handy idea, at least for a dev machine |
| 09:58 |
csharp |
remingtron: pretty sure someone here suggested it to me sometime back to fix an unrelated issue :-) |
| 10:00 |
JBoyer |
UGH. |
| 10:00 |
JBoyer |
So, after syncing IDLs and re-running autogen.sh, one needs to remember to tell Chrome to clear cache and hard reload. |
| 10:01 |
JBoyer |
The most fun. |
| 10:01 |
Dyrcona |
JBoyer: Yeah, eg_org_top is what I was thinking of. |
| 10:01 |
JBoyer |
It's good now, thanks for the suggestions everyone. |
| 10:05 |
jeff |
next time i'll suggest a fresh cache and not assume. :-) |
| 10:06 |
csharp |
JBoyer: awesome that you got it fixed |
| 10:07 |
JBoyer |
Well, it's "fixed" in that it will now load and show your folders, but now it's unhappy about trying to set onclick handlers when trying to see what's inside a folder. that one is a puzzler. |
| 10:08 |
Dyrcona |
JBoyer: Having fun, yet? :) |
| 10:08 |
JBoyer |
*party horn* |
| 10:13 |
|
collum joined #evergreen |
| 10:59 |
|
khuckins joined #evergreen |
| 11:10 |
|
khaun joined #evergreen |
| 11:27 |
Dyrcona |
Seems like after each Evergreen release messing with MARC records in the database gets slower. |
| 11:28 |
Dyrcona |
It's gotten to the point where it would be more efficient for staff to load records via Vandelay than using my Perl DBI scripts. |
| 11:40 |
csharp |
our match sets create ugly and super slow MARC loading through vandelay too |
| 11:43 |
|
sandbergja joined #evergreen |
| 11:46 |
Dyrcona |
I'm tsvector searches for ISBNs, but not for the other identifiers. |
| 11:47 |
Dyrcona |
I'm using tsvector.... |
| 11:48 |
Dyrcona |
Doesn't seem to help, much. |
| 11:49 |
Dyrcona |
https://pastebin.com/g4RGDJLr |
| 11:53 |
dbs |
csharp: hah, I came here today because I noticed the same Fedora EDI article. I was like "What? Where were you 10+ years ago?" |
| 11:54 |
dbs |
Also, I thought most of our vendors still use FTP or the like, rather than encrypted transfer methods... |
| 11:57 |
|
sandbergja_ joined #evergreen |
| 12:01 |
dbs |
Dyrcona: hrm, how do we spin that as a feature in the release notes? "Indexing now 5% slower!" |
| 12:02 |
Dyrcona |
dbs: Pretty much. Last time I tried timing things, it took 2 seconds to update a MARC record. |
| 12:03 |
dbs |
There was a lot of wisdom to the slim MODS approach for indexing, but I guess the demands for incredibly fine-grained search pushed us in a different direction |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:03 |
dbs |
Also maybe complex Perl inside the database... |
| 12:05 |
Dyrcona |
Yeahp. I think we do too much in the databse....a case of too many features being a bad thing. |
| 12:05 |
csharp |
dbs: yeah - I would expect a lot of cluelessness from acq vendors |
| 12:06 |
csharp |
just don't see EDI mentioned much in the wild and got excited :-) |
| 12:06 |
dbs |
csharp: me too :) |
| 12:06 |
Dyrcona |
"I would expect a lot of cluelessness." :) |
| 12:08 |
Dyrcona |
"FTP was fine in 1999!" (No, it wasn't, but stil....) |
| 12:08 |
dbs |
Folio went with a MARC-centric approach to indexing and display and are now thinking about how to integrate BIBFRAME in parallel; their path will likely lead to a common intermediate format as well |
| 12:08 |
dbs |
Dyrcona++ |
| 12:09 |
* Dyrcona |
begins to suspect that MARC is part of the problem. |
| 12:09 |
csharp |
@quote add * Dyrcona begins to suspect that MARC is part of the problem. |
| 12:09 |
pinesol |
csharp: The operation succeeded. Quote #198 added. |
| 12:09 |
dbs |
(I believe slim MODS was supposed to be an intermediate format for Evergreen too but we've hard-coded MARC into frontend, middle layers, and backend all over now) |
| 12:11 |
* dbs |
was sorry to miss out on EG2019 conf |
| 12:11 |
csharp |
dbs: we missed you too |
| 12:11 |
Dyrcona |
Yeah, we did miss you. |
| 12:14 |
dbs |
aww |
| 12:17 |
dbs |
p.s. gmcharlt: the link for the EG history talk actually leads to your Angular slides - major cognitive dissonance when I opened that up :) (https://evergreen-ils.org/conference/2019-evergreen-international-conference/2019-presentations/) |
| 12:29 |
gmcharlt |
dbs: thanks! (and missed you too!) |
| 12:30 |
Dyrcona |
@dunno |
| 12:30 |
pinesol |
Dyrcona: https://i.imgur.com/m8EySrW.gifv |
| 12:34 |
Dyrcona |
So, I suspect something is broken in SRU in 3.2. |
| 12:35 |
Dyrcona |
I have two more or less identical searches that return very different results depending on if you do it through SRU or the OPAC. |
| 12:35 |
Dyrcona |
https://catalog.cwmars.org/opac/extras/sru/CWMARS/holdings?version=1.2&operation=searchRetrieve&query=eg.author%20%3D%20%22paulo%20coelho%22&startRecord=1&maximumRecords=0 |
| 12:35 |
Dyrcona |
https://catalog.cwmars.org/eg/opac/results?query=author%3Apaulo+coelho&qtype=keyword&fi%3Asearch_format=&locg=1&detail_record_view=0&_adv=1&page=0&sort=poprel |
| 12:36 |
Dyrcona |
The SRU search (top) returns 4 results. The OPAC search currently returns 198. AFAICT, it should be the same search. |
| 12:37 |
Dyrcona |
Oh... It's the quotes! |
| 12:37 |
Dyrcona |
Don't mind me. :) |
| 12:37 |
Dyrcona |
%22 = " |
| 12:37 |
|
remingtron joined #evergreen |
| 12:38 |
Dyrcona |
So, maybe the bug is that z39.50 searches quote the author? |
| 12:39 |
Dyrcona |
hrm... no. Without the quotes, the SRU search ends up with an internal server error. |
| 12:40 |
Dyrcona |
But, this still doesn't explain why the same author search via Z39.50 on our catalog returns different results from the same search on NOBLE's catalog. |
| 12:52 |
Dyrcona |
I seem to recall messing with Supercat and quotes back in the 2.9 days while I was at MVLC, but I don't recall exactly what I did. |
| 12:55 |
JBoyer |
I think you stopped it from trying to do exact matches even if there are quotes, because we have that patch loaded here. I'll look it ip |
| 12:56 |
Dyrcona |
JBoyer++ |
| 12:56 |
Dyrcona |
That sounds about right. |
| 12:58 |
JBoyer |
our old local commits have some less-than-helpful names. like "SIP Upgrades" and "un-break the broken fix from ..." |
| 12:58 |
JBoyer |
Entirely my fault, but still. |
| 13:00 |
Dyrcona |
Well, I can't find it in my working branches, a lot of them are just named for Lp bugs. |
| 13:01 |
JBoyer |
I have the commit hash in our repo, now I'm trying to find out how to get a patch for a single commit in the past. I now have a nice 40+ files to clean up, all of which come after. :p |
| 13:01 |
JBoyer |
(and from the comment it looks like you didn't put it up on LP anywhere) |
| 13:02 |
Dyrcona |
git show HASH > ~/path/file.patch |
| 13:02 |
Dyrcona |
Yeah, it was probably in my MVLC repo, which is now long gone. |
| 13:02 |
JBoyer |
That's definitely better than fighting with format-patch. |
| 13:03 |
Dyrcona |
For something like this, definitely quicker. |
| 13:04 |
Dyrcona |
I stumbled upon this informative branch name from 2012: working/user/dyrcona/zomg_wtf_bbq |
| 13:05 |
pastebot |
"JBoyer" at 168.25.130.30 pasted "Z39.50 search fix from Dyrcona" (23 lines) at http://paste.evergreen-ils.org/10005 |
| 13:06 |
JBoyer |
Looks like I applied it by hand since it shows me as the author. (that simple a change I probably wouldn't bother with a patch file) |
| 13:06 |
Dyrcona |
Yeah. I don't mind. I'm going to test it out on a vm. |
| 13:07 |
Dyrcona |
JBoyer++ muchas thanks! |
| 13:07 |
JBoyer |
Dyrcona++ for putting it out there *mumble* years ago! |
| 13:08 |
JBoyer |
hah, the thing has dates. Somewhere around May 2016. |
| 13:18 |
Dyrcona |
Yay! It works! |
| 13:19 |
Dyrcona |
I think the patch is older than that by a year or so, though. |
| 13:23 |
Dyrcona |
Maybe not... |
| 13:24 |
JBoyer |
It's definitely older than that date because the CommCat was around well longer than SRCS. |
| 13:31 |
|
khuckins joined #evergreen |
| 13:33 |
Dyrcona |
I apparently never made a Lp bug. I just searched for bugs reported by me with all statuses checked. |
| 13:34 |
Dyrcona |
I do recall discussing the change with miker and the conclusion being that's OK for a local change. |
| 13:34 |
jeffdavis |
dbwells: any idea if the fix for bug 1796945 is likely to be backportable to 3.1? |
| 13:34 |
pinesol |
Launchpad bug 1796945 in Evergreen 3.3 "Report templates cloned from those created on XUL client causing error or producing different results" [High,Confirmed] https://launchpad.net/bugs/1796945 |
| 13:34 |
jeffdavis |
it's not targeted for that version |
| 13:36 |
* dbwells |
looks |
| 13:37 |
Dyrcona |
jeffdavis: Have you tried applying it to 3.1? |
| 13:37 |
jeffdavis |
not yet |
| 13:38 |
dbwells |
jeffdavis: Yes, I think it should. I wasn't sure if webstaff report cloning got into 3.1, but it appears that it did. |
| 13:38 |
dbwells |
I will target it. |
| 13:38 |
jeffdavis |
Awesome, thanks. I expect we'll be testing it on 3.1 soon. |
| 13:39 |
dbwells |
jeffdavis: If it doesn't and there is any confusion, I'd be happy to help sort it out, if needed. |
| 13:39 |
jeffdavis |
dbwells++ |
| 13:52 |
Dyrcona |
JBoyer: I found the original in some old files I kept from MVLC. Looks like it was from January 2016. |
| 14:20 |
|
khuckins joined #evergreen |
| 14:25 |
Dyrcona |
BTW, if anyone is interested in a branch with the patch that JBoyer and I have been discussing, it is on the working repository at collab/dyrcona/supercat-unquote-z3950 |
| 14:29 |
JBoyer |
If you do external resource sharing via a third party search aggregator you're probably interested. |
| 14:35 |
JBoyer |
Part of me wishes scp would complain if neither src nor dest are actually remote... |
| 14:35 |
* JBoyer |
has been removing files named after hosts for a couple mins |
| 14:36 |
Dyrcona |
Happens to me, to. |
| 14:36 |
Dyrcona |
too, even. :) |
| 14:36 |
Dyrcona |
scp file user typo:./ |
| 14:38 |
JBoyer |
Good way to leave a lot of "backups" lying around. ;) |
| 14:40 |
Dyrcona |
:) |
| 14:52 |
csharp |
JBoyer: I have the same complaint about scp |
| 14:57 |
|
mmorgan1 joined #evergreen |
| 15:05 |
|
yboston joined #evergreen |
| 15:43 |
|
khuckins joined #evergreen |
| 15:49 |
* jeff |
looks at the 242 unique values in actor.usr_address.address_type and once again considers removing / papering over that field and migrating some contents to an optional "address note" field. |
| 15:59 |
jeff |
Does anyone here currently use the address_type field in a way that they're attached to and would not be served by an optional address note/comment field? |
| 16:02 |
jeffdavis |
wow, only 242 unique values? |
| 16:02 |
jeff |
jeffdavis: we've done some cleanup. ;-) |
| 16:03 |
|
sandbergja_ joined #evergreen |
| 16:05 |
Dyrcona |
Whee! 571! |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
Bmagic |
I'm trying to figure out why some of my circ notices are showing a blank title and author for "circ.target_copy.call_number.record.simple_record.title" and "copy_details.author" - looks like it makes use of "reporter.simple_record" |
| 17:05 |
Bmagic |
querying that view for my record ID - I get two rows of results. Having two results is the issue? |
| 17:06 |
Bmagic |
perhaps circ.target_copy.call_number.record.simple_record.0.title instead? (Adding the "0" to indicate the first result?) |
| 17:10 |
jeffdavis |
we've run into that intermittently, don't think I ever got to the bottom of it |
| 17:10 |
Bmagic |
sheesh |
| 17:11 |
miker |
berick: around for some brain picking, re websocketd? |
| 17:11 |
Bmagic |
jeffdavis: I've got examples that use different code to get the title: FOR part IN bibxml.findnodes('//*[@tag="245"]/*[@code="a"]'); title = title _ part.textContent; END; |
| 17:12 |
Bmagic |
And in that example, the title is blank. Funny enough, this template outputs html and plain text in the template. For some reason, the template uses both the FOR loop and simple_record.title - the simple_record.title method outputted the title where the FOR loop didn't. LOL |
| 17:19 |
Bmagic |
I hope to see everyone at Geekway 2 the west Tomorrow-Sunday https://geekwaytothewest.com/ |
| 17:20 |
jeffdavis |
Should config.metabib_field.display_field default to TRUE or FALSE? The table definition is inconsistent with the upgrade scripts. |
| 17:22 |
Bmagic |
jeffdavis: default false for me on 3.1.6 as well as 3.1.10 and 3.3.0 |
| 17:23 |
jeffdavis |
It will be false on a system that was upgraded from <3.0, but true on an install that started with 3.0+ |
| 17:23 |
jeffdavis |
bug 1829294 |
| 17:23 |
pinesol |
Launchpad bug 1829294 in Evergreen "Conflicting defaults for config.metabib_field.display_field" [Undecided,New] https://launchpad.net/bugs/1829294 |
| 17:24 |
Bmagic |
jeffdavis++ |
| 17:29 |
|
mdriscoll left #evergreen |
| 17:30 |
|
mmorgan1 left #evergreen |
| 17:49 |
|
jamesrf joined #evergreen |
| 18:10 |
berick |
miker: sorry I missed you, I will be tomorrow |
| 18:19 |
csharp |
jlamos++ # community VM wrangling |
| 18:50 |
|
khuckins joined #evergreen |
| 18:51 |
|
sandbergja_ joined #evergreen |
| 18:57 |
|
sandbergja_ joined #evergreen |
| 20:43 |
|
sandbergja_ joined #evergreen |
| 21:05 |
|
sandbergja_ joined #evergreen |
| 22:57 |
|
sandbergja joined #evergreen |
