| Time |
Nick |
Message |
| 03:40 |
|
tsbere_ joined #evergreen |
| 07:11 |
|
Callender joined #evergreen |
| 07:12 |
|
ericar joined #evergreen |
| 07:57 |
|
rjackson_isl joined #evergreen |
| 08:03 |
|
mrpeters joined #evergreen |
| 08:03 |
|
Stompro joined #evergreen |
| 08:05 |
|
jboyer-isl joined #evergreen |
| 08:16 |
|
sarabee joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:41 |
|
Dyrcona joined #evergreen |
| 08:57 |
|
maryj joined #evergreen |
| 09:08 |
|
mrpeters joined #evergreen |
| 09:27 |
jeff |
"ferb, I know what we're gonna' do today." |
| 09:34 |
Dyrcona |
heh. |
| 09:34 |
Dyrcona |
"Whatcha doin'?" |
| 09:35 |
jeff |
noticed a quirk in my incremental indexing: it always re-indexed the most recently updated record, even if it had not changed since the last run. |
| 09:36 |
jeff |
in looking at that, noticed a new quirk: there was one run after close last night that indexed three items, then on the next run it found zero items to index. |
| 09:37 |
jeff |
and on that zero item index run, it stored an empty state, which means that every index run after that found zero items. |
| 09:37 |
jeff |
(i think because it was looking for a last edit date > null. |
| 09:38 |
jeff |
and as far as postgres is concerned, null is neither >, <, or = to now() |
| 09:39 |
jeff |
oh neat. |
| 09:39 |
jeff |
2015-11-11 22:36:15,690 INFO: bib 48078963 last_edit_date 2015-11-11 22:36:01.697919-05:00 |
| 09:40 |
jeff |
oh, nevermind. |
| 09:40 |
jeff |
i noticed that the bib in question had an earlier edit_date -- but in the case of that log output, it's the most recent of bre, acn, acp edit_date. |
| 09:50 |
|
mrpeters joined #evergreen |
| 09:52 |
tsbere_ |
jeff: I created a table for MVLC that stores the last date I have run certain things to avoid "I had nothing on the previous run" headaches. |
| 09:52 |
tsbere_ |
hmm |
| 09:52 |
jeff |
yeah. i see why i was indexing at least one bib every time -- i even had a todo for that. |
| 09:53 |
jeff |
and i see how indexing zero records was clearing the state from the state tracking file and how an empty state there causes all incrementals after that to fail to find anything. |
| 09:53 |
jeff |
what i can't see is how i ended up with a run of zero records, given the issue that caused there to be at least one record indexed every time. :-) |
| 09:54 |
|
mrpeters joined #evergreen |
| 09:55 |
jeff |
it's possible that it will come down to something like a failure to account for a failed db query. |
| 10:00 |
|
mrpeters joined #evergreen |
| 10:01 |
|
mrpeters joined #evergreen |
| 10:03 |
jeff |
aha. |
| 10:04 |
jeff |
because the copy edit date moved back in time. |
| 10:05 |
tsbere |
jeff: Are you including deleted copies in your edit dates? |
| 10:05 |
jeff |
copy was created with a default NOW() edit_date of '2015-11-11 22:36:01.697919-05:00', then audit_time '2015-11-11 22:36:02.701287-05' the edit_date was set to '2015-11-11 22:36:01-05' |
| 10:05 |
tsbere |
heh, loss of the microseconds could do that too, I guess. date_trunc that field to second? |
| 10:06 |
jeff |
i believe i shall, for purposes of this query. |
| 10:08 |
jeff |
and i am including deleted copies in this query, because i want to re-index the bib and its holdings when a copy is deleted, etc. |
| 10:08 |
jeff |
the fun part is that i am not at present doing anything tricky to catch copy/volume transfers or bib merges. i need to determine if those are something i'll have to go out of my way to notice, or if i got lucky. |
| 10:10 |
jeff |
almost any way i slice it, i think i'll want regular full indexes. the frequency of those could probably be made lower if i were to rely on some triggers instead of just relying on edit_date. |
| 10:10 |
|
yboston joined #evergreen |
| 10:14 |
jeff |
Dyrcona may appreciate that in this case, I can at least partially blame NCIP. |
| 10:14 |
Dyrcona |
@blame NCIP |
| 10:14 |
pinesol_green |
Dyrcona: NCIP stole Dyrcona's ice cream! |
| 10:14 |
jeff |
IceCreamRequestCancelled |
| 10:15 |
Dyrcona |
Ha! |
| 10:15 |
Dyrcona |
<IceCreamRequestCancelledResponse><Problem/></IceCreamRequestCancelledResponse> |
| 10:25 |
|
jwoodard joined #evergreen |
| 10:35 |
dbs |
triggers++ |
| 10:39 |
jboyer-isl |
@marc 505 |
| 10:39 |
pinesol_green |
jboyer-isl: The titles of separate works or parts of an item or the table of contents. The field may also contain statements of responsibility and volume numbers or other sequential designations. (Repeatable) [a,g,r,t,u,6,8] |
| 10:39 |
Dyrcona |
jboyer-isl: We added that to our title keyword index. |
| 10:40 |
jboyer-isl |
Dyrcona: I did too (also author, maybe? not sure), but only when ind2=0. |
| 10:40 |
jboyer-isl |
I was hoping that pinseol would also explain the indicators, but it was not to be. |
| 10:40 |
Dyrcona |
LC has a good reference on that, so does OCLC. |
| 10:41 |
jboyer-isl |
(trying to determine why a record is freaking out.) |
| 10:41 |
jboyer-isl |
I've got them both bookmarked, but I was trying to lazysearch it |
| 10:41 |
Dyrcona |
I'm not sure what you mean by "freaking out." |
| 10:41 |
Dyrcona |
Yep. I figured. ;) |
| 10:43 |
jboyer-isl |
Not a good explanation, but basically if this record is returned as a result, the OPAC displays nothing at all but a position number and an Add to my lists link, and in the DB the BRE entry has linebreaks, which usually implies a parser failure of some kind. ("good" records are usually collapsed into a single line if memory serves) |
| 10:44 |
Dyrcona |
Yes, they are. |
| 10:44 |
Dyrcona |
You can look at OpenILS::Utils::Normalize::clean_marc for the gory details. |
| 10:46 |
Dyrcona |
Basically, line ends, extra whitespace, and control characters are scrubbed. |
| 10:46 |
Dyrcona |
"Fancy" characters are converted to entities, and the <?xml?> directive is removed. |
| 10:47 |
jboyer-isl |
Well that's maddening. All I did was load it in the client, switch to the MARC Edit View, click Save to see if there would be any complaining, and now it's fine. No complaints, no explanation, nothing. |
| 10:48 |
jeff |
in that case, you might find the before/after contents of the bre.marc column instructive. |
| 10:48 |
jeff |
the auditor is your friend there. |
| 10:48 |
Dyrcona |
jboyer-isl: Do you know how that record got into your system? |
| 10:48 |
Dyrcona |
jeff++ |
| 10:49 |
jeff |
but keep in mind that just copying and pasting the output from psql might not help you -- even with things like \t \a and \o |
| 10:50 |
jboyer-isl |
jeff: I looked at it in-db before loading it in the client. None of the obvious problems like tag="" or the like. Lots of ind2="" (rather than " ") but I don't know if that's enough. |
| 10:50 |
jeff |
at times, i've just queried from a perl script with DBI or a python script with psycopg2 when i have concerns about encoding/etc getting lost in copy/paste or psql quoting. |
| 10:50 |
jeff |
when diffing, passing both through xmllint --format and then diffing the formatted output can save you some sanity. |
| 10:51 |
jboyer-isl |
Dyrcona: It was created from one of our templates in 2009, so I guess 6 years ago things were less strict on save. |
| 10:51 |
jeff |
of course, invalid XML generally won't pass through xmllint --format, and i've seen some xml that refuses to be formatted. then you're on your own. ;-) |
| 10:52 |
jeff |
jboyer-isl: and six years ago, catalog display was mostly MODS-driven via a virtual mvr object, and less MARCXML parsed by misc_util.tt2. |
| 10:52 |
Dyrcona |
jboyer-isl: Could be some old bug if the record never got updated. |
| 10:53 |
jboyer-isl |
It might be useful to just dump every id for a BRE with a newline in the marc field. Someday. |
| 10:54 |
Dyrcona |
What I meant was: If the record had not been edited in 6 years, then this could be the results of an old bug. |
| 10:55 |
|
bmills joined #evergreen |
| 10:55 |
jboyer-isl |
I see what you mean. |
| 10:55 |
Dyrcona |
I realized what I said might not have been clear to everyone. |
| 10:55 |
Dyrcona |
Anyhoo. |
| 10:56 |
Dyrcona |
I don't think I've seen any records like that for a long time. |
| 10:59 |
jboyer-isl |
What appears to have happened: Saving that record stripped out a bunch of "empty" fields and subfields. (like so: <datafield tag="100" ind1="" ind2=""><subfield code="a"/><datafield> ) and that is the only real change I can see. (I don't suspect any unusual characters or whitespace issues, it was created in the client "by hand" as far as I can tell.) |
| 11:00 |
Dyrcona |
Ah. We sometimes get errors from MARC export about records with empty subfields. |
| 11:00 |
Dyrcona |
That may be a bug of creating records from templates. |
| 11:00 |
Dyrcona |
I've never looked into it, though. |
| 11:01 |
jboyer-isl |
Which is likely long fixed, because we'd be hitting this constantly if it was still happening. |
| 11:01 |
Dyrcona |
Well, *I* still see it, and it is always on newly-created records before central site catalogers overlay the records from OCLC. |
| 11:03 |
jboyer-isl |
(I have at times wished catalogers could save records with lots of empty fields; that way they could create new templates in the editor and all I'd have to do is select the data out of them. Time for an LP about in-db templates, perhaps.) |
| 11:03 |
jboyer-isl |
Dyrcona: newly created as in newly imported, or are staff able to save records with blank fields? |
| 11:04 |
Dyrcona |
Created from a MARC template, so created and saved in the client. |
| 11:04 |
Dyrcona |
I'm searching my trash folder to see if it has turned up in any recent dumps for EBSCO. |
| 11:04 |
Dyrcona |
I get something like this: Field 520 must have at least one subfield at /usr/share/perl5/MARC/File/XML.pm line 481. |
| 11:06 |
Dyrcona |
I should merge cf4410e & a9d80dc into my production branch. |
| 11:07 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1502152: Improve marc_export warnings. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cf4410e> |
| 11:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1502152: (follow-up) fix a typo - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9d80dc> |
| 11:07 |
Dyrcona |
Then I'd know the record id. |
| 11:09 |
Dyrcona |
Since staff add the 520 field, or its in our templates, I know that record was created via the staff client. |
| 11:12 |
|
vlewis joined #evergreen |
| 11:13 |
jeff |
i need to adopt better style when it comes to indenting / nesting SQL |
| 11:25 |
Dyrcona |
Yay for Make targets for individual scripts! |
| 11:27 |
Dyrcona |
jeff: (add-hook 'sql-mode-hook (lambda () (setq indent-tabs-mode nil tab-width 4))) works pretty well for me. :) |
| 11:28 |
|
stonerl left #evergreen |
| 11:33 |
Dyrcona |
Hrm. Perhaps I misspoke about the 520. |
| 11:33 |
Dyrcona |
@marc 520 |
| 11:33 |
pinesol_green |
Dyrcona: Unformatted information that describes the scope and general contents of the materials. This could be a summary, abstract, annotation, review, or only a phrase describing the material. (Repeatable) [a,b,u,3,6,8] |
| 11:34 |
Dyrcona |
Yep. I did. |
| 11:34 |
Dyrcona |
@marc 540 |
| 11:34 |
pinesol_green |
Dyrcona: Terms governing the use of the described materials (e.g., copyrights, film rights, trade rights) after access has been provided. (Repeatable) [a,b,c,d,u,3,5,6,8] |
| 11:35 |
Dyrcona |
@marc 590 |
| 11:35 |
pinesol_green |
Dyrcona: unknown tag 590 |
| 11:37 |
Dyrcona |
Well, either I've guessed the wrong record, or I don't know what happened to it. |
| 11:47 |
Dyrcona |
Ah ha! |
| 11:47 |
Dyrcona |
Failure to map a character to MARC-8 in the 520 resulted in the record being skipped and erroring out. |
| 11:48 |
Dyrcona |
Looks like there's a UTF-8 em dash in the 520. |
| 11:48 |
* Dyrcona |
wishes vendors would just accept UTF-8 MARC records already. |
| 11:52 |
|
jwoodard2 joined #evergreen |
| 12:14 |
|
Christineb joined #evergreen |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:32 |
dbs |
Maybe once UTF-8 has really proven itself as a reliable technology. |
| 12:34 |
Dyrcona |
heh |
| 12:35 |
Dyrcona |
dbs++ |
| 12:37 |
Dyrcona |
UCS-16 foreva! |
| 12:48 |
Christineb |
Good Morning Everyone - just a reminder the Acquisitions Interest Group meeting will begin in ~10 minutes |
| 13:00 |
Christineb |
#startmeeting Acquisitions Interest Group Quarterly Meeting |
| 13:00 |
pinesol_green |
Meeting started Thu Nov 12 13:00:42 2015 US/Eastern. The chair is Christineb. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 13:00 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 13:00 |
pinesol_green |
The meeting name has been set to 'acquisitions_interest_group_quarterly_meeting' |
| 13:00 |
Christineb |
#topic Introductions |
| 13:01 |
Christineb |
#info Christineb is Christine Burns - BC Libraries Cooperative / Sitka |
| 13:02 |
jihpringle |
jihpringle is Jennifer Pringle - BC Libraries Cooperative / Sitka |
| 13:02 |
jihpringle |
#info jihpringle is Jennifer Pringle - BC Libraries Cooperative / Sitka |
| 13:09 |
Christineb |
Ok so I don't think anyone else is coming - I will just post a few updates and then end meeting... End of Year is very busy for Acquisitions |
| 13:09 |
Christineb |
#topic Review Previous Action Items |
| 13:10 |
Christineb |
Launchpad bug #'s added to official development wishlist - https://docs.google.com/spreadsheets/d/1iEWNjR3yhluIA5ViLZAj_QANEmaKlJ5L8JMubtO_mZc/edit#gid=0 |
| 13:10 |
Christineb |
Comments have been added to existing launchpad bug's for development wishlist top 5 list. |
| 13:11 |
Christineb |
#topic Review development wishlist |
| 13:11 |
Christineb |
Requirement document has been completed & posted for #1 - http://wiki.evergreen-ils.org/doku.php?id=acq:interest-group |
| 13:11 |
Christineb |
Big Thanks to Leslie St John & Elaine Hardy at Georgia Pines!!! |
| 13:12 |
Christineb |
#action need more info for #3, #4 & #5 |
| 13:12 |
Christineb |
#topic New Business |
| 13:12 |
|
lstjohn joined #evergreen |
| 13:12 |
Christineb |
Fix available for #2 from development wishlist "Acq Wishlist --> Add Batch Updater to Selection list interface" - https://bugs.launchpad.net/evergreen/+bug/1486191 |
| 13:12 |
pinesol_green |
Launchpad bug 1486191 in Evergreen "Acq Wishlist --> Add Batch Updater to Selection list interface" [Undecided,New] |
| 13:13 |
Christineb |
Fix for #5b - "Allow fund tags to rollover at fiscal year-end" - https://bugs.launchpad.net/evergreen/+bug/1204671 |
| 13:13 |
pinesol_green |
Launchpad bug 1204671 in Evergreen 2.8 "Fund tags are not carried over during fund propagation" [Medium,Fix released] |
| 13:13 |
Christineb |
#info Next Meeting will be Thursday February 18th @ 1:00pm EST |
| 13:13 |
Christineb |
#endmeeting |
| 13:13 |
pinesol_green |
Meeting ended Thu Nov 12 13:13:36 2015 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 13:13 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-11-12-13.00.html |
| 13:13 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-11-12-13.00.txt |
| 13:13 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-11-12-13.00.log.html |
| 13:13 |
jihpringle |
Christineb++ |
| 13:14 |
* Dyrcona |
is getting lost in Acquisitions at the moment. |
| 13:15 |
|
lstjohn joined #evergreen |
| 13:16 |
Dyrcona |
So, we have a purchase order and when I look at the EDI messages the ORDERS message is complete, ORDERSP is processed, and INVOIC is processed. |
| 13:16 |
* jeff |
closes one TODO and opens another |
| 13:16 |
Dyrcona |
The user reports that the invoice doesn't show up for the PO. |
| 13:16 |
|
leslie joined #evergreen |
| 13:16 |
Dyrcona |
So, I assume that I have to get the ORDERSP and INVOIC messages to complete for that to happen? |
| 13:17 |
* Dyrcona |
doesn't know how to do that. |
| 13:18 |
|
lstjohn_ joined #evergreen |
| 13:18 |
Christineb |
Dyrcona - quick question - do the invoices exist (are you able to open them?) It sounds like they may not be matching with the purchase orders |
| 13:18 |
Christineb |
matching / linking |
| 13:19 |
Dyrcona |
Christineb: I'm not sure what to search for to find the invoices. |
| 13:19 |
Christineb |
Message Type INVOIC will only ever say processed |
| 13:19 |
|
sandbergja joined #evergreen |
| 13:19 |
Dyrcona |
The PO shows 0 invoices available, but the EDI message of INVOIC is there, but not complete. |
| 13:20 |
Christineb |
If you look on the EDI messages screen - there should be a "File Name" this will be the "VENDOR Invoice ID" |
| 13:20 |
Christineb |
INVOIC will never say complete |
| 13:21 |
berick |
same w/ ORDRSP. they stop at 'processed'. an oversight in the code. |
| 13:22 |
Dyrcona |
The whole filename or just part of it? |
| 13:22 |
Christineb |
Example filename "20151111-inv518457-02028.810" - the invoice can be found by using general search --> search for invoices --> "Vendor Invoice ID is 518457" |
| 13:24 |
|
mmorgan1 joined #evergreen |
| 13:24 |
Christineb |
so just part of the filename - should be the number following "inv" |
| 13:26 |
Dyrcona |
Ah. My filename doesn't look like that: outgoing/1697978_3073548_OUT__20151030223443818.ein |
| 13:27 |
lstjohn_ |
Hi, you can also go to Providers and look at the invoices tab to find invoices |
| 13:27 |
Dyrcona |
But there is an invoice from months earlier with id 1697978 that was "Receive Method" Paper and "For testing purposes." |
| 13:27 |
Dyrcona |
I think I see the problem, now. :( |
| 13:29 |
Christineb |
Drycona: Our EDI fetcher will not pull in "duplicate" invoices (invoices where invoice ID already exists in the system) |
| 13:31 |
* berick |
confirms different vendors use different file name schemes |
| 13:31 |
Dyrcona |
lstjohn_: I'm not finding anything searching by provider. |
| 13:32 |
Dyrcona |
I think I'll just throw this at someone who has had some acq. training and say "it's over my head." |
| 13:33 |
berick |
Dyrcona: does the edi_message have a value for purchase_order ? |
| 13:33 |
Dyrcona |
berick: Yes, it does, and it is the PO in question. |
| 13:34 |
berick |
are there any acq.invoice_entry's pointing to lineitems from the PO? |
| 13:34 |
Dyrcona |
The user mentions another PO on the same ticket with multiple INVOIC messages, and they all start 1697978_[more numbers and junk] |
| 13:34 |
Dyrcona |
berick: I don't know jack 'bout acq.... I've passed the ticket on. |
| 13:36 |
berick |
Dyrcona: gotcha. fwiw, i was basically asking: select * from acq.invoice_entry entry join acq.lineitem jub on (jub.id = entry.lineitem) where jub.purchase_order = <po_id> |
| 13:36 |
berick |
if they exist, from there you can find the invoice |
| 13:37 |
lstjohn |
You have to go Admin->server admin->acquisitions->providers, select the provider and click on the Invoices tab |
| 13:37 |
lstjohn |
but it is the long way around and you have passed the ticket on. |
| 13:39 |
Dyrcona |
berick: FWIW, your query returns nothing. |
| 13:40 |
berick |
Dyrcona: k |
| 13:41 |
Dyrcona |
The EDI message ended on on the correct PO, though. |
| 13:41 |
berick |
hm, possible it only contains direct charges |
| 13:41 |
berick |
select * from acq.invoice_item where purchase_order = <id> |
| 13:42 |
berick |
if there's nothing there, then the invoice data is probably funky |
| 13:42 |
berick |
and there's likely an error osrfsys for when it was processed |
| 13:43 |
Dyrcona |
Nothing there, and acq.po_item is empty, which would only have something in it if the po had direct charges, right? |
| 13:44 |
berick |
right, acq.po_item are charges added to the PO, but you can get invoice-only direct charges as well (e.g. taxes included in the invoice that were not added to the PO) |
| 13:44 |
Dyrcona |
There's no error showing in the client. |
| 13:44 |
Dyrcona |
But, I'll grep the logs for 10/31/15 00:00. ;) |
| 13:44 |
csharp |
hmm - why "jub" for lineitem? |
| 13:44 |
berick |
if there were an error processing the invoice, it would be from the edi_fetcher.pl proces |
| 13:44 |
berick |
csharp: jacked-up bib |
| 13:44 |
csharp |
berick: LOL |
| 13:45 |
csharp |
berick++ |
| 13:46 |
berick |
csharp: maybe you were expecting https://i.ytimg.com/vi/gGH8kFjr9LA/hqdefault.jpg |
| 13:49 |
Dyrcona |
I'm not finding anything for edi_fetcher. Is that what I should be grepping for? |
| 13:50 |
csharp |
berick: I was ;-) |
| 13:51 |
berick |
Dyrcona: hm, yeah, that's how it appears in our logs |
| 13:51 |
berick |
Dyrcona: you might also see "EDI check for vendor.." |
| 13:52 |
csharp |
"./edi_fetcher.pl:" is how those show up for us |
| 13:53 |
Dyrcona |
Yeah, I'm not finding anything. |
| 13:54 |
berick |
as a reminder, it's a cron job, so if you run those on a different machine.. |
| 13:55 |
Dyrcona |
Looking for EDI turns up some open-ils.cstore.direct.acq.invoice.update calls. |
| 13:55 |
csharp |
'cd /openils/bin && /usr/bin/perl ./edi_fetcher.pl' is our cron job line |
| 13:55 |
Dyrcona |
berick: Right. |
| 13:55 |
csharp |
we run it at 1:00 a.m. |
| 13:55 |
berick |
csharp: just once a day? |
| 13:56 |
csharp |
berick: at this point, yes |
| 13:56 |
csharp |
the pusher runs every 30 mins |
| 13:56 |
Dyrcona |
Apparently, we run ours at midnight. |
| 13:56 |
Dyrcona |
Err, no. Every hour on the hour. |
| 13:57 |
csharp |
perhaps cron mail will provide a clue? |
| 13:57 |
Dyrcona |
Oh. Nice.... |
| 13:57 |
Dyrcona |
Apparently it is going to syslog on the utility box. I'll have to see if that makes it over to lorax, our logging server. |
| 13:58 |
Dyrcona |
That will be in a different location from our osrfsys.log files. |
| 13:58 |
csharp |
berick: I don't remember why we chose to do it just once a day - whether from recommendations or just preference |
| 13:58 |
* csharp |
is working on acq today too |
| 13:59 |
berick |
csharp: just curious. just boils down to preference. |
| 13:59 |
Dyrcona |
Not useful: 2015-10-31T23:00:01.715915-04:00 thing2-utility CRON[1408]: (opensrf) CMD (. /home/opensrf/.bashrc && /openils/bin/run_cron && cd $BIN_DIR && /usr/bin/perl edi_fetcher.pl 2>&1 > /dev/null | grep -v 'already retrieved') |
| 13:59 |
Bmagic |
we had a problem where we were sending them to often and the vendor was putting two PO's into the same PO because of some wild software on their side |
| 14:01 |
csharp |
dr_seuss_server_names++ |
| 14:01 |
Dyrcona |
Looks like the only useful messages are in /var/log/syslog on thing2-utility, and they only go back to the 7th of November. |
| 14:01 |
csharp |
Bmagic: ewww - good to know |
| 14:01 |
Dyrcona |
csharp: horton, lorax, thing1, thing2 |
| 14:01 |
csharp |
:-) |
| 14:02 |
csharp |
remember remember the 7th of November |
| 14:02 |
Dyrcona |
Next one will be jojo. |
| 14:02 |
Dyrcona |
csharp++ |
| 14:03 |
Dyrcona |
Misspoke, 6th November at 06:25 am, so that would cover the 5th of November... ;) |
| 14:03 |
Bmagic |
csharp: yeah, that took some digging to figure out. We ended up slowing it down to once per hour. I believe it was every 5 minutes before |
| 14:06 |
Dyrcona |
Nothing in cron emails, probably 'cause the messages are going to /dev/null. :) |
| 14:06 |
csharp |
@eightball is /dev/null web scale? |
| 14:06 |
pinesol_green |
csharp: The answer is def-- oooh! shiny thing! |
| 14:11 |
|
mmorgan joined #evergreen |
| 14:14 |
|
mmorgan2 joined #evergreen |
| 14:16 |
Dyrcona |
redirection syntax is weird, and what we have is correct. |
| 14:16 |
Dyrcona |
At least for what we want it to do. |
| 14:18 |
Dyrcona |
Grr. Complicated configurations.... |
| 14:21 |
Dyrcona |
So, the osrfsys.logs in question do end up on our logging server, just not where I was looking before. |
| 14:25 |
Dyrcona |
2015-10-31T00:00:05.876000-04:00 thing2-utility edi_fetcher.pl: [ERR :22298:CStoreEditor.pm:139:] editor[1|0] request error open-ils.cstore.direct.acq.invoice.create : <new object> : Exception: OpenSRF::DomainObject::oilsMethodException 2015-10-31T00:00:05 OpenILS::Utils::CStoreEditor /usr/local/share/perl/5.18.2/OpenILS/Utils/CStoreEditor.pm:465 <500> INSERT error -- please see the error log for more details |
| 14:28 |
berick |
getting closer... |
| 14:28 |
berick |
pg logs to the rescue |
| 14:31 |
Dyrcona |
I get to blame the provider. 2015-10-31T00:00:19.668083-04:00 horton postgres[73914]: [3-1] 2015-10-31 00:00:19 EDT ERROR: duplicate key value violates unique constraint "inv_ident_once_per_provider" |
| 14:32 |
* Dyrcona |
still has no clue how acq is supposed to work. :) |
| 14:32 |
tsbere |
Dyrcona: Magic. |
| 14:34 |
* Dyrcona |
stands at the end of the dilapidated runway with coconuts over his ears and frantically waves palm fronds in the air. |
| 14:48 |
mrpeters |
having some web client troubles -- seeing this error consistently in my gateway logs -- The timeout specified has expired: [client 73.176.215.80:60625] AH01991: SSL input filter read failed. |
| 14:48 |
mrpeters |
SSL certificate is valid and signed |
| 14:48 |
mrpeters |
I can't login to web client, choose a workstation, etc. |
| 14:49 |
csharp |
where could I find more blue buttons for the button bar? |
| 14:49 |
berick |
mrpeters: websockets is running and using same ssl cert? |
| 14:50 |
mrpeters |
berick: ah, you know what i bet it isn't looking at the same certs |
| 14:51 |
mrpeters |
yeah, its trying to use some default apache certs so that's surely the problem |
| 14:52 |
Dyrcona |
Well, damn. That error is not for this EDI message.... |
| 14:53 |
Dyrcona |
In fact, no errors for this EDI message, but no invoice created, either. |
| 14:54 |
tsbere |
csharp: Depends on how much work you want to do, I think |
| 14:55 |
tsbere |
csharp: I believe there is a background svg file in the xul/imagesources/toolbar_blue folder |
| 14:55 |
|
dkyle joined #evergreen |
| 14:55 |
csharp |
tsbere: I've been asked to add buttons that do the equivalent of Acquisitions -> Purchase Orders and Aquisitions -> Invoices |
| 14:56 |
csharp |
ah - I'll check that out |
| 15:02 |
Dyrcona |
Well, I found an invoice generated from that EDI message. |
| 15:03 |
Dyrcona |
It's an hour off from the timestamp in EDI messages in the client. |
| 15:03 |
csharp |
DST? |
| 15:04 |
mrpeters |
fun...same deal with the right certs in /etc/apache2-websockets/apache2.conf --- osrf_http_translator: [ssl:info] [pid 2383] (70007)The timeout specified has expired: [client 73.176.215.80:64375] AH01991: SSL input filter read failed. |
| 15:05 |
berick |
mrpeters: check the javascript console |
| 15:05 |
berick |
those apache errors are not that uncommon and don't always mean trouble |
| 15:06 |
Dyrcona |
csharp: Not sure. But, no invoice_entries for this invoice. |
| 15:06 |
jeff |
mrpeters: that particular error message is usually not -- right, what berick said. |
| 15:06 |
mrpeters |
yeah i see some bad news in the javascript console |
| 15:06 |
Dyrcona |
Two invoice_item entries. |
| 15:07 |
mrpeters |
unable to connect to hatch server, firefox cant establisha aconnection to the server at wss://foo:7682/osrf-websocket-translator |
| 15:07 |
Dyrcona |
And no acq.po_item for the purchase order. |
| 15:08 |
berick |
mrpeters: open a browser tab and go to https://foo:7682/osrf-websocket-translator |
| 15:08 |
berick |
or, well |
| 15:08 |
berick |
just https://foo:7682/ |
| 15:09 |
berick |
looking for an ssl cert warning |
| 15:09 |
mrpeters |
no action at all, actually |
| 15:10 |
mrpeters |
csharp: do we have a firewall situation blocking that port perhaps? |
| 15:11 |
csharp |
mrpeters: yes - check with awitter |
| 15:12 |
mrpeters |
will do |
| 15:12 |
mrpeters |
berick: any other ports we will need to open? |
| 15:12 |
Dyrcona |
Open all the ports!!!!! |
| 15:12 |
mrpeters |
lol |
| 15:13 |
berick |
7682 is all you need |
| 15:16 |
* berick |
sings All you need is 7682 ♬ |
| 15:16 |
* berick |
cues horns |
| 15:17 |
|
Callender_ joined #evergreen |
| 15:17 |
jboyer-isl |
OH. berick, csharp: I seem to remember one of you talking about an SSL cert for hatch that would be used for private networks (127., 10., 192.168., etc.) Unless I misheard something at the hackaway that's impossible. |
| 15:17 |
tsbere |
jboyer-isl: I believe that was me that came up with an idea for that. <_< |
| 15:18 |
jeff |
If you're getting a cert for your hatch instances, you'll want to be using a hostname. |
| 15:18 |
tsbere |
jboyer-isl: See the "Possibility for SSL cert issues" section of https://docs.google.com/document/d/1_wbIiU47kSElcg0hG2o-ZJ9hNmyM8v7rOWyi8jGvA38/edit#heading=h.ni2yq76skhtq |
| 15:19 |
jboyer-isl |
tsbere: sorry about that, I was very in-and-out about the hatch conversations. Anyway, you can't get a valid cert for a private network from a real registrar. (you could self-sign one and add it to your browser's trusted store, but then we're way outside of the comfort zone for those places where this would help) |
| 15:19 |
* berick |
tries to convince letsencrypt he owns "localhost" |
| 15:19 |
jboyer-isl |
There are also a list of generic 1-word hostnames that are banned from being granted also. :) |
| 15:27 |
csharp |
jboyer-isl: yeah, it was tsbere |
| 15:28 |
tsbere |
jboyer-isl: Also, if you haven't checked, my thought has nothing to do with getting a cert for the IPs, but using a single wildcard with subdomain entries that point to the IPs |
| 15:30 |
* csharp |
learns the hard way that gimp doesn't really do SVG |
| 15:30 |
* csharp |
tries to intuit his way through inkscape |
| 15:30 |
Dyrcona |
csharp: Inkscape, but be careful. It has two SVG modes. |
| 15:31 |
* jeff |
reads the doc |
| 15:31 |
jeff |
oh. |
| 15:31 |
csharp |
"Two roads diverged in a yellow wood..." |
| 15:31 |
jeff |
yeah, that will only work until your CA finds out what you're doing and revokes the cert. |
| 15:31 |
Dyrcona |
jboyer-isl: Oddly enough, if you pay attention to the certs you are handed, self-signed certs can be safer than trusting the "authorities" in your browser. |
| 15:33 |
Dyrcona |
Of course, that whole "paying attention" bit is what trips people up. |
| 15:33 |
jboyer-isl |
Dyrcona: Oh, I know. I heard about the Symantec issues right around the time I heard they were stopping the private range / internal name certs. |
| 15:34 |
Dyrcona |
Anyway, I now have lots of information about what happened with the invoices for two POs, but no idea what it means. :) |
| 15:36 |
Dyrcona |
If hatch is running on the local network with your browser, then why encrypt the traffic? |
| 15:36 |
berick |
Dyrcona: browsers require it :( |
| 15:36 |
berick |
you can't open a non-SSL websocket connection from an HTTPS page |
| 15:36 |
Dyrcona |
So, you want a desktop application, not a browser application? |
| 15:36 |
* Dyrcona |
ducks. |
| 15:37 |
berick |
well, we want to print. everything else works great in the browser. |
| 15:41 |
csharp |
how does koha handle multiple printers? |
| 15:42 |
jboyer-isl |
csharp: That's Q2; Q1 is "Does Koha handle multiple printers?" |
| 15:43 |
jboyer-isl |
<Buzzfeed>The answer may shock you!</Buzzfeed> |
| 15:43 |
jboyer-isl |
(I don't actually know) |
| 15:43 |
* csharp |
finds http://sclsstatus.pbworks.com/f/KOHA_Printing_Guidelines.pdf |
| 15:43 |
berick |
heh |
| 15:43 |
csharp |
dunno if that's "official" but it might be doable for us too |
| 15:44 |
berick |
this suggests a) a browser plugin and b) you can't automatically switch between the two |
| 15:45 |
Dyrcona |
Hmm.. this conversation sounds awfully familiar.... |
| 15:45 |
* Dyrcona |
ducks, again. :) |
| 15:45 |
Dyrcona |
But on a more serious note..... I got nothin'. |
| 15:46 |
jboyer-isl |
I would guess FF Profiles, which someone at that location has gone to considerable effort to set up. (i.e. doesn't scale well to large distributed installations) |
| 15:47 |
berick |
jboyer-isl: ah, could be |
| 15:50 |
berick |
could be browser plugins are the better route. never written one, so i can't really say. https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ |
| 15:50 |
berick |
"To this end, we are implementing a new, Blink-compatible API in Firefox called WebExtensions. Extension code written for Chrome, Opera, or, possibly in the future, Microsoft Edge will run in Firefox with few changes as a WebExtension" |
| 15:50 |
berick |
if we only had to write one, it's considerably more appealing |
| 15:51 |
csharp |
our libraries would probably be comfortable with the separate FF profile approach to multiple printers, at least until hatch is done |
| 15:51 |
jboyer-isl |
Ah, the joys of centralized (not around me) IT management. Must reboot to see if the IE11 install worked... |
| 15:52 |
Dyrcona |
So, it's going full circle: from everyone (just about) supporting NPAPI plugins to FF supporting everyone else..... |
| 15:55 |
|
jboyer-isl joined #evergreen |
| 15:58 |
Dyrcona |
I guess IE11 isn't working out so well. :) |
| 16:04 |
dbs |
maybe running a raspberry pi that acts as a print server for farming out the jobs for labels vs. small receipts vs. full pages and having the clients POST stuff to different URLs on that central print server would be unworkable for all kinds of reasons |
| 16:04 |
dbs |
printing-- |
| 16:05 |
dbs |
If getting hatch running locally on every machine that wants to print is a hassle, though, then maybe centralizing the hassle would be worth it. Maybe. In the glorious future, with many glorious extra resources. hah. |
| 16:09 |
|
jboyer-isl joined #evergreen |
| 16:11 |
jboyer-isl |
Dyrcona: It has not gone terribly well so far, no. |
| 16:15 |
Dyrcona |
So, if I am trying to manually link an invoice to a purchase order, what field's data goes into the invoice # field in the dialog? |
| 16:16 |
Dyrcona |
I've tried acq.invoice.id and acq.invoice.invoice_ident |
| 16:17 |
Dyrcona |
well, it's inv_ident, but anyway. |
| 16:20 |
berick |
if i'm reading the code right, it's inv_ident |
| 16:20 |
Dyrcona |
Ok, so why does it not find my invoice.... |
| 16:21 |
berick |
beware the invoice provider has to match the PO provider |
| 16:22 |
Dyrcona |
It does. |
| 16:22 |
Dyrcona |
But, we've got two named "Ingram" and no matter which one I try, it fails. |
| 16:23 |
berick |
when you try to link, the UI sends a pcrud query searching "acqinv" objects. should be able to work from there to find the query that's returning no results |
| 16:25 |
Dyrcona |
Hmm. maybe i should try this logged as their acq account. |
| 16:25 |
Dyrcona |
Seems to be searching for the wrong provider no matter what I put in. |
| 16:27 |
berick |
oh, it lets you pick the provider. forgot about that |
| 16:27 |
berick |
well, it does in theory |
| 16:27 |
Dyrcona |
Right, but I put in Ingram, and I get two options to "choose." |
| 16:28 |
Dyrcona |
Whether I pick the first or second, it is searching for 80. |
| 16:28 |
Dyrcona |
The one I want is 71. |
| 16:28 |
berick |
ah |
| 16:28 |
berick |
they have the exact same name? |
| 16:28 |
Dyrcona |
Yes. |
| 16:28 |
berick |
not that it should matter, just curious |
| 16:28 |
Dyrcona |
So do several others. |
| 16:28 |
berick |
i've never heard of that being a problem before |
| 16:29 |
berick |
"that" being dojo selectors being able to handle duplicates.. |
| 16:29 |
berick |
hmm |
| 16:30 |
berick |
thought I had something, but nevermind |
| 16:30 |
Dyrcona |
Well, that's logged in as my admin account that sees everything. |
| 16:30 |
Dyrcona |
When I log in at the library in question as there acq account, it works. |
| 16:31 |
Dyrcona |
I was able to link the invoice, and now I see that the invoice has 0 for the price of the line items and direct charges, which is what I gathered from the database. |
| 16:31 |
Dyrcona |
Well, I mean there are two direct charges that are not $0. |
| 16:32 |
Dyrcona |
Heh, # invoiced is 0 also. |
| 16:32 |
Dyrcona |
Methinks the vendor messed up. |
| 16:33 |
Dyrcona |
Although, I tried to link the invoice, it apparently didn't link. |
| 16:34 |
berick |
anyone ever discussed/implemented a way to set a total limit on the number of holds that can be placed for a given bib (etc.)? |
| 16:36 |
berick |
use case is we have some items for a limited time. would like to prevent holds if we know they'll never be fulfilled. |
| 16:37 |
Dyrcona |
No, we've never discussed that, but it sounds like an interesting problem. |
| 16:38 |
tsbere |
berick: Make them not holdable, and then if you want holds anyway use force holds only so that a staff member has to mediate them? |
| 16:38 |
berick |
tsbere: interesting thought. not sure it will work for us, but I'll relay that as an option |
| 16:42 |
tsbere |
berick: For similar "staff have to be involved" but supporting multiple copies capturing you could use hold rules that require that a non-patron place the hold (requestor is staff, usr is patron deal). |
| 16:44 |
Dyrcona |
So, this is weird. On the tab where I tried to link the invoice to the PO it shows 17 line items. On another tab where I did a general search for the invoice, it shows 0 lineitems. |
| 16:44 |
Dyrcona |
I assume that's because the one tab thinks the invoice is linked, but in the other tab it isn't because it is not actually linked in the database? |
| 16:49 |
Dyrcona |
Ah, it can't link because: the po only has line items (and no direct charges) and the invoice only has direct charges and no line items (entries). |
| 16:53 |
Dyrcona |
Although, I think I figured that out over an hour ago. |
| 16:54 |
Dyrcona |
It has been a long day. I think I'm calling it quits. |
| 16:54 |
Dyrcona |
See y'all tomorrow. |
| 17:05 |
|
bmills joined #evergreen |
| 17:09 |
Stompro |
Does anyone here use soft hold boundaries? |
| 17:09 |
mmorgan2 |
Stompro: We don't use them at NOBLE. |
| 17:16 |
|
mmorgan left #evergreen |
| 18:25 |
|
sarabee joined #evergreen |
| 18:34 |
|
dcook joined #evergreen |
| 18:57 |
|
kmlussier joined #evergreen |
| 18:57 |
|
mceraso joined #evergreen |
| 18:57 |
|
bshum joined #evergreen |
| 19:05 |
|
sarabee joined #evergreen |
| 19:43 |
|
bmills joined #evergreen |
| 20:21 |
|
kitteh_ joined #evergreen |
| 21:36 |
|
bmills joined #evergreen |
