Evergreen ILS Website

IRC log for #evergreen, 2015-07-31

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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_req​uest_dumping_ground/Submitted_Forms/Oth​er_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/eve​rgreen/+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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat