| 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-org/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 |
