| Time |
Nick |
Message |
| 01:35 |
|
StomproJosh joined #evergreen |
| 01:35 |
|
dbwells_ joined #evergreen |
| 01:36 |
|
JBoyer_alt joined #evergreen |
| 07:57 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:47 |
jeff |
i wonder if a "bib source: auto" feature with defined "fingerprints" (but not that kind of fingerprint) would be useful. |
| 08:47 |
tsbere |
jeff: Such as "appears to have an OCLC number -> oclc bib source"? |
| 08:47 |
jeff |
as i ponder treating "new bibs with null source" as a QA issue. |
| 08:48 |
jeff |
tsbere: yeah, or various electronic resource vendors, etc. |
| 08:48 |
Dyrcona |
jeff: I gave up on worrying about null bib sources, but I like your idea. |
| 08:48 |
jeff |
(and not certain that "has an OCLC number" is the best measure for the oclc one) |
| 08:48 |
tsbere |
jeff: If you want to make such a feature I will point out that, for example, OverDrive bibs may have OCLC numbers, so you will need a "this trumps that" ranking. ;) |
| 08:48 |
* jeff |
nod |
| 08:48 |
* jeff |
nods |
| 08:48 |
|
bos20k joined #evergreen |
| 08:49 |
|
finnx joined #evergreen |
| 08:51 |
|
mmorgan left #evergreen |
| 08:54 |
jeff |
i also wonder if there is a current way to limit bib matching/overlay to a given source. |
| 08:55 |
tsbere |
that.....may be useful to me in the near future as well, actually |
| 08:56 |
* tsbere |
was going to look into it at some point, and today may not be a bad day to do so |
| 08:58 |
jeff |
though in some cases a match set with another field that all records from that source may have in common might be just-as-good. |
| 09:00 |
tsbere |
jeff: I could see bib source going both ways. "Don't match against our OverDrive bib source when importing non-OverDrive records" and "Match against *only* our OverDrive bib source when importing OverDrive records" for example. |
| 09:00 |
jeff |
ah, but match sets don't permit fixed text that i can see. |
| 09:01 |
jeff |
so i couldn't do something like have a match set that only matches when 037$a is CL0500000109 |
| 09:01 |
jeff |
(which is a pretty strong "this is a safari books online bib" indicator) |
| 09:05 |
|
Callender joined #evergreen |
| 09:08 |
jeff |
oh, nevermind. Safari MARC files apparently no longer include the 037 I described above. |
| 09:10 |
Dyrcona |
Well, I handled Safari at MVLC by automating the load and always using our Safari bib source. |
| 09:10 |
Dyrcona |
But, I see where you're going. |
| 09:11 |
Dyrcona |
This would need to be well documented so that it could be applied to custom bib sources...just a thought. |
| 09:14 |
jeff |
frustrating with the most reliable identifier for a vendor-provided bib tends to be the URL. |
| 09:15 |
jeff |
because ignoring for the moment that vendors change urls from time to time, it gets in the way of an overlay attempt where the reason you're overlaying is because you're changing the url for something like proxying purposes. |
| 09:16 |
jeff |
almost need to export, match externally and affix the 901$c from the exported record to the new record, then overlay on exact match (901$c). |
| 09:17 |
Dyrcona |
Yep. Reliable and MARC are generally not the same thing. |
| 09:19 |
jeff |
035$a + 020$z might work for some/most of the batch i'm currently looking at, but i'm pretty sure the 035 can go from (VENDOR) to (OCoLC) in the source files. |
| 09:19 |
* tsbere |
has attempted to play with match sets in his dev machine, but can't even make one right now for some reason |
| 09:20 |
jeff |
i believe the create button for a match set will silently fail if you lack permission. |
| 09:21 |
jeff |
morning, dbwells! |
| 09:21 |
tsbere |
jeff: I am logged in as the "defined at DB build time" admin account... |
| 09:21 |
jeff |
probably not that, then. :-) |
| 09:21 |
jeff |
though there are some cases... |
| 09:22 |
jeff |
i forget what work_ou looks like for that user. |
| 09:23 |
* tsbere |
finds that, apparently, he has several dead services on his dev machine, says "screw it", and blows out his dev machine while switching to MVLC's training system for the moment |
| 09:25 |
tsbere |
jeff: Looks like you could add static strings under "Quality Metrics"...though I don't know which side of the match that applies to. |
| 09:25 |
* tsbere |
should go find the docs before playing too much |
| 09:31 |
|
finnx joined #evergreen |
| 09:38 |
Stompro |
Could someone remind me if staff are supposed to be able to search for and find titles where all the copies have a non opac visible status, from within the XUL staff client? I have a bib that has one copy marked missing, and the staff client doesn't show the missing copy when the title is brought up by id number, and won't bring up the title from a title search. Is that expected behavior? |
| 09:39 |
Stompro |
We are on EG 2.10.6. |
| 09:40 |
|
agoben joined #evergreen |
| 09:41 |
Stompro |
We had a problem once with ass.opac_visible_copies, but I didn't think the staff client used that, I thought it was supposed to show everything. |
| 09:42 |
Stompro |
s/ass/asset |
| 09:42 |
tsbere |
Stompro: I believe staff should normally be able to see missing copies, though I have seen people somehow get to a "public" pac interface in the staff client before... |
| 09:43 |
Stompro |
tsbere, I've seen that also, since search catalog doesn't trigger an auth check in my experience. I'm seeing the staff header though (record summary) so I'm assuming it knows I'm in staff mode... I'll try restarting the client though. |
| 09:45 |
|
maryj joined #evergreen |
| 09:51 |
Stompro |
Hmm, the same thing doesn't happen on our test system running 2.10.6... I mark the only copy as missing and it still comes up in a title search and the missing copy is shown when it is brought up. |
| 09:54 |
|
JBoyer joined #evergreen |
| 09:59 |
|
mmorgan joined #evergreen |
| 10:00 |
mmorgan |
windows10-- |
| 10:07 |
* gmcharlt |
hands mmorgan a shiny new Windows 9 |
| 10:08 |
* mmorgan |
laments the loss of Windows XP. |
| 10:08 |
* rhamby |
thinks that Windows 2000 was the best Windows they ever made |
| 10:08 |
gmcharlt |
yeah, 2000 and XP were both pretty solid |
| 10:10 |
mmorgan |
I have actually been pretty ok with win10 - until IT decided when to install a major update. It is MY computer, y'know!! |
| 10:11 |
Dyrcona |
Yeah, even I'll admit that Windows 2000 was good. |
| 10:15 |
Stompro |
So I changed the item back to available from missing, and there is no change in behavior. I still cannot find the bib by a title search, the copy still doesn't show up when viewing the record. But it does now show up in the public catalog..... and I'm an idiot... Search library was set to my branch. |
| 10:16 |
dbs |
I haven't minded Windows 10 the few times that I've used it |
| 10:17 |
JBoyer |
Windows 10 is a breath of fresh air compared to 8.0. 8.1 had less of a trash fire smell than 8.0, but not much. |
| 10:22 |
|
finnx_ left #evergreen |
| 10:25 |
tsbere |
Stompro: That would do it. <_< |
| 10:26 |
|
finnx joined #evergreen |
| 11:17 |
|
sandbergja joined #evergreen |
| 11:31 |
* tsbere |
stares at the progress bar on a 4022 record import in his dev machine |
| 11:32 |
dbs |
hmm. timeouts after 5 minutes of no activity on SIP ring a bell for anyone? |
| 11:32 |
tsbere |
dbs: I seem to recall writing "timeout after no activity" code for SIP... |
| 11:33 |
dbs |
I set "timeout=0" in the policy for our connection, but that appears to have done nothing |
| 11:33 |
dbs |
tsbere: hah! apparently bibliotheca doesn't do keepalives |
| 11:35 |
tsbere |
dbs: I wouldn't be surprised if 0 doesn't work right as an override, for that matter. |
| 11:36 |
tsbere |
in the "specific || general || default" syntax I think 0 gets skipped over. So if specific is 0 and general is 600 general will win.... |
| 11:46 |
dbs |
The more I look at this, the more I think bibliotheca is throwing me a red herring and it's actually another unicode issue |
| 11:49 |
dbs |
hmm, not in this case :/ |
| 11:55 |
dbs |
Doesn't make any sense, there was activity 4 minutes before the unknown server response. Maybe it's an Apache / cstore timeout |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:03 |
dbs |
ah ah! OILS: Patron->fine_items() ERROR: Not an ARRAY reference at /usr/local/share/perl/5.18.2/OpenILS/SIP/Patron.pm line 830 |
| 12:06 |
dbs |
hmm. what if the authtoken timed out and thus the open-ils.actor.user.transactions.history.have_balance returns an error instead of an array... |
| 12:10 |
|
bmills joined #evergreen |
| 12:11 |
dbs |
and then right after that we get open-ils.cstore: permacrud received a bad auth token: <blah> |
| 12:16 |
dbs |
hmm. how worried should I be that the bad auth token <blah> doesn't match any of the auth tokens logged for "successful login: username=<sipuser>" |
| 12:17 |
dbs |
oh wait I'm drunk, it's there |
| 12:18 |
dbs |
so 18 minutes later it's a bad authtoken. narrowing this down, a bit. |
| 12:21 |
dbs |
ah, we use an opac type login, so I guess we get whatever the default timeout is for opac sessions for those authtokens? |
| 12:21 |
dbs |
(in OpenILS::SIP::login()) |
| 12:22 |
dbs |
(we haven't set an opac timeout in actor.org_unit_settings thus default) |
| 12:28 |
dbs |
and after reading all the way through oils_auth.c and oils_auth_internal.c and opensrf.xml, we have... 420! |
| 12:30 |
dbs |
so if policy timeout was 600 (per default in oils_sip.xml), but opensrf.xml opac timeout is 420 (per default in opensrf.xml), then we have a gap of 180 seconds where the authtoken will be invalid? |
| 12:31 |
dbs |
that's assuming that the SIP server reauths at timeout |
| 12:31 |
* dbs |
will set policy timeout to 300 and see what happens |
| 12:32 |
dbs |
argh except oils_sip.xml policy timeout is 60 :/ |
| 12:33 |
dbs |
err no, 50 for the service, 600 for the policy |
| 12:34 |
jeff |
i can't give it a second set of eyes right now, but i'm following. i'll try to look later today. |
| 12:37 |
dbs |
and maybe verify_session isn't being called in all the right places |
| 12:40 |
dbs |
like, in this case, the error comes when retrieving the patron by their barcode; presumably in OpenILS::SIP::find_patron() we should call verify_session() before using the potentially stale authtoken in "return OpenILS::SIP::Patron->new($key => $patron_id, authtoken => $self->{authtoken}, @_);"? |
| 12:43 |
dbs |
yeah, it looks like in some of the deeper code we're just blindly using authtoken without checking to see if it's actually still valid |
| 13:22 |
|
kmlussier joined #evergreen |
| 13:32 |
|
maryj joined #evergreen |
| 13:35 |
* dbs |
adds verify_session() calls to the find_patron() and find_item() methods to see what happens |
| 14:08 |
* jeff |
tries to think if there's a strong reason for verify-then-use over use-and-relogin-on-failure |
| 14:09 |
jeff |
(not suggesting you go that route) |
| 14:09 |
tsbere |
jeff: less need to detect "oh, that was my authtoken dieing on me"? |
| 14:09 |
jeff |
just questioning something that's bothered me before about our current convention. :-) |
| 14:09 |
* tsbere |
wonders if "verify on incoming SIP2 message" would generally just work well |
| 14:10 |
jeff |
i don't think the current implementation allows for that. |
| 14:10 |
tsbere |
I doubt that any given SIP2 message parsing session would take long enough for any authtoken to expire. If it did the other end probably gave up long before then anyway... |
| 14:11 |
tsbere |
jeff: Add a single "callback" to the ILS driver for "I just started parsing a message", then add a verify to EG in said callback? |
| 14:11 |
* jeff |
nods |
| 14:11 |
|
yboston joined #evergreen |
| 14:13 |
jeff |
though if that were to continue and we really don't want to go the "handle failure gracefully instead of pre-flighting before every request" route, i'd want it to have at least some sense of debounce. :-) |
| 14:14 |
jeff |
"did i verify this auth token already within the last T time? skip." |
| 14:14 |
berick |
iirc, pre-flighting meant touching a lot less code. |
| 14:15 |
jeff |
berick: and that might be that. i'm just adding something else to look into later since dbs already figured out his original issue. :-) |
| 14:15 |
dbs |
and a call to open-ils.auth should be fast as it's a c service |
| 14:15 |
berick |
oh yeah, don't let me stop you |
| 14:16 |
dbs |
nice to have eyes on 10-year-old code every once in a while :) |
| 14:16 |
jeff |
but yes, if it comes down to "change everything" to save making what should be a rather fast preflight open-ils.auth request, there are other more important things to look at first. :-) |
| 14:16 |
jeff |
like making sessions durable! :-) |
| 14:18 |
jeff |
or usernames case insensitive! :-) |
| 14:18 |
jeff |
or killing xulrunner and dojo! |
| 14:23 |
dbs |
+1000 to the latter |
| 14:24 |
* tsbere |
is happy his "pre-check thousands of bib records, add subfield 9s to URIs, and output just the bib records that aren't already in production for later import" script works |
| 14:24 |
dbs |
and migrating to Angular 2! # before AngularJS 1 becomes the new Dojo 1.3 :) |
| 14:41 |
|
tspindler joined #evergreen |
| 14:44 |
tspindler |
We are looking at implementing Authorize.net through TSYS. I have to fill out the PCI compliance questionaire. Has anyone done this? |
| 14:45 |
berick |
tspindler: i would seriously consider looking at Stripe instead. PCI compliance is a beast. |
| 14:45 |
|
finnx left #evergreen |
| 14:46 |
berick |
Stripe means the CC data does not go to your EG servers, which drastically reduces the PCI compliance burden. |
| 14:46 |
JBoyer |
Seconded, even though I wasn't able to use it. (We're also using a service that removes the PCI burden from our systems) |
| 14:46 |
jeff |
thirded. |
| 14:46 |
jeff |
don't bring unnecessary systems or processes into scope for PCI-DSS. |
| 14:46 |
berick |
we just migrated to paypal hosted pages w/ some custom code for the same reason. |
| 14:48 |
berick |
this might make good lightning talk fodder |
| 14:48 |
tspindler |
berick: do you have the ecommerce setup to use paypal for fine and lost book payment in eg |
| 14:49 |
jeff |
i have cast this lightning before. |
| 14:49 |
berick |
tspindler: yeah, patrons can pay any kind of transaction (w/ a postitive balance) |
| 14:50 |
berick |
jeff++ |
| 14:51 |
tspindler |
thanks, we currently have paypal in place but we have libraires who want to do credit card payments at the desk and we are in the process of implementing the envisionware solution for one library |
| 14:51 |
berick |
tspindler: oh, misunderstood your question.. we're just doing credit cards too |
| 14:51 |
berick |
not actual paypal payments |
| 14:52 |
berick |
credit cards via paypal |
| 14:52 |
tspindler |
tsys will be processing their credit card payments and I thought we would move everything over to tsys to simplify management |
| 14:53 |
tspindler |
however, as you point out, the pci compliance piece with evergreen ecommerce is daunting |
| 15:15 |
|
bmills joined #evergreen |
| 15:17 |
|
kmlussier joined #evergreen |
| 15:23 |
jeff |
s/with evergreen ecommerce// |
| 15:23 |
jeff |
:-) |
| 15:37 |
tspindler |
according to the sales men its a breeze ;-), |
| 15:39 |
Dyrcona |
:) |
| 15:53 |
|
tspindler left #evergreen |
| 16:06 |
|
bmills joined #evergreen |
| 16:52 |
|
finnx joined #evergreen |
| 16:54 |
|
finnx joined #evergreen |
| 16:56 |
|
finnx joined #evergreen |
| 16:57 |
|
finnx joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:08 |
|
StomproJ joined #evergreen |
| 17:12 |
|
abneiman_ joined #evergreen |
| 17:16 |
|
bmills1 joined #evergreen |
| 17:17 |
|
JBoyer_alt joined #evergreen |
| 17:20 |
|
finnx1 joined #evergreen |
| 17:28 |
|
ejk joined #evergreen |
| 17:58 |
|
gsams_ joined #evergreen |
| 18:51 |
|
gsams_ joined #evergreen |
