| Time |
Nick |
Message |
| 00:26 |
|
_robbat2|irssi joined #evergreen |
| 04:28 |
|
sarabee joined #evergreen |
| 05:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:48 |
csharp |
@praise sys admins |
| 07:48 |
* pinesol_green |
sys admins is kind and patient to newbies |
| 08:05 |
|
maryj joined #evergreen |
| 08:13 |
|
_bott_ joined #evergreen |
| 08:24 |
|
akilsdonk joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:38 |
|
sarabee joined #evergreen |
| 08:40 |
|
rjackson_isl joined #evergreen |
| 08:44 |
|
Dyrcona joined #evergreen |
| 08:46 |
_bott_ |
http://intranet.grpl.org//data/comm_request_dumping_ground/Submitted_Forms/Other_Requests/1438290407/1438290406.xhtml |
| 08:46 |
_bott_ |
Oops, wrong place to paste! |
| 08:54 |
|
mrpeters joined #evergreen |
| 09:00 |
|
RoganH joined #evergreen |
| 09:04 |
Dyrcona |
That reminds me of something I found on bash.org some years ago, but I can't find it now. |
| 09:04 |
Dyrcona |
The next to last line was "Oops! Wrong window." |
| 09:05 |
Dyrcona |
The very last line was "How can it ever be the right window?" |
| 09:05 |
Dyrcona |
Or something to that effect. |
| 09:07 |
Dyrcona |
There's one I found, but it isn't the one. |
| 09:08 |
Dyrcona |
Quote number is 56878. I won't put a link because I'm self-censoring to some small extent. |
| 09:18 |
mtate |
Happy SysAdmin day, Evergreen! |
| 09:23 |
* mmorgan |
is parsing through dbwells' overdue hierarchy doc on lp 1479110 |
| 09:23 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479110 |
| 09:24 |
mmorgan |
When negative balance intervals are set, the doc says "Prohibited if in interval". |
| 09:24 |
mmorgan |
Shouldn't that read "Prohibited if outside of interval"? |
| 09:37 |
Dyrcona |
mmorgan: That was the original intent, yeah. |
| 09:38 |
|
mrpeters joined #evergreen |
| 09:39 |
|
Shae joined #evergreen |
| 09:40 |
|
yboston joined #evergreen |
| 09:40 |
mmorgan |
Ok, thanks, just making sure :) |
| 09:43 |
Dyrcona |
But, it looks like the code doesn't do that. |
| 09:43 |
Dyrcona |
I have to look more closely. |
| 09:48 |
Dyrcona |
Maybe someone else should have a look but the logic on line 1,045 of CircCommon.pm looks backwards to me. |
| 09:49 |
Dyrcona |
But the two places the _has_refundable_payments function gets used in CircCommon.pm, use a not logic, so it might be right in that context. |
| 09:50 |
Dyrcona |
Oh wait, never mind. Not enough caffeine. :) |
| 09:51 |
Dyrcona |
The logic is correct. |
| 09:51 |
mmorgan |
@coffee Dyrcona |
| 09:51 |
* pinesol_green |
brews and pours a cup of Sumatra Lake Tawar, and sends it sliding down the bar to Dyrcona |
| 09:51 |
Dyrcona |
if the last payment date plus the interval is equal to now or in the future, then we're inside the interval for refunds. |
| 09:52 |
Dyrcona |
So, yeah, it still works as intended. |
| 09:52 |
miker |
mmorgan / Dyrcona: you're both remembering the intent correctly: https://bugs.launchpad.net/evergreen/+bug/1479110/comments/8 |
| 09:52 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] |
| 09:53 |
Dyrcona |
Yeah. I was just expecting to see a <= instead of a >=. Guess my mental Boolean parser in on the fritz. |
| 09:54 |
mmorgan |
Sorry, didn't mean to be an alarmist, thought it must have just been a typo-ish thing in the doc. |
| 09:55 |
Dyrcona |
It probably is. |
| 09:57 |
* jeff |
breaks out the packet sniffer |
| 09:58 |
jeff |
there's a joke in here somewhere... i'd rather be sipping coffee than sniffing SIP? |
| 09:58 |
RoganH |
sniffing SIP just gives you headaches |
| 09:59 |
Dyrcona |
Huffing NCIP on the other hand..... |
| 10:00 |
jeff |
NCIP: Not Even Once. |
| 10:00 |
dbwells |
mmorgan: I'll fix the doc wording, thanks. Sorry for being careless with my wording. |
| 10:00 |
Dyrcona |
jeff++ |
| 10:09 |
jeff |
this morning's toolset includes: my phone, laptop, wireshark, vnc client, evergreen staff client |
| 10:10 |
jeff |
oh, and a psql shell of course. |
| 10:12 |
Dyrcona |
We built some dedicated sniffers a few years ago to see why certain libraries were slow using OpenBSD and netflow and that sort of thing. |
| 10:12 |
Dyrcona |
We'd plunk 'em between the LAN and router and collect the data. |
| 10:14 |
csharp |
Dyrcona: was that helpful? I've been envisioning something similar |
| 10:15 |
Dyrcona |
csharp: Yes, it was. |
| 10:15 |
Dyrcona |
We could say, "Yeah, you're getting the bandwidth you expect. Just stop watching 12 Youtube videos simultaneously." |
| 10:16 |
Dyrcona |
And this was a staff-only network, btw. |
| 10:16 |
csharp |
nice |
| 10:16 |
csharp |
it would be great to see what is actually happening at some of our libraries |
| 10:16 |
csharp |
I just don't trust the reports at face value |
| 10:16 |
Dyrcona |
We bought these $500 machines from Cappuccino PC. Doesn't take much. |
| 10:17 |
Dyrcona |
Real evidence beats anecdotes any day. :) |
| 10:19 |
Dyrcona |
At least two NICs and you can configure it as a pass through. |
| 10:19 |
Dyrcona |
We lost one somewhere. |
| 10:20 |
Dyrcona |
We think it is still at one of the libraries, but we're not sure which, and no one reports seeing anything odd with their networking equipment. |
| 10:22 |
tsbere |
I think it was disconnected but left sitting there.....so yea. |
| 10:35 |
jeff |
hrm. 63/64 pair with summary request for unavailable hold items. barcodes are returned in the 64 as expected. |
| 10:35 |
jeff |
first 17 request results in no response from the SIP server. |
| 10:36 |
* jeff |
attempts to reproduce somewhere where he has access to relevant logs |
| 10:57 |
|
Christineb joined #evergreen |
| 11:07 |
Stompro |
If your routers support netflow exports, you can get a report of all traffic easily without an inline tap. |
| 11:11 |
jeff |
if your routers support netflow/sflow can be a big if. |
| 11:12 |
jeff |
especially when paired with the if of "in a format that is 1) useful and 2) compatible with your available/preferred tools" |
| 11:14 |
Dyrcona |
OpenBSD can read CISCO netflow output, fwiw. |
| 11:15 |
jeff |
the argument could be made that if the network equipment can't generate suitable netflow output, replacing it with something that can could be an improvement. ;-) |
| 11:15 |
jeff |
but that's bordering on scope creep. |
| 11:17 |
Dyrcona |
yep. |
| 11:33 |
|
maryj_ joined #evergreen |
| 11:33 |
|
maryj joined #evergreen |
| 11:41 |
|
bmills joined #evergreen |
| 11:59 |
jeff |
oh good. this looks like a SIPServer bug. |
| 12:04 |
|
kitteh_ joined #evergreen |
| 12:11 |
* csharp |
just read jeff's last and heard "Oh, Good! The curtains are on fire!" in Marge Simpson's voice (from this early 90s Halloween episode: http://i.imgur.com/CJanemO.png) |
| 12:11 |
gsams |
csharp++ |
| 12:11 |
gsams |
got a giggle out of that |
| 12:12 |
csharp |
"Every day, same old cat..." |
| 12:16 |
jeff |
UPDATE asset.copy SET barcode = REGEXP_REPLACE(barcode, 'AY', 'ay') WHERE NOT deleted AND barcode LIKE '%AY%' AND circ_lib IN (SELECT id FROM actor.org_unit_descendants(22)); |
| 12:17 |
jeff |
that is a workaround for this SIP2 issue. |
| 12:17 |
jeff |
guess the issue? |
| 12:18 |
jboyer-isl |
I'm guessing those barcodes are actually LIKE 'AY%'. |
| 12:18 |
jeff |
some, but not all. |
| 12:20 |
jboyer-isl |
Oh, I suppose it could be a bug if they look like AY_______ instead. I suppose the "Is this a checksummed message" check is getting confused? |
| 12:20 |
jeff |
yup. |
| 12:22 |
jboyer-isl |
Hmm. Yeah, AY (and possibly AZ) should be treated as normal fields, not checked for via regex anchored $. (I'm making a couple of assumtions there, but given the issue, I think they're pretty safe assumptions to make.) |
| 12:22 |
jeff |
and it does appear that the barcodes containing-but-not-starting-with AY are fine, so i've set those back. |
| 12:23 |
* jeff |
mutters something about serial lines |
| 12:23 |
|
jihpringle joined #evergreen |
| 12:30 |
jeff |
nope, I was wrong. some still break it even if the AY is not first in the string. |
| 12:30 |
jboyer-isl |
Oops. I was wrong; no regex, but a substr($msg,-9,2), so basically the same thing. I'm not familiar enough with SIPServer to know where to start looking to fix that |
| 12:30 |
jboyer-isl |
jeff: count the number of digits after the AY. |
| 12:31 |
jboyer-isl |
Time to lunch and visit some GenCon'ers. |
| 12:39 |
jeff |
still not sure why on a test instance i get a 96 (retransmit) and on prod i get dead air. might be a secondary bug in multiplex. uncertain yet. |
| 13:45 |
jeff |
but yes, any SIP message that is at least 11 characters and whose last 9 characters start with AY will be passed through verify_checksum |
| 14:27 |
|
akilsdonk_ joined #evergreen |
| 14:32 |
|
Shae_ joined #evergreen |
| 14:59 |
kmlussier |
I'm just getting a chance now to wish a very Happy SysAdmin Day to all the awesome Evergreen Sys Admins in here! |
| 15:09 |
jeff |
okay, confirmed that while previous versions of this software transmitted SIP2 37/Fee Paid messages for credit card transactions as "payment type" of "02" (credit card), the new version sets "payment type" for credit card transactions to "01" (VISA) |
| 15:09 |
jeff |
(including non-VISA card transactions) |
| 15:09 |
* Dyrcona |
wonders if it makes a huge difference. |
| 15:10 |
Dyrcona |
Evergreen doesn't process the actual payment in that case, does it? |
| 15:10 |
jeff |
well, since they only ever used 02 previously, and informed me that 01 was an unused/vestigal type, Evergreen only records 02 as credit card, anything else as cash. |
| 15:11 |
jeff |
should I have probably originally treated 01 and 02 as credit card? probably. |
| 15:11 |
jeff |
will i be opening a bug and doing so now? yup. |
| 15:11 |
jeff |
evergreen does not process the payment, it simply records the payment. |
| 15:11 |
jeff |
which we then report on. |
| 15:11 |
jeff |
and reconcile with the bank statements and with the selfcheck reports. |
| 15:13 |
Dyrcona |
I'm sure you've thought of this, but if there are other values for different credit card, you probably want to count them all CC payments. |
| 15:13 |
Dyrcona |
You never know what 3rd party vendors are going to send you. |
| 15:15 |
* jeff |
nods |
| 15:16 |
jeff |
perfectly clear in hindsight. i can't recall if there was any other reason/logic for not treating an explicit "visa" the same as "credit card" |
| 15:17 |
jeff |
sip config option to "treat these types as credit card" and/or "treat all payments from this client as credit card / cash"... |
| 15:18 |
jeff |
generelized "force field X from this client to Y", variants for removing fields entirely, similar option for any messages from the server... make possible ALL THE THINGS... |
| 15:18 |
jeff |
(no, not starting any work on that today) |
| 15:36 |
jeff |
i've toyed with the idea of a sip translator that was able to do such "swiss army knife"-like things. |
| 15:36 |
|
jlitrell joined #evergreen |
| 15:37 |
Dyrcona |
Easiest thing might be to just say if payment type is one of these, treat it as credit card, otherwise cash. |
| 15:38 |
Dyrcona |
And, no, I don't remember if there was any reason for ignoring the specific codes for different credit card brands, either. |
| 15:38 |
jeff |
the codes are publically enumerated as 00 (cash); 01 (VISA); 02 (Credit Card) |
| 15:39 |
jeff |
apparently additional extensions / internal documentation adds a few others. |
| 15:40 |
jeff |
the argument for having them backed by config is getting stronger in my head, but i'm not sure where i think that config belongs. |
| 15:40 |
jeff |
the first step will be to treat 01 and 02 the same |
| 16:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:49 |
|
hopkinsju joined #evergreen |
| 17:51 |
hopkinsju |
Using vandelay to import some record we got back from backstage. They had RDA fields added, cleaned up, etc. Odd thing is that when I import with a 901c match set, I get 2 matches per record. |
| 17:51 |
hopkinsju |
http://cl.ly/image/0f0b2K1M1s14 |
| 17:52 |
hopkinsju |
When I look closer, I see that the matches are, unsurprisingly, the same record - just appearing twice. |
| 17:52 |
hopkinsju |
http://cl.ly/image/1U3z0c0J1t2S |
| 17:52 |
hopkinsju |
What gives? |
| 18:01 |
berick |
hopkinsju: i believe it's matching on two different match points |
| 18:01 |
berick |
it shows a row per match |
| 18:01 |
|
akilsdonk joined #evergreen |
| 18:02 |
berick |
instead of 1 row, with the total match score, as you might expect |
| 18:02 |
hopkinsju |
It's odd because there is only the one matchpoint. Or am I missing somethign? |
| 18:03 |
berick |
you are using a match set? |
| 18:04 |
berick |
the 9999 match score is for the 901c match. the "1" match score is, i think, some other match, based on your match set |
| 18:04 |
hopkinsju |
I'm using the 901c matchset. |
| 18:04 |
berick |
ah, that's it, then |
| 18:04 |
berick |
the system automatically matches on 901c and gives it a high score |
| 18:05 |
berick |
using a 901c match set just adds another match on the same field |
| 18:05 |
berick |
if you choose "exact match only" (or whatever it's called) the built-in 901c matching should do what you need, no match set needed |
| 18:05 |
hopkinsju |
Well that's bizarre. This is a *ahem* newly acquired system for us. It came with a 901c matchset. I thought that was standard. |
| 18:06 |
berick |
just checked, there's not one in my test DB |
| 18:06 |
hopkinsju |
Oh yeah, weird. I never noticed that Missouri Evergreen doesn't have a 901c matchset. KSL had one, and I just selected it, because it was there. |
| 18:06 |
berick |
ther are merge profiles using 901c, but no match set |
| 18:06 |
hopkinsju |
Cool, well, that clears things up then. |
| 18:07 |
hopkinsju |
berick++ |
| 18:07 |
hopkinsju |
Thanks for your help, as always! |
| 18:07 |
berick |
cool, you're welcome |
| 18:07 |
* berick |
heads off into the weekend |
| 18:11 |
|
akilsdonk_ joined #evergreen |
| 18:16 |
|
akilsdonk joined #evergreen |
| 18:58 |
|
akilsdonk joined #evergreen |
| 20:05 |
|
akilsdonk_ joined #evergreen |
| 20:07 |
|
bmills joined #evergreen |
| 23:46 |
|
Trigraph joined #evergreen |
