Evergreen ILS Website

IRC log for #evergreen, 2017-05-09

| 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
03:32 ejk joined #evergreen
04:31 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:06 eady joined #evergreen
07:17 rjackson_isl joined #evergreen
07:53 agoben joined #evergreen
08:21 Dyrcona joined #evergreen
08:42 mmorgan joined #evergreen
08:51 bos20k joined #evergreen
09:01 rlefaive joined #evergreen
09:04 kmlussier joined #evergreen
09:04 kmlussier Good morning #evergreen
09:05 jeff good morning!
09:05 pinesol_green [evergreen|Jeff Davis] LP#1647852: Use correct method during adjust to zero on negative balance - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7b9c44d>
09:05 mmorgan Good Morning!
09:06 Dyrcona jeff++ # Find a bug in LibXML::XML.
09:06 Dyrcona Good morning!
09:18 kmlussier joined #evergreen
09:31 yboston joined #evergreen
09:37 kmlussier joined #evergreen
09:55 krvmga joined #evergreen
10:24 rlefaive joined #evergreen
10:25 kmlussier If I go to http://webstats.evergreen-ils.org/, I get a Piwik login form. I thought we were able to view webstats without logging in. If I use https://webstats.evergreen-ils.org, I get redirected to the https://evergreen-ils.org.
10:26 bshum kmlussier: Piwik was disabled awhile ago
10:26 kmlussier bshum: Oh, that would explain it then.
10:26 bshum By disabled I mean, we removed the tracking code and planned on killing it off
10:27 bshum I guess the DNS entry still exists for it
10:28 kmlussier I'm sure I knew it was being killed at the time, but I have no memory of it now. Why did we decide to disable it?
10:28 bshum And I also guess I don't remember the admin login credentials
10:28 bshum kmlussier: At the time, we were having a space issue on the web server I think
10:28 bshum And a problem with upgrading it to Debian Wheezy
10:28 bshum Up from Squeeze
10:29 bshum Something to do with upgrading MySQL I think
10:29 bshum If memory serve
10:31 bshum I think we just decided to end support for it due to lack of interest in keeping it upgraded and working
10:31 * kmlussier wonders if the WP site stats available in the dashboard is enough to meet our needs.
10:32 bshum I think that was the other idea that we could use the logging from apache to track some stats too
10:46 dbs Yeah piwik packaging with current Debian has been a long-running problem, not sure if they've corrected that recently
10:47 JBoyer Sometimes I hate Unix's silly attempts to save single characters. It's worse than our modern "drop the 'e'" branding.
10:48 JBoyer For instance: $SIG{ALRM} == set an alarm handler, $SIG{ALARM} == Errors in log files.
10:49 JBoyer (LP Incoming, BTW.)
10:51 * Dyrcona scratches gitlab off the list.
10:53 dbs ruh-roh
10:57 Dyrcona https://gitlab.com/gitlab-or​g/omnibus-gitlab/issues/1602
10:58 Dyrcona Just think about how you'd resolve that on a per-repository basis when only a handful of people have CLI access to the server.
11:01 Jillianne joined #evergreen
11:13 rlefaive joined #evergreen
11:14 Bmagic What is the permission that allows staff to populate the Org tree in the patron editor? It's not populating for a staff login
11:20 mmorgan Bmagic: Does the user have a working location?
11:20 Bmagic yes
11:20 Bmagic several
11:24 Christineb joined #evergreen
11:26 mmorgan Bmagic: Does this describe the same problem? http://irc.evergreen-ils.org/​evergreen/2016-12-16#i_280769
11:27 Bmagic yes :)
11:27 dbs JBoyer: can you amend your commit to state what the behaviour was before the typo fix, vs what happens after, for those of us who might be wondering what we should expect to see?
11:28 JBoyer dbs, ah, yeah, I did leave that a bit vague. Incoming soon.
11:28 mmorgan Unfortunately, I'm not sure of the exact solution there.
11:28 dbs JBoyer++
11:30 Bmagic mmorgan++
11:31 Bmagic This IS it. We added some OU's later. All of the logins that were created prior to those OU's work just fine
11:32 Dyrcona autogen.sh was run?
11:32 Bmagic The OU's we added should be depth 3 but are "Branch" (which is depth 2) but their parent OU is also depth 2
11:32 Dyrcona That's it. You broke the hierarchy.
11:32 Dyrcona You need to fix it.
11:32 Bmagic there is a logic issue I think when children OU's have the same depth as the parent
11:33 Dyrcona They shouldn't have the same depth.
11:33 Dyrcona Children should be 1 depth lower.
11:33 Bmagic right, lesson learned
11:34 Dyrcona Otherwise, it isn't a parent/child. It's more like siblings.
11:34 mmorgan Broken hierarchy never sounds good :)
11:36 JBoyer dbs: pushed. What you see now is a warning log line, what you should see is nothing. :)
11:37 dbs JBoyer++
11:39 kmlussier joined #evergreen
11:46 Bmagic Is there a time when Evergreen can work just fine with the parent OU/depth == child/depth ?
11:47 _adb joined #evergreen
11:47 Dyrcona Bmagic: Not that I am aware of, and that signals an error in your ou design.
11:48 Bmagic The staff client allowed us to create those.... it probably shouldn't
11:48 Dyrcona If depth is the same they are siblings, not parent/child, so should have a parent at a higher depth.
11:48 Dyrcona No, it probably shouldn't.
11:49 Dyrcona We had a case where someone assigned the parent's parent's ou type to an ou so the child had a depth higher than its parent.
11:49 Dyrcona Hilarity ensued when org unit drop downs were broken for some users but not others.
11:50 Bmagic when creating a child ou, the "Organization Unit Type" dropdown should only be populated with items of depth > (parent/depth)
11:50 JBoyer More specifically, is there any benefit at all in allowing a user to specify the depth vs something like a trigger looking at the parent_ou values?
11:51 Dyrcona Bmagic: I suggest bugging that on Lp if it's not there already.
11:51 JBoyer Dyrcona, Sharing report templates also get funky like that if a folder is shared more restrictedly than it's parent. Fun stuff
11:52 Bmagic Dyrcona: mmorgan linked your IRC log when you had that issue, which lead me to the resolution
11:52 Dyrcona JBoyer: IIRC, you select an ou_type from a list of names.
11:53 Dyrcona I think it should restrict the list to parent_depth + 1 if possible. I don't know how easy that would be in that interface.
11:53 JBoyer Oh, yes. depth as a field is on ou type, not ou.
11:54 Dyrcona Yeah. I didn't look at the link, but when you said it worked for some and not others, that rang a bell. :)
11:54 JBoyer (My Q still stands, it just encompasses more work, heh. ;) )
11:54 Dyrcona Yeah. :)
11:55 Dyrcona I think you might want to choose if there is more than 1 choice, like sublibrary and bookmobile for instance.
11:55 Dyrcona IIRC, they're at the same depth in the standard hierarchy, just below branch.
11:56 Bmagic bookmobile = 3, branch=2, system=1, consortium=0  right?
11:56 Dyrcona No, I think consortium=1, but I could be misremembering.
11:57 Dyrcona But something like that.
11:57 Dyrcona Lot of places have custom hierarchies.
11:57 Dyrcona But that shouldn't complicate things.
11:58 mmorgan Bmagic: Right, cons = 0
12:03 sandbergja joined #evergreen
12:03 kmlussier joined #evergreen
12:15 jihpringle joined #evergreen
12:17 dbs On our opening day in 2009, one of our administrators made their library be a child of itself and the system quickly crashed. We took away OU hierarchy editing privileges from everyone after that
12:18 dbs (I suppose we could add DB level constraints to prevent such nonsense... heh)
12:18 mmorgan Ouch.
13:36 jeffdavis SIPServer puts patron expiry date in a non-standard field. We have a vendor who says they can't use that (!), and wants us to add a different non-standard field to indicate if a patron is expired (Y/N). I am reluctant to start adding redundant non-standard fields to SIP responses, but maybe we should do it for the sake of broader support. Any thoughts?
13:39 Dyrcona On thought is why does this need the expiry date?
13:39 Dyrcona this [vendor] need...
13:39 * Dyrcona tells his fingers to cooperate with his brain.
13:40 jeffdavis Library wants to be able to block expired patrons but not patrons with fines.
13:41 Dyrcona Well, shouldn't an expired patron have a BL field value of N?
13:44 jeffdavis Should they? The account is valid, just expired.
13:44 jeffdavis Looks like BL is "Y" for expired patrons currently.
13:45 Dyrcona Looks like BL is "Y" for all patrons. :)
13:46 Dyrcona Well, it depends on your definition of "valid patron."
13:47 Dyrcona There is no standard field for patron expiry date.
13:47 jeff my preference on working around vendor desires / limitations is to have it be something configurable, ideally at a per-sip-client level.
13:48 Dyrcona Well, they can use that. They just have to change their code.
13:49 Dyrcona But, yeah, making it configurable is the way to go if you decide you have to do it.
13:49 Dyrcona I wonder what this vendor would tell SirsiDynix or III?
13:51 Dyrcona OK. BL is N if the patron id (barcode) is invalid.
13:52 Dyrcona So, I guess it really means "valid patron id"
13:53 Dyrcona And that code around that in SIPServer seems to imply we're still trying to support SIP 1.
13:53 Dyrcona But, I digress...
13:55 Dyrcona The comments imply that the field we're using for the expire date is what Envisionware expects.
13:55 jeff i can confirm that it works with Envisionware
13:56 jeff and i think we have something unusual in place for our selfchecks so that they get a friendly screen message when an expired patron attempts to use them.
13:58 eady joined #evergreen
14:01 Dyrcona If you wanted to implement an alternate field for expire date, it shouldn't be too hard, maybe 10 to 20 lines or so.
14:02 jeff some of it may come down to the vendor not supporting the idea of "expiry" at all, and it's the library driving the request. yet another reason for whatever protocol you use for vendor auth to be just a very verbose PASS / FAIL. :-)
14:04 Dyrcona XP: expired patron. Though XP is probably used for something else already. :)
14:04 jeffdavis They want PY specifically.
14:05 jeffdavis The implementation is not hard, but if I'm gonna do it I want to do it in a way that works for others (since I don't want to maintain a local customization for this).
14:06 Jillianne joined #evergreen
14:06 Dyrcona Y'know what. After doing a little more looking, I don't see any reason not to just add it and return it without configuration.
14:07 Dyrcona PY isn't used for anything else, and we do that for a couple of other extensions, including one that says "application unknown" in the comment.
14:07 jeff it will create an additional non-redacted log entry every time a patron is retrieved in at least one selfcheck product. :P
14:09 jeff longer-term, if SIP2 is going to continue to exist, we probably need to do some things to make our lives easier, like making it easier to add/drop fields from messages on a per-client or per-client-group basis.
14:09 jeff some of this ties into the things i've said about privacy and least-worst practices for abusing SIP2 for vendor auth, some of it just in general would probably be a worthy undertaking.
14:09 jeff (talking out loud, sorry)
14:11 Bmagic I am working on a SIP proxy server that could be used to filter fields or manipulate the message depending on need
14:12 Dyrcona Y'know, what, we really have no privacy.
14:13 Dyrcona My experience signing up for an account with a payroll company yesterday absolutely convinced me of that.
14:13 Dyrcona The information that they knew about me was scary.
14:15 jeffdavis I'm hoping to get some time to look at sanitizing SIP responses.
14:15 jeffdavis Bmagic: sounds interesting!
14:15 Bmagic Dyrcona: Agreed, I gave up on privacy a long time ago
14:15 Bmagic (personally)
14:16 Bmagic not for our patrons!
14:16 Dyrcona Well, my point is worrying about whether or not a patron being expired is being logged or not is nothing.
14:17 Dyrcona I'd say just add the field and be done with it.
14:18 Bmagic who has SIP connections over ssh?
14:20 jeff we pass SIP2 traffic over TCP in the handful of cases where it is passing over the Internet.
14:21 Bmagic so, not a tunnel?
14:21 jeff we also don't allow third party SIP2 access and most of our SIP2 clients are in the same building as SIPServer, so we tunnel less traffic than we did when SIPServer lived elsewhere.
14:21 jeff er, sorry. i mis-spoke. let me retry:
14:22 jeff we pass SIP2 traffic over SSH in the handful of cases where it is passing over the Internet.
14:23 Bmagic gotcha
14:23 Bmagic I am looking at autossh
14:23 Bmagic to keep the tunnel going when it breaks. Have you had to tackle that issue?
14:23 jeff we are happy autossh users
14:42 JBoyer Dyrcona, do you know anyone running NCIPServer against 2.11 or 2.12? I'm running into some trouble after loading the latest 2.12 this weekend.
14:43 Dyrcona NOBLE might be. I'm still running on 2.10, but I could test on 2.12. What's going on?
14:44 JBoyer Looks like the other end is getting 500 errors for CheckoutItem requests, and LookupUser requests are all returning "User with barcode (blah) unknown at (Location)"
14:45 JBoyer I haven't done a ton of looking yet, was wondering if you or anyone else had seen similar.
14:45 Dyrcona Have you got any scripts to test these, yourself?
14:46 JBoyer Really basic ones to send a single pre-composed request and save the reply.
14:46 JBoyer (so not really, no.)
14:49 Dyrcona I can send you some, just give me an hour or two.
14:49 JBoyer Thanks
14:49 Dyrcona Is the issue with 2.11, 2.12, or both?
14:50 mmorgan JBoyer: NOBLE is running NCIP on 2.11. I can check with mdriscoll to see if there were similar issues.
14:50 JBoyer I'm only seeing it on 2.12, latest rel_2_12 as of this morning.
14:51 JBoyer Not knowing what's up, I didn't know if it might also be hitting late 2.11's or not also.
14:51 Dyrcona OK.
14:52 Dyrcona I have a vm where I can easily test with 2.12.
14:52 Bmagic docker....
14:54 Dyrcona I say "easily" but I have to finish setting up Evergreen, etc. I'm using it to do another test of our upgrade to 2.12.
14:54 Dyrcona I don't have time to learn docker right now. :)
15:03 mmorgan1 joined #evergreen
15:04 JBoyer Nice. I get 500's even for a simple LookupUser against myself. :( Really the only logs I have for NCIP are the generic osrfsys logs that look fine, the full NCIP messages I dump coming and going, which looks fine, leading me to believe it's dying after rendering but before sending.
15:05 Dyrcona JBoyer: Did you also upgrade apache from 2.2 to 2.4?
15:05 Dyrcona Though, I suspect if the config was out of line, Apache would not start.
15:07 Dyrcona I have scripts for most of the messages with hard coded values. I meant to make them take parameters but haven't found the time.
15:09 Dyrcona I'll send you those and you'll have to change all of the relevant fields.
15:10 Dyrcona We should really make them generic and put them in a repo somewhere. ;)
15:10 JBoyer I've been on 2.4 for a good while and it's been fine.
15:12 Dyrcona OK. I've used it on 2.4, I just thought if you upgraded you might have missed a required change in configuration.
15:13 Dyrcona I've used it on 2.2 also.
15:13 Dyrcona That reminds me, I haven't installed the NCIPServer prerequisites on the vm.
15:13 Dyrcona I sent you the scripts.
15:14 JBoyer Dyrcona++
15:26 JBoyer Outlook doesn't like them. I do have a couple simple tests I can do locally (using w3m to post a file at (server)/NCIP and saving the reply)
15:48 jwoodard joined #evergreen
16:05 mmorgan joined #evergreen
16:07 mmorgan JBoyer: FWIW, we have not seen any NCIP issues on 2.11.
16:07 JBoyer Thanks
16:07 JBoyer mmorgan++
16:30 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:01 mmorgan left #evergreen
22:20 genpaku joined #evergreen

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