| Time |
Nick |
Message |
| 06:58 |
|
wsmoak joined #evergreen |
| 07:09 |
|
akilsdonk joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 07:52 |
|
Callender joined #evergreen |
| 08:08 |
|
sarabee joined #evergreen |
| 08:12 |
|
Dyrcona joined #evergreen |
| 08:24 |
|
Shae joined #evergreen |
| 08:24 |
|
maryj joined #evergreen |
| 08:24 |
|
graced joined #evergreen |
| 08:24 |
|
eeevil joined #evergreen |
| 08:24 |
|
mtate joined #evergreen |
| 08:24 |
|
Callender_ joined #evergreen |
| 08:25 |
|
TaraC joined #evergreen |
| 08:26 |
|
phasefx joined #evergreen |
| 08:29 |
|
mrpeters joined #evergreen |
| 08:32 |
|
kmlussier joined #evergreen |
| 08:38 |
|
rjackson-isl joined #evergreen |
| 08:38 |
Dyrcona |
kmlussier: I updated my dev machine yesterday afternoon. It has dbwells latest branch, and fresh data from production. |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:39 |
|
mmorgan left #evergreen |
| 08:52 |
|
mmorgan joined #evergreen |
| 09:02 |
kmlussier |
Dyrcona++ #Thank you! |
| 09:03 |
kmlussier |
Well, then, I guess I know what I will be working on today. |
| 09:04 |
mmorgan |
negative_balances-- |
| 09:05 |
|
ericar joined #evergreen |
| 09:18 |
|
mdriscoll joined #evergreen |
| 09:18 |
kmlussier |
negative_balances-- indeed |
| 09:19 |
kmlussier |
getting_rid_of_negative_balances++ |
| 09:19 |
Dyrcona |
Is that a triple negative? |
| 09:19 |
kmlussier |
:) |
| 09:19 |
* Dyrcona |
is reminded of something from a linguistics class. |
| 09:20 |
Dyrcona |
Professor: In no language is a double positive ever considered a negative response. |
| 09:20 |
mmorgan |
getting_rid_of_negative_balances++ indeed! |
| 09:20 |
Dyrcona |
Student: Yeah, right. |
| 09:20 |
mmorgan |
Dyrcona++ |
| 09:20 |
jboyer-isl |
Bah-dum, pssh. |
| 09:21 |
csharp |
@quote add < Dyrcona> Professor: In no language is a double positive ever considered a negative response. Student: Yeah, right. |
| 09:21 |
pinesol_green |
csharp: The operation succeeded. Quote #98 added. |
| 09:22 |
jboyer-isl |
mmorgan, just wanted to let you know I haven't been ignoring your update to bug 1210541, but I've not had time to investigate/reply. |
| 09:22 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 09:23 |
jboyer-isl |
mmorgan++ # for testing it |
| 09:23 |
mmorgan |
jboyer-isl: no problem! I am thrilled to see progress on it! |
| 09:24 |
kmlussier |
jboyer-isl++ mmorgan++ |
| 09:24 |
Dyrcona |
If you search the logs you'll find some brief discussion of how we at MVLC solved some of our issues by increasing the limit on the number of files that our opensrf user can have. |
| 09:24 |
mmorgan |
jboyer-isl++ # for tackling it |
| 09:24 |
Dyrcona |
In the mean time, I've noticed that we're using a good bit more swap than we used to. |
| 09:24 |
csharp |
@weather 30033 |
| 09:24 |
pinesol_green |
csharp: The current temperature in Leafmore, Decatur, Georgia is 30.2°F (9:24 AM EST on November 14, 2014). Conditions: Clear. Humidity: 58%. Dew Point: 17.6°F. Windchill: 30.2°F. Pressure: 30.25 in 1024 hPa (Rising). Freeze warning in effect until 10 am EST this morning... |
| 09:25 |
* csharp |
shivers |
| 09:25 |
Dyrcona |
This leads me to suspect that something isn't closing file handles when it should, but I've not dug into, yet. |
| 09:25 |
Dyrcona |
@weather 01845 |
| 09:25 |
pinesol_green |
Dyrcona: The current temperature in Shawsheen Area, Andover, Massachusetts is 37.9°F (9:05 AM EST on November 14, 2014). Conditions: Overcast. Humidity: 81%. Dew Point: 32.0°F. Windchill: 37.4°F. Pressure: 29.94 in 1014 hPa (Steady). |
| 09:26 |
Dyrcona |
Shawsheen? Really? Guess that's close enough. |
| 09:39 |
bshum |
Stompro++ # just saw your examples for vote command usage you added to the wiki page for meetbot. |
| 09:39 |
jeff |
> Toby finds Josh and they meet with the State Department translator who is to help them with the Indonesian representative. However, Mr. Minaldi (the State Dept. translator) speaks Javanese, and Mr. Bambang (the Indonesian representative) speaks Botok. |
| 09:39 |
* bshum |
is amused. |
| 09:39 |
jeff |
> Donna appears to say that she is aware of this problem but has found a dishwasher in the White House kitchen that speaks Botok. Mr. Minaldi speaks Portuguese and so does the dishwasher. So Josh and Toby will be able to converse with Mr. Bambang via English-Portuguese-Botok-Portuguese-English. |
| 09:40 |
bshum |
jeff: That was a good episode. :P |
| 09:40 |
|
mllewellyn joined #evergreen |
| 09:40 |
jeff |
This is the scene from The West Wing that went through my mind this morning as I was describing to a co-worker how I was successful last night in initial testing with getting an outside vendor to verify patrons in our Evergreen system by emulating the III Patron API. |
| 09:42 |
bshum |
Yeah, that sounds about right. |
| 09:48 |
jeff |
There was a moment the other day where I thought the "Why don't we just speak in English" would have been more appropriate, but no. |
| 09:51 |
csharp |
The_West_Wing++ |
| 09:51 |
* csharp |
wishes everybody spoke SSL |
| 09:58 |
jeff |
SSL has been broken for eleven years or more. Talk TLS. ;-) |
| 10:01 |
jeff |
(to be fair, that should probably be more along the lines of "SSL hasn't had a new version in eleven years or more and all versions are now considered badly broken") |
| 10:09 |
csharp |
jeff: good point |
| 10:10 |
|
akilsdonk_ joined #evergreen |
| 10:21 |
Dyrcona |
STARTTLS |
| 10:26 |
jeff |
yeah. sadly, the ratio of active to passive attackers has increased. |
| 10:26 |
jeff |
and STARTTLS (as recent news has reminded) is pretty worthless against an active attacker |
| 10:27 |
jeff |
also sad, the number of "attackers" and flavors of attackers have both gone way up. |
| 10:28 |
jeff |
and yet I still have vendors in 2014 saying things like ``I understand the protection of your patrons’ information is paramount, but I am hopeful that we can start to move forward, and circle back towards adding the SSL tunnel in the near future.'' |
| 10:30 |
jeff |
somewhat pleasant to see the NY Times challenge this morning, though. |
| 10:30 |
Dyrcona |
Yep. |
| 10:30 |
Dyrcona |
Social login in the OPAC. What do you think? |
| 10:32 |
* Dyrcona |
wishes vendors using SIP2 would do SSH tunnels. |
| 10:32 |
Dyrcona |
We do them for our libraries' self check and PC reservation systems. |
| 10:34 |
Dyrcona |
Here in MA, I have a law that I can point to: 201 CMR 17.00 STANDARDS FOR THE PROTECTION OF PERSONAL INFORMATION |
| 10:34 |
Dyrcona |
OF RESIDENTS OF THE COMMONWEALTH |
| 10:34 |
jeff |
We have a vendor that has asked us to advise them on that topic. We're considering it, since there's benefit to the larger community. |
| 10:34 |
jeff |
I've also hacked up "just for patron auth, nothing else" in an untested (due to vendor timeline) proof of concept. |
| 10:35 |
jeff |
I've considered (and probably talked about here) a few other things that would help make the current reality of "some vendors use SIP2 for auth" a little better. |
| 10:36 |
jeff |
But I think the long term goal would still be to use technologies that are better with regard to being 1) less niche, 2) better experience for patrons and 3) not gaping privacy/security holes |
| 10:37 |
kmlussier |
Dyrcona: Do you still have the fine generator running overnight on your dev server? |
| 10:37 |
Dyrcona |
It should be. |
| 10:37 |
kmlussier |
Dyrcona: OK, I just wanted to check before I got to far in my testing. Thanks! :) |
| 10:37 |
jeff |
the "other things" for the current reality would include divorcing SIP2 credentials from ILS credentials, giving the ability to filter or limit SIP messages and their responses -- essentially a field-level fine-grained control over what a given SIP client can see and do. |
| 10:37 |
kmlussier |
s/to/too |
| 10:38 |
jeff |
that second bit could either be in SIPServer (with or without need for driver support -- probably depending on where you wanted to do your config) or via a SIP proxy, which would be a bit more complex but have wider benefit to those not running SIPServer |
| 10:39 |
Dyrcona |
kmlussier: I just checked that there were no tmp files hanging around for it, so looks like it ran OK last night. |
| 10:39 |
Dyrcona |
jeff: NCIP2 over HTTPS. :) |
| 10:39 |
jeff |
but i think i've talked about this kind of thing in here before (i know i've recently come across my own conversations in search results when doing some research along these lines ;-) |
| 10:39 |
Dyrcona |
jeff: Certificates for vendor authentication. |
| 10:40 |
Dyrcona |
Not that any vendor does that. |
| 10:40 |
jeff |
my proposed solution to the "no vendor does that" is a multi-faceted approach. :-) |
| 10:42 |
jeff |
1) create some "vendor" implementations, 2) work with interested vendors, 3) make it a deal-breaker when a vendor is not capable of meeting your requirements |
| 10:42 |
Dyrcona |
Meh. Internet, security, and privacy don't belong in the same sentence, except maybe this one. |
| 10:43 |
jeff |
...just call me pollyanna on item 3 above. ;-) |
| 10:43 |
* Dyrcona |
rocks out to "Black Feathered Wings" by Bourbon Princess. |
| 10:44 |
Dyrcona |
Call my cynical....but is it really cynicism if it comes from experience? |
| 10:44 |
jeff |
nope. :-) |
| 10:45 |
Dyrcona |
Heh. The chorus of "Black Feather Wings" is eerily apropos this conversation. |
| 10:46 |
Dyrcona |
"They always lie. They promise you wonderful things. They new said you'd grow horns or black feather wings." |
| 10:46 |
Dyrcona |
s/new/never/ |
| 10:46 |
* jeff |
laughs |
| 10:48 |
jeff |
"that claim you just made contradicts your earlier statements." |
| 10:48 |
jeff |
"no it doesn't. let me restate the claim." |
| 10:48 |
jeff |
"yeah, let's walk through this..." |
| 10:48 |
jeff |
"oh, i guess we can't make that claim anymore." |
| 10:48 |
jeff |
(HEAVILY paraphrased :P) |
| 10:49 |
jeff |
especially since iirc the last line was more of a "but... well..." |
| 10:49 |
Dyrcona |
Do I contradict myself? Very well, then, I contradict myself. I am large. I contain multitudes! -- Walt Whitman (also likely not quoted directly) |
| 10:51 |
* jeff |
grins |
| 10:52 |
jeff |
i do appreciate that one. |
| 10:52 |
Dyrcona |
Sadly, convenience almost always trumps security. |
| 10:53 |
Dyrcona |
Except, when the security isn't real, but a bunch of smoke and mirrors designed to give the impression of security, without actually providing any real security. |
| 10:53 |
jeff |
yeah, and i don't want to be in a situation where we as a library/project/profession are saying "we know best and you may not have it that way" on everything. |
| 10:53 |
jeff |
i try to be careful of that. |
| 10:54 |
bshum |
berick++ # love the idea for bug 1392759 |
| 10:54 |
pinesol_green |
Launchpad bug 1392759 in Evergreen "Developer/Packager Makefile.install targets" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1392759 |
| 10:55 |
* Dyrcona |
agrees with bshum. |
| 10:55 |
berick |
cool |
| 10:55 |
Dyrcona |
I thought that was a great idea when I saw the email. |
| 10:55 |
Dyrcona |
berick++ |
| 10:56 |
bshum |
berick: I think we need to include zip/unzip for staff client building. |
| 10:57 |
|
dreuther joined #evergreen |
| 10:57 |
Dyrcona |
nsis, aslo |
| 10:57 |
bshum |
One of those is never installed on my Ubuntu servers whenever I do it |
| 10:57 |
Dyrcona |
also, even. |
| 10:57 |
bshum |
nsis is in his initial branch |
| 10:57 |
Dyrcona |
OK. I didn't look. |
| 10:57 |
Dyrcona |
bshum lack of zip/unzip may be a vm vs. regular installation thing, too. |
| 10:58 |
bshum |
Dyrcona: That souldn't surprise me. |
| 10:58 |
Dyrcona |
I know that the way I install vms a bare minimum of packages are included by default. |
| 10:58 |
Dyrcona |
Wouldn't hurt to add it, though. dpkg/apt won't install it again if it is already installed. |
| 10:58 |
berick |
ah, right.. i'll add [un]zip |
| 11:00 |
Bmagic |
We are expierencing an issue with 2.7.0/opensrf 2.4 alpha in production. When using the fast item add feature on marcedit, the copy editor pops up (we are not using unified) and you click modify copies: the system does not save your copy into the system. It does create the volume however. |
| 11:00 |
berick |
force-pushed w/ zip and unzip |
| 11:00 |
bshum |
Bmagic: Interesting! Tell me more, cause I've been trying to solve a copy problem... |
| 11:01 |
Bmagic |
bshum: yes! I was hoping that someone else is seeing this |
| 11:01 |
bshum |
Bmagic: So we're having copy edit problems in other places, I don't think our libs use fast item add usually |
| 11:02 |
bshum |
Bmagic: What we've seen is that things like doing from menu: Edit -> Replace barcode doesn't work. |
| 11:02 |
bshum |
And neither do the new "edit" links in the catalog. |
| 11:02 |
* Dyrcona |
was about to say we hadn't seen it, but I'm going to check my internal ticket system. |
| 11:02 |
bshum |
It passes off the update command in perl, but it never actually does it to the database. |
| 11:02 |
Bmagic |
bshum: I've spent some hours on the code and found that $copy->isnew is null on OpenILS/Applicatoin/Cat/AssetCommon.pm line 301 when it should be "true" |
| 11:02 |
kmlussier |
bshum: Are you using the unified editor? |
| 11:02 |
bshum |
kmlussier: Yes. |
| 11:02 |
Dyrcona |
I seem to recall someone opening a ticket about fast item add. |
| 11:02 |
Bmagic |
kmlussier: no |
| 11:03 |
bshum |
Bmagic: That's... weird. |
| 11:03 |
kmlussier |
bshum: And the "edit" link in the catalog never works? |
| 11:03 |
bshum |
And may be different than what I'm seeing in our production then. |
| 11:03 |
bshum |
kmlussier: Edit spawns the unified editor for us. We make changes, hit update or whatnot. And when we look at the item, none of our changes have taken effect. |
| 11:04 |
Bmagic |
bshum: that is basically the same for us |
| 11:04 |
bshum |
For the last couple weeks since our 2.7 upgrade, I removed the edit link from our catalog so that staff don't make mistakes. |
| 11:04 |
bshum |
But we're slowly encountering other areas of brokenness |
| 11:04 |
bshum |
Like the replace barcode thing |
| 11:04 |
kmlussier |
bshum: Huh. I haven't seen that problem. I haven't used Fast Add lately, so I can't comment on that. But I do happen to have a client open, so I can check. |
| 11:04 |
Bmagic |
bshum: we have 2 different ways that fail: 1. when using the edit button on the opac view 2. using fast item add from the marc edit screen |
| 11:05 |
bshum |
Bmagic: Well.... shoot :( |
| 11:05 |
bshum |
It's nice to see confirmation. It's definitely NOT nice that there's something awry :( |
| 11:05 |
bshum |
Oh, replace barcode from the icon (under item status icon) doesn't work either for us. |
| 11:06 |
bshum |
Basically anywhere it's supposed to update the copy, it doesn't update the copy. |
| 11:06 |
bshum |
Outside of the regular chain of right-clicking on the copy in item status / holdings maintenance |
| 11:06 |
bshum |
And updating it |
| 11:06 |
Bmagic |
bshum: this worked in 2.6.1 and when comparing the relative perl modules between the two releases, there are NO changes (AssetCommon.pm, copy_editor.xul, copy_editor.js, Cat.pm) |
| 11:06 |
bshum |
Bmagic: Yep, that's my conclusion too. |
| 11:06 |
bshum |
I was starting to think maybe it's a change in OpenSRF or maybe some of the javascript changes |
| 11:07 |
Bmagic |
OpenSRF came to mind but I can't unwind the code and figure out where the isnew value is getting set |
| 11:07 |
mmorgan |
hmm. This is ringing a bell. |
| 11:07 |
mmorgan |
Not a problem for us in production (2.6), but something like this happened on our trianing system once. |
| 11:07 |
Bmagic |
mmorgan: yes..... |
| 11:08 |
bshum |
Bmagic: The thing that bothers me right now is that when I install a fresh Evergreen master / OpenSRF master, I don't see this bug. So it seems sporadic somehow. |
| 11:08 |
bshum |
Meaning not production data, using concerto or whatnot |
| 11:08 |
mmorgan |
we were testing some code and had made changes to the fm_idl. |
| 11:08 |
kmlussier |
Odd, I just tried the Fast Item Add from the MARC editor and had no problems. |
| 11:08 |
mmorgan |
then we could not save changes to items. We reverted the idl and it fixed the problem. |
| 11:08 |
Bmagic |
kmlussier: are you on 2.7+ ? and OpenSRF 2.4+ ? |
| 11:09 |
kmlussier |
I wonder if I'm doing something somewhat differently. |
| 11:09 |
mmorgan |
Not sure if it's related, but might be a place to look. |
| 11:09 |
bshum |
mmorgan: Worth a try |
| 11:09 |
kmlussier |
Bmagic: I'm on master. I think it was just updated yesterday, but Dyrcona can confirm. |
| 11:09 |
* bshum |
does a quick diff |
| 11:10 |
Bmagic |
bshum: are you comparing 2.7.0 to master? |
| 11:11 |
bshum |
Bmagic: We're running master straight up |
| 11:11 |
bshum |
(with our customizations, of course) |
| 11:11 |
bshum |
Our current production is basically 2.7.1 |
| 11:11 |
|
sbrylander joined #evergreen |
| 11:11 |
Bmagic |
AssetCommon.pm, copy_editor.xul, copy_editor.js, Cat.pm are some of the key players |
| 11:12 |
bshum |
mmorgan: Nothing different in my fm_IDL.xml vs. stock it seems. |
| 11:12 |
Dyrcona |
Bmagic: Did you autogen.sh after upgrading? |
| 11:12 |
bshum |
So maybe not that |
| 11:12 |
Dyrcona |
If there were IDL changes, the JavaScript copy needs updating, and that is one of the things that autogen.sh does. |
| 11:13 |
Dyrcona |
I always do it after updates just to make sure. |
| 11:13 |
bshum |
... is suddenly unsure if he autogen'd |
| 11:13 |
Bmagic |
Dyrcona: good question, Im not really sure, but I will do it for good measure |
| 11:13 |
* bshum |
does the same |
| 11:14 |
Dyrcona |
Yeah, the server kmlussier is looking at was updated yesterday afternoon, so has latest master. |
| 11:15 |
Bmagic |
autogen didn't fix it |
| 11:16 |
bshum |
Well |
| 11:16 |
bshum |
My replace barcode works now... |
| 11:16 |
bshum |
After you autogen, you restarted apache right? |
| 11:16 |
bshum |
Bmagic --^ |
| 11:16 |
Bmagic |
I did |
| 11:16 |
bshum |
Okay |
| 11:17 |
bshum |
And restarted your staff client too right. Exit completely |
| 11:17 |
Bmagic |
but... my staff client wasnt restarted |
| 11:17 |
Bmagic |
bshum: let me attempt that |
| 11:18 |
Bmagic |
bshum: OMG, it worked |
| 11:18 |
bshum |
Dyrcona++ |
| 11:18 |
Bmagic |
Dyrcona++ |
| 11:18 |
* bshum |
is so relieved |
| 11:19 |
Bmagic |
wow, what a solution |
| 11:19 |
Dyrcona |
Glad I could help. |
| 11:19 |
Dyrcona |
mmorgan++ # for mentioning the IDL. |
| 11:19 |
Dyrcona |
mmorgan: Rather than revert the IDL, you should probably run autogen.sh next time. |
| 11:20 |
mmorgan |
Yeah, will know that next time. |
| 11:20 |
bshum |
mmorgan++ |
| 11:20 |
bshum |
Thanks so much everyone |
| 11:20 |
kmlussier |
Dyrcona++ mmorgan++ |
| 11:20 |
* bshum |
can't believe he missed autogen... :( |
| 11:20 |
kmlussier |
bshum: But isn't it nice that it ended up being an easy fix? :) |
| 11:21 |
bshum |
kmlussier: So happy :) |
| 11:21 |
bshum |
Course now I have to figure out how I hid the Edit links... and undo it :) |
| 11:21 |
kmlussier |
bshum: I imagine your catalogers will be very happy to get those restored. |
| 11:22 |
jeff |
bshum: wait until it's likely everyone's restarted their staff clients. :-) |
| 11:22 |
bshum |
mllewellyn will definitely be happier ;) |
| 11:22 |
bshum |
jeff: Gah, you're right |
| 11:23 |
* kmlussier |
returns to negative balance testing but thanks Bmagic for the distraction. :) |
| 11:23 |
Bmagic |
The stock js files have the path to the server with the generic /server/ and autogen replaces that with whatever you compled with right? |
| 11:23 |
* bshum |
will wait for the weekend then. |
| 11:23 |
mllewellyn |
mllewellyn will be much happier |
| 11:23 |
kmlussier |
@dessert mllewellyn |
| 11:23 |
* pinesol_green |
grabs some pineapple chocolate things from New Zealand for mllewellyn |
| 11:24 |
Bmagic |
So in theory if you had ln -sf yourcompileddir/server server it should still work? |
| 11:25 |
mllewellyn |
kmlussier, yum, much thanks! |
| 11:31 |
jeff |
Bmagic: i think that the issue is that you had old javascript representations of the IDL from before you upgraded. among the things that autogen.sh updates are fmall.js/fmcore.js |
| 11:31 |
Bmagic |
jeff: Aha |
| 11:32 |
jeff |
Bmagic: with a fresh install, not running autogen.sh would have been more fatal and obvious. with an upgrade, the breakage is more... subtle. |
| 11:33 |
hopkinsju |
bshum++ |
| 11:33 |
bshum |
Bmagic++ |
| 11:33 |
hopkinsju |
@love autogen.sh |
| 11:33 |
pinesol_green |
hopkinsju: The operation succeeded. hopkinsju loves autogen.sh. |
| 11:34 |
* hopkinsju |
hugs autogen.sh |
| 11:42 |
|
jcamins joined #evergreen |
| 11:44 |
|
sandbergja joined #evergreen |
| 11:44 |
Dyrcona |
bshum: I'd setup a copy of the fixed template, and schedule a job via at to copy it into place after your libraries are closed tonight. |
| 11:44 |
Dyrcona |
A simple copy should do if the change only affects the template. |
| 11:50 |
bshum |
Dyrcona: a good idea indeed! |
| 11:52 |
jeff |
would people here be inclined to respond to a survey asking what vendors/services you use that tie into your ILS for patron auth, and what methods you use for each? |
| 11:53 |
Dyrcona |
Sounds like a worthy survey. |
| 11:59 |
bshum |
Didn't gmcharlt start something like that once? |
| 12:00 |
* bshum |
vaguely remembers some blog post / wiki page or something looking for that |
| 12:00 |
kmlussier |
Yes, I think it around conference time. But I can't remember which conference. |
| 12:00 |
bshum |
Maybe it was just broad third party stuff |
| 12:02 |
kmlussier |
http://evergreen-ils.org/olly-olly-oxen-free-users-of-evergreen-apis-stand-up-and-be-counted/ |
| 12:04 |
gmcharlt |
yeah |
| 12:09 |
* jeff |
nods |
| 12:10 |
jeff |
this would be a very similar second round, but with a bit more specific focus. |
| 12:10 |
Bmagic |
Does the OPAC Login permission need to be granted at consortium level? |
| 12:15 |
mmorgan |
Bmagic: not sure, ours is. Is there a reason not to? |
| 12:16 |
|
dreuther joined #evergreen |
| 12:18 |
Bmagic |
mmorgan, I am wondering if a system wide "Everything" permission changes the OPAC login to "system" instead of consortium, which breaks the ability to login |
| 12:20 |
kmlussier |
Bmagic: I don't know the answer to your question, but, if it does, I do know there are other permissions at there that need to be set at the consortium level. Manage Parts comes to mind and anything related to bib records editing. |
| 12:20 |
kmlussier |
s/at there/out there |
| 12:20 |
kmlussier |
tsbere sent me a list of some of them at one time. |
| 12:21 |
Dyrcona |
Been a while since I looked at the code, but it the permissions checks may actually look for everything before looking for a specific permission. |
| 12:21 |
Bmagic |
kmlussier: so it's possible to give someone less permissions on acciedent by making them a member of grp_tree where System Everything is granted overriding anything granted at consortium? |
| 12:21 |
Dyrcona |
This would be a database function, IIRC. |
| 12:24 |
Dyrcona |
Anyway, if that's the case, the everything permission at system would trump a specific permission consortium wide, so yeah. |
| 12:26 |
Dyrcona |
We actually let our local admins do less than other local users. They can't catalog or circulate, for instance. |
| 12:26 |
Dyrcona |
They basically exist to have a special account to update local settings. |
| 12:26 |
Dyrcona |
Of course we don't let catalogers or circulators make those changes. |
| 12:28 |
Dyrcona |
But, that's a whole other discussion. ;) |
| 12:29 |
Bmagic |
Dyrcona: intresting |
| 12:29 |
Bmagic |
s/intresting/interesting/ |
| 12:33 |
dbs |
We have a number of people who are Local Admins + Circulators + Cataloguers. I love groups. |
| 12:33 |
Dyrcona |
Bmagic: It *might* be permission.usr_has_perm_at_nd that is tripping you up. |
| 12:34 |
Dyrcona |
That's in 006.schema.permissions.sql. |
| 12:35 |
Dyrcona |
It might be one of the other functions in there, though. |
| 12:35 |
Bmagic |
dbs: Dyrcona: we have similar grouping. The thing I found was if you give someone "Everything" at the system level, they cannot login to the OPAC |
| 12:36 |
Dyrcona |
We use a few groups. We find it useful to encourage user switching for those times that special permissions are needed. |
| 12:37 |
Dyrcona |
Evetthing at a circulation desk can be dangerous. |
| 12:37 |
Dyrcona |
Everything, even. |
| 12:58 |
|
gvitez joined #evergreen |
| 13:04 |
|
akilsdonk joined #evergreen |
| 13:14 |
|
buzzy joined #evergreen |
| 14:09 |
|
ericar_ joined #evergreen |
| 14:11 |
|
akilsdonk_ joined #evergreen |
| 14:14 |
mrpeters |
working with a very out of date system -- seeing the old ERROR: Cannot decode string with wide characters at /usr/local/lib/perl/5.14.2/Encode.pm line 241. CONTEXT: PL/Perl function "maintain_901" error -- i know this is usually something wrong in the MARCXML -- csharp thinks it may be the LDR -- anyone with "cataloger eyes" able to confirm what might be missing from the record (http://pastie.org/9719633) causing this error upon update? |
| 14:16 |
mrpeters |
fwiw, MARC::Charset = 1.33 / Evergreen 2.3.5 |
| 14:17 |
mrpeters |
Encode 2.64 |
| 14:19 |
jeff |
mrpeters: how are you obtaining that MARCXML? |
| 14:20 |
mrpeters |
postgres log |
| 14:20 |
mrpeters |
so, it would be the update they are performing |
| 14:23 |
mrpeters |
http://pastie.org/9719655 is the record as it sits currently in the database |
| 14:25 |
jeff |
mrpeters: the 264$c is where i'd look first. |
| 14:25 |
mrpeters |
oh yeah look at that |
| 14:25 |
mrpeters |
<subfield code="c">�2014</subfield> that can't be right :) |
| 14:25 |
jeff |
could be something else, though. |
| 14:26 |
|
RBecker joined #evergreen |
| 14:27 |
mrpeters |
the current db version is <subfield code="c">©2014</subfield> which is UTF-8 |
| 14:27 |
mrpeters |
� unicode, so that is probably the issue |
| 14:29 |
mrpeters |
i was just reading a release note about this, but i seem to have lost that window |
| 14:30 |
mrpeters |
ah here we go -- 2.6.0 -- upgrade 0851 |
| 14:31 |
mrpeters |
+CREATE OR REPLACE FUNCTION evergreen.maintain_901 () RETURNS TRIGGER AS $func$ |
| 14:31 |
mrpeters |
... |
| 14:31 |
mrpeters |
+use MARC::File::XML (BinaryEncoding => 'UTF-8'); |
| 14:31 |
mrpeters |
... |
| 14:31 |
mrpeters |
+use Unicode::Normalize; |
| 14:32 |
Dyrcona |
yep. what you're seeing sounds like a classic case of double encoding...i.e. lets try to encode something that is already encoded. |
| 14:35 |
mrpeters |
perfect. i know the next question will be is there a way to clean these up all at once. anyone put together a script to replace common unicode with the proper utf-8? does that happen in that 2.6 upgrade where it tells the system all records should be utf-8? |
| 14:37 |
Dyrcona |
mrpeters: Well, what does the evergreen.maintain_901 function look like in your database? |
| 14:38 |
Dyrcona |
It may be missing the (BinaryEncoding => 'UTF-8') bit. |
| 14:38 |
mrpeters |
could be...let me take a peek |
| 14:38 |
Dyrcona |
IIRC, that's the bit that would stop it from trying to encode it again. |
| 14:39 |
mrpeters |
noe, we're good...that is there |
| 14:39 |
Dyrcona |
Not sure then. |
| 14:39 |
mrpeters |
oh this is interesting |
| 14:39 |
mrpeters |
MARC::Charset->assume_unicode(1); |
| 14:40 |
Dyrcona |
I'd recommend upgrading to get the RDA stuff anyway, since the offending field looks like the copyright 264 from RDA. |
| 14:40 |
mrpeters |
oh, trust me, ive encouraged upgrading |
| 14:40 |
|
Stompro joined #evergreen |
| 14:41 |
mrpeters |
so an upgrade to a version with RDA support would handle a record like this |
| 14:42 |
Dyrcona |
Well, if there were other fixes, too. The RDA support is mostly displaying 264 and other fields in the OPAC. |
| 14:42 |
mrpeters |
was pulled in on 10/29, likely with z39.50 so i bet they pulled from a system with RDA support |
| 14:43 |
Dyrcona |
Ah, z39.50.... It has issues with UTF-8 records, or some UTF-8 records. |
| 14:43 |
Dyrcona |
I think I made a Launchpad bug about it. |
| 14:43 |
mrpeters |
yeah, at least i can make them aware to watch for this kind of stuff if they get the database update error |
| 14:44 |
mrpeters |
good stuff Dyrcona++ jeff++ |
| 14:45 |
Dyrcona |
I know we've dealt with an issue bringing a record in via z39.50 from another Evergreen site, and I think it was actually a copyright symbol causing the problem. |
| 14:46 |
Dyrcona |
Because it goes through yaz, I think it gets converted from utf8 to marc8 back to utf8 and some symbols don't work that way. |
| 14:46 |
Dyrcona |
I never really did take the time to dig into it because more important things always come up. |
| 14:52 |
Dyrcona |
I wonder if the OCLC number in the 901 isn't some how involved in the issue? |
| 14:52 |
Dyrcona |
I think we've seen weird stuff with TCNs when importing records via Z39.50. |
| 14:52 |
* Dyrcona |
has a number of Z39.50 bugs on his internal bug tracker that he should really sort out and determine if they're real bugs or not. |
| 15:05 |
|
mnsri joined #evergreen |
| 15:35 |
* mrpeters |
starts to think Encode is just totaly fubar |
| 15:36 |
mrpeters |
i think the problem is that Encode got upgraded to 2.64 and a 2.3.5 server should be 2.42_01 |
| 15:41 |
kmlussier |
@bartender Dyrcona |
| 15:41 |
* pinesol_green |
fills a pint glass with Bare Knuckle Stout, and sends it sliding down the bar to Dyrcona (http://beeradvocate.com/beer/profile/29/8842/) |
| 15:42 |
* kmlussier |
gets hungry looking at the ESI Twitter feed. |
| 15:43 |
csharp |
@dessert kmlussier |
| 15:43 |
* pinesol_green |
grabs some Chocolate Chip Cookies for kmlussier |
| 15:44 |
csharp |
@dessert add Pumpkin Pie |
| 15:44 |
pinesol_green |
csharp: The operation succeeded. Dessert #29 added. |
| 15:44 |
kmlussier |
csharp: Thank you! |
| 15:44 |
* csharp |
's wife just complained about a lack of cookies in the house IRL |
| 15:45 |
* csharp |
handed her a tangerine and called it "Nature's Candy" |
| 15:45 |
kmlussier |
csharp: There is always a severe lack of cookies in our house. |
| 15:45 |
* csharp |
escaped with minimal injury |
| 15:46 |
csharp |
I like to bake on the weekends... unfortunately, I eat more and exercise less as the weather gets colder |
| 15:46 |
csharp |
apparently I've evolved from bears or something |
| 15:47 |
kmlussier |
I think we all have |
| 15:49 |
jcamins |
csharp: as the baker in the family, I can attest to the fact that tangerines are not suitable replacements for cookies. |
| 15:50 |
kmlussier |
Ha ha. I've been sitting here wondering when jcamins would join the cookie conversation. |
| 15:50 |
Dyrcona |
mrpeters: That could be. I seem to recall there being some issue with Encode versions in the past. Also, 2.3.5! |
| 15:50 |
mrpeters |
yeah, im not having much luck finding a way to roll back to 2.42_01 |
| 15:51 |
jcamins |
kmlussier: it took me a bit to get over because I just started cataloging an elephant folio. |
| 15:51 |
mrpeters |
I was actually asked to install your Boopsie code, Encode and some other modules got upgraded (my fault), created a bit of a mess but i think sorting out Encode.pm is the last hurdle |
| 15:54 |
Dyrcona |
mrpeters: If it was upgraded by CPAN, you should be able to uninstall it. The one installed by the OS should still be there. |
| 15:54 |
mrpeters |
ah, true |
| 15:55 |
jcamins |
And, having carried an elephant folio over and placed it on the only flat surface that can fit such a large book, the cat arrives to climb on my lap. |
| 15:58 |
jcamins |
I suppose this is the disadvantage to library cats. |
| 16:04 |
mrpeters |
Dyrcona++ thanks that worked |
| 16:04 |
Dyrcona |
Glad to hear it. |
| 16:04 |
mrpeters |
i think the one Evergreen installed was gone...but re-running make took care of it |
| 16:09 |
|
akilsdonk joined #evergreen |
| 16:13 |
|
dreuther_ joined #evergreen |
| 16:14 |
|
ericar_ joined #evergreen |
| 16:42 |
|
mdriscoll left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:20 |
|
wsmoak joined #evergreen |
| 18:20 |
|
wsmoak joined #evergreen |
