| Time |
Nick |
Message |
| 04:08 |
|
BigRig joined #evergreen |
| 04:08 |
|
gsams joined #evergreen |
| 04:09 |
|
dbwells_ joined #evergreen |
| 04:10 |
|
dkyle joined #evergreen |
| 04:11 |
|
graced joined #evergreen |
| 05:22 |
|
rangi joined #evergreen |
| 06:43 |
|
kmlussier joined #evergreen |
| 06:43 |
|
ldw joined #evergreen |
| 06:43 |
|
mceraso joined #evergreen |
| 06:43 |
|
bshum joined #evergreen |
| 07:16 |
|
gsams joined #evergreen |
| 07:25 |
|
gsams joined #evergreen |
| 07:37 |
|
jboyer-isl joined #evergreen |
| 07:54 |
|
rjackson_isl joined #evergreen |
| 08:04 |
|
mrpeters joined #evergreen |
| 08:25 |
|
sarabee joined #evergreen |
| 08:32 |
|
krvmga joined #evergreen |
| 08:33 |
krvmga |
if there's a # in a call number, advanced search > numeric search seems to ignore it. |
| 08:34 |
krvmga |
i've been looking on launchpad for a bug related to this but haven't been able to find one yet. |
| 08:34 |
krvmga |
does this sound familiar to anyone? |
| 08:36 |
|
mmorgan1 left #evergreen |
| 08:37 |
|
Newziky joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:48 |
|
akilsdonk joined #evergreen |
| 08:51 |
|
Dyrcona joined #evergreen |
| 08:58 |
|
ericar joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:23 |
mmorgan |
krvmga: I believe characters like "#" in the search term are stripped out, possibly replaced by spaces when the search is executed. |
| 09:24 |
krvmga |
mmorgan: that seems to be what's happening. yes. library staff complains, though, because they can't search on call numbers like "Kit #1". |
| 09:25 |
|
yboston joined #evergreen |
| 09:25 |
krvmga |
or "Book Bag #1" |
| 09:25 |
Dyrcona |
krvmga: Are they doing a call number search when they're reporting this? |
| 09:25 |
krvmga |
Dyrcona: yes, Call Number (shelf browse) in numeric search |
| 09:26 |
Dyrcona |
krvmga: Something with Kit #1 for the call number should still show up. |
| 09:29 |
krvmga |
Dyrcona: it does, in fact, but not till after all the "book bag" call numbers |
| 09:30 |
krvmga |
http://catalog.cwmars.org/eg/opac/cnbrowse?cn=Book%20Bag%20#6&locg=95 |
| 09:30 |
krvmga |
for instance |
| 09:31 |
krvmga |
so if i search for "Book Bag #6", it's on the second page of returns |
| 09:31 |
Dyrcona |
http://bark.cwmars.org/eg/opac/cnbrowse?cn=book%20bag%20#1&locg=1 : It show up at the last entry on the first page of results. |
| 09:32 |
krvmga |
yes, instead of the central entry |
| 09:32 |
mmorgan |
Hmm. Looks like call numbers like "cd#1" that have the generic call number class get a label_sortkey of "CD 1" So I think they show up, but don't sort the way you would expect. |
| 09:32 |
krvmga |
mmorgan: yes |
| 09:33 |
Dyrcona |
Meh. It's browse. |
| 09:35 |
krvmga |
Dyrcona: i think the heart of the question is "bug or feature?". |
| 09:36 |
Dyrcona |
It's browse. It's obsolete as far as I am concerned. |
| 09:36 |
Dyrcona |
And, one person's bug is another person's (mis)feature. |
| 09:37 |
krvmga |
Dyrcona: i hear you. but what do i say to the libraries? |
| 09:37 |
Dyrcona |
Broken as designed? ;) |
| 09:37 |
krvmga |
ROFL |
| 09:38 |
Dyrcona |
There should be a non-browse version of that search, but I've never looked into the implementation of it. |
| 09:38 |
krvmga |
really? that's interesting. |
| 09:38 |
Dyrcona |
Search is definitely not my area in Evergreen. |
| 09:39 |
krvmga |
i've had requests from libraries for exactly that - a non-browse version of that search |
| 09:39 |
Dyrcona |
Note, the *should* is more aspirational than a statement of something that exists, i.e. if there isn't, there ought to be. |
| 09:39 |
krvmga |
ah, ic |
| 09:39 |
krvmga |
got my hopes up there for a second |
| 09:39 |
Dyrcona |
Well, English.... |
| 09:39 |
krvmga |
:) |
| 09:44 |
bshum |
Changing how label sortkey operates isn't wholly out of the question. And generic in general isn't used by default anymore for our consortium, everyone uses Dewey. |
| 09:45 |
bshum |
But I think sorting goes A-Z, a-z, 1-9, etc. |
| 09:45 |
bshum |
So if the entry is CD 1, i would expect and want that after CD z, etc. |
| 09:45 |
krvmga |
bshum: based on the results i see, that is all correct. |
| 09:46 |
krvmga |
i'm just going to try to explain that to the libraries and hope i don't get killed |
| 09:47 |
|
gmcharlt joined #evergreen |
| 09:47 |
|
maryj joined #evergreen |
| 09:48 |
* bshum |
think of it as a plus, at least all the numbers sort together-ish once you reach them. |
| 09:49 |
bshum |
I imagine the extra space conversion happens if using dewey classification |
| 09:49 |
mmorgan |
ish? Doesn't sound ideal :-( |
| 09:50 |
mmorgan |
We found the Dewey normalizer didn't work at all well for our data. |
| 09:50 |
* bshum |
shrugs |
| 09:50 |
mmorgan |
So we use the generic normalizer for both generic and dewey. |
| 09:50 |
bshum |
It is changeable, but arguments and wars have been started over that. |
| 09:50 |
Dyrcona |
IIRC, we modified the normalizer(s) at one point. Thought we shared that and it went in. |
| 09:50 |
bshum |
:D |
| 09:51 |
bshum |
Yes, we altered the normalizers for Dewey and LOC a couple times over the last years |
| 09:51 |
bshum |
Though not without controversy. |
| 09:53 |
mmorgan |
Contoversy among your libraries, in that different libraries expected them to work in different ways? |
| 09:54 |
Dyrcona |
Some controversy in the community, too. |
| 09:54 |
krvmga |
mmorgan: library staff expect call number (shelf browse) to work like basic search, where what they want comes up as close to first as can be. |
| 09:54 |
bshum |
Mostly community controversy. |
| 09:54 |
* bshum |
doesn't usually bother everyone else with library mis-use of the systems. |
| 09:54 |
bshum |
:) |
| 09:55 |
* mmorgan |
thinks that it is a reasonable expectation of libraries to find what they need :) |
| 09:58 |
mmorgan |
krvmga: You could steer your library to a report, or run them a query. Not exactly what they expect, but they can get the info they need. |
| 09:59 |
krvmga |
mmorgan: what i have observed as a chronic problem is library staff trying to use the opac to generate reports. |
| 09:59 |
bshum |
Just tell them numbers come after letters. |
| 09:59 |
bshum |
It's the order of things. |
| 09:59 |
krvmga |
despite 3 years of training efforts, they are not comfortable with the reports interface. |
| 09:59 |
bshum |
:P |
| 09:59 |
Dyrcona |
bshum: I know that's how it works, but that's backwards. |
| 10:00 |
krvmga |
they sometimes do not respond well to being advised they can run reports. |
| 10:00 |
krvmga |
bshum: i will tell them that |
| 10:00 |
krvmga |
Dyrcona: yes, you are correct about that. |
| 10:00 |
bshum |
Dyrcona: Sure, but until someone gives me a patch to fix that, I'll carry on. |
| 10:00 |
Dyrcona |
heh |
| 10:01 |
* Dyrcona |
doesn't browse. |
| 10:01 |
Dyrcona |
:) |
| 10:01 |
* Dyrcona |
also mostly does known item searches and has no trouble finding what he's looking for. |
| 10:02 |
* mmorgan |
thinks it's reasonable to expect to be able to search a call number and get a list of the surrounding numbers. |
| 10:02 |
* mmorgan |
runs off to meeting with head down ;-) |
| 10:03 |
|
collum joined #evergreen |
| 10:04 |
* Dyrcona |
waits on database upgrade scripts. |
| 10:11 |
remingtron |
Has anyone encountered Authorities bug 712490 in recent EG versions? |
| 10:11 |
pinesol_green |
Launchpad bug 712490 in Evergreen "Subfield order in bib. record changes when editing authority" (affected: 2, heat: 10) [Undecided,Incomplete] https://launchpad.net/bugs/712490 |
| 10:14 |
yboston |
I have |
| 10:14 |
Dyrcona |
remingtron: No one has reported it to me, and I have not noticed it. |
| 10:14 |
Dyrcona |
Well, there you go: Berklee does a lot with authorities. :) |
| 10:15 |
yboston |
I have seen it happen after soemone has done a merge of atuhority records with linked bibs |
| 10:16 |
remingtron |
yboston: thanks for confirming. Could you comment on the bug about it? |
| 10:16 |
yboston |
I had always meant to create a bug for it. Now I see that there is a bug that predates our EG migration |
| 10:16 |
Dyrcona |
remingtron: Are you seeing it? |
| 10:17 |
remingtron |
Dyrcona: we are just about to import our authority file |
| 10:17 |
Dyrcona |
remingtron: We import authorities quarterly, and we've not noticed this bug. |
| 10:18 |
Dyrcona |
I'm not saying it isn't there. |
| 10:19 |
Dyrcona |
We run linking again after each upload. I wonder if that makes a difference? |
| 10:19 |
yboston |
I think it happens when you do a lot of manual merging of authoirities within EG. Either the bug has gone away or if you avoid it use an outside company to merge duypkicate authoriites then return them to EG, |
| 10:19 |
yboston |
oops, sorry for the grammar |
| 10:20 |
Dyrcona |
Could be. We don't generally do anything with authorities directly in Evergreen. |
| 10:20 |
yboston |
at Berklee we still are doing our own auth merging, still trying to get funding to have an outside company help us with it |
| 10:20 |
yboston |
Also, at ever EG cofnerence someone mentiosn that bug to me. I always promise to create a bug for it :( |
| 10:21 |
yboston |
*every |
| 10:21 |
Dyrcona |
Well, you can confirm it, and add a comment. |
| 10:23 |
yboston |
I just added a comment and cofnirmed it affects me |
| 10:23 |
Dyrcona |
yboston: What release are you on? |
| 10:23 |
yboston |
I just switched to 2.7 the MOnday after the last EG conference |
| 10:24 |
yboston |
BW, I am not kidding that for the last three eyars at the EG cofnerence that bug has been mentioned to me by various folks |
| 10:24 |
Dyrcona |
I believe you. I recall hearing it mentioned at one, at least. |
| 10:25 |
Dyrcona |
Best thing is if we could set up a test to make it happen. |
| 10:25 |
yboston |
It could have gone away, but from Dan's comments it might have been a feature and not in the sarcastic CYA way |
| 10:25 |
Dyrcona |
That doesn't sound intentional to me. |
| 10:26 |
Dyrcona |
I don't recall what MARC says about subfield order, if anything. |
| 10:27 |
yboston |
Dyrcona: you are right I am not making much sense, I guess I mean that I understand the thinking that the $0 should be ignored by a lot of the UI, except here thta the change it location is quite jarring |
| 10:28 |
yboston |
in the MARC editor |
| 10:28 |
Dyrcona |
yep, $0 should be ignored, but the other fields should not move. ("Should" does not mean it is.) |
| 10:29 |
Dyrcona |
$0 should probably always be at the end, too. |
| 10:29 |
Dyrcona |
When my dev vm is running again, I'll give it a look. |
| 10:35 |
Dyrcona |
Whaddya know? The upgrade scripts finished. |
| 10:39 |
bshum |
Dun, dun, dunnnnnn |
| 10:39 |
Dyrcona |
heh |
| 10:40 |
Dyrcona |
Only took about 1 hour. |
| 10:43 |
dbwells |
krvmga: I think the problem you are seeing with "#" in call numbers is not with the DB/normalization side, but simply an issue with the "#" not getting URL encoded. Since "#" is special in a URL, the variable effectively gets truncated. That looks like a bug to me. You can also see it work fine if you manually encode the "#": |
| 10:43 |
dbwells |
krvmga: http://catalog.cwmars.org/eg/opac/cnbrowse?cn=Book%20Bag%20%236&locg=1 |
| 10:43 |
krvmga |
dbwells: really? wow. |
| 10:44 |
krvmga |
dbwells++ |
| 10:44 |
|
pmurray joined #evergreen |
| 10:53 |
krvmga |
https://bugs.launchpad.net/evergreen/+bug/1467559 |
| 10:53 |
pinesol_green |
Launchpad bug 1467559 in Evergreen "# hash tag truncated in URL in Call Number (shelf browse)" (affected: 1, heat: 6) [Undecided,New] |
| 10:56 |
Dyrcona |
Guess I should find a controlled field with more than 1 subfield to test lp 712490. |
| 10:56 |
pinesol_green |
Launchpad bug 712490 in Evergreen "Subfield order in bib. record changes when editing authority" (affected: 3, heat: 16) [Undecided,Incomplete] https://launchpad.net/bugs/712490 |
| 10:56 |
Dyrcona |
I did find an author with the $0 before the $a in the bre's 100. |
| 10:56 |
dbwells |
krvmga: pretty sure I'm not Chris Sharp, but I've been called worse ;) |
| 10:57 |
krvmga |
Dan, i fixed it. Monday morning brain gas... <humbly apologizes> |
| 10:57 |
Dyrcona |
The $0 does not display in the Evergreen catalog. |
| 10:57 |
* bshum |
suddenly feels that should be <humbly apologizes /> but I digress |
| 10:57 |
dbwells |
krvmga: haha, no problem, just found it amusing |
| 11:01 |
krvmga |
bshum: lol |
| 11:01 |
krvmga |
or i should have put <humbly apologizes>abjectness here</humbly apologizes> |
| 11:03 |
mmorgan |
dbwells++ |
| 11:06 |
Dyrcona |
So, how do you know when an authority merge has finished in the staff client? |
| 11:07 |
Dyrcona |
Hmm. Looks like it doesn't work for me. |
| 11:08 |
Dyrcona |
'Course, I don't know what I'm doing in that interface, either. |
| 11:10 |
yboston |
It has been a while, but first question I have. How many linked bibs did each authoirty record you we merging have/had? |
| 11:10 |
yboston |
here is an open bug that makes the merge operation hang if the number of linked bibs is "high enough" |
| 11:11 |
yboston |
if you are not being affected by that timeout bug, I would try searching for the two merge auth names to see if oen went away and the expected one remained |
| 11:11 |
Dyrcona |
yboston: Ninety on one and 316 on the other. |
| 11:11 |
Dyrcona |
From the look of it, though, it goes to the database to do the merge. |
| 11:12 |
yboston |
I suspect you might have hit that bug. We hit it with more than 13 linked bibs some times |
| 11:12 |
yboston |
the timeout is on the DB side, not xulrunner |
| 11:12 |
yboston |
will look up bug |
| 11:12 |
yboston |
bug 1193490 |
| 11:12 |
pinesol_green |
Launchpad bug 1193490 in Evergreen "Authority merge time out when too many records, " (affected: 3, heat: 18) [Medium,Triaged] https://launchpad.net/bugs/1193490 |
| 11:13 |
yboston |
assumign you are hitting this bug, you mightt want to try to merge auth records that have a lot less linked bibs. Like less than 15 each |
| 11:17 |
Dyrcona |
yboston: But, if I do the merge in the database, it should work. I'm guessing that the cstore layer is timing out, 'cause a message processing duration of 60 seconds comes up in the logs. |
| 11:17 |
Dyrcona |
Nothing in my db logs about a time out. |
| 11:18 |
yboston |
I don't remember the details of the issue, I am attempting to quote what eeevil explained to me a while ago. My memory might be wrong |
| 11:19 |
yboston |
s/I am/I was/ |
| 11:23 |
Dyrcona |
Yep. It took 72.575 seconds in the database. |
| 11:25 |
Dyrcona |
Maybe I picked a bad one to test with. |
| 11:25 |
Dyrcona |
We had two subject headings for Fables, so I merged them. |
| 11:26 |
Dyrcona |
Looking at some records for books by Coelho, I don't see that the the fields changed order after the merge, but the most they have in that sugject is three, including the $0. |
| 11:27 |
Dyrcona |
That should be "subfields changed order." |
| 11:35 |
jeff |
hrm. |
| 11:35 |
jeff |
morning! |
| 11:35 |
mmorgan |
'Morning! |
| 12:00 |
jeff |
dojo.require('diaf'); |
| 12:01 |
|
bbqben joined #evergreen |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:17 |
jboyer-isl |
jeff: D'oh, the diaf module wasn't included until 1.4. We're stuck. |
| 12:49 |
|
Sato joined #evergreen |
| 13:41 |
krvmga |
i do a browse search for subject philippines history. in the list is one entry with (22) after it. i click that and get a list of results. then i check the group formats and editions checkbox and get sorry no entries were found for "' |
| 13:41 |
krvmga |
is this odd? |
| 13:42 |
krvmga |
or does group formats and editions have a problem with subject search results? |
| 13:46 |
|
ningalls_ left #evergreen |
| 13:47 |
eeevil |
that's not a subject search result, though it looks similar. and, yes, group formats should go away from that ui |
| 13:48 |
krvmga |
eeevil: is that something i have control over or were you just expressing a wish? |
| 13:48 |
eeevil |
a wish :) |
| 13:48 |
krvmga |
:) |
| 13:48 |
krvmga |
i'm seeing this same issue in other searches as well. is this a bug i should report? |
| 13:49 |
eeevil |
browse results should all lose that option, if that's what you mean |
| 13:51 |
krvmga |
eeevil: i'm thinking that. yes. |
| 14:11 |
|
bbqben joined #evergreen |
| 14:16 |
|
ningalls joined #evergreen |
| 14:35 |
Bmagic_ |
@updog |
| 14:35 |
pinesol_green |
Bmagic_: Have you confirmed your ISBN SPIDs with your service provider? |
| 14:36 |
Bmagic |
@updog |
| 14:36 |
pinesol_green |
Bmagic: Try restarting apache. |
| 14:37 |
Bmagic |
pinesol_green: yes I did! |
| 14:37 |
pinesol_green |
Bmagic: No, you're a puzzleheaded kraken! |
| 14:38 |
Dyrcona |
heh |
| 14:38 |
Dyrcona |
@dunno |
| 14:38 |
pinesol_green |
Dyrcona: The horror... The horror... |
| 14:44 |
Bmagic |
pinesol_green: No, you're a puzzleheaded kraken! |
| 14:44 |
pinesol_green |
Bmagic: As great as you are man, you'll never be greater than yourself. |
| 14:44 |
pinesol_green |
Bmagic: I am only a bot, please don't think I'm intelligent :) |
| 15:03 |
mmorgan |
eeevil: (or anyone who might know) How's webby these days? Is it up to a few folks poking at it tomorrow? |
| 15:04 |
eeevil |
I'm working with it ATM. |
| 15:06 |
mmorgan |
We're having an open house tomorrow and plan to have a workstation where people can sit down the look around. |
| 15:09 |
bshum |
@dunno add We're going to need a bigger boat. |
| 15:09 |
pinesol_green |
bshum: The operation succeeded. Dunno #39 added. |
| 15:09 |
Dyrcona |
bshum++ |
| 15:10 |
mmorgan |
:) |
| 15:13 |
csharp |
@who [dunno]? |
| 15:13 |
pinesol_green |
maryj Have me confirmed my ISBN SPIDs with my service provider. |
| 15:13 |
eeevil |
mmorgan: I'll try to keep it happy. just poke me or gmcharlt if it's not, though |
| 15:14 |
mmorgan |
OK, Thanks!! |
| 15:14 |
gmcharlt |
I solemnly swear not to break it! |
| 15:14 |
mmorgan |
I solemly swear that I will try very hard not to break it! ;-) |
| 15:15 |
gmcharlt |
:) |
| 15:49 |
Dyrcona |
So, this is fun. |
| 15:49 |
Dyrcona |
I reloaded my dev database today and tried to use the web staff client. |
| 15:49 |
Dyrcona |
I couldn't log in because my workstation was no longer registered in the database. |
| 15:49 |
* bshum |
waits for the other show to drop |
| 15:49 |
bshum |
*shoe |
| 15:50 |
Dyrcona |
I had to clear local storage to log in and re-register. |
| 15:53 |
dbs |
Shouldn't be an issue in normal circumstances, right? |
| 15:53 |
Dyrcona |
I wouldn't think so, but it might come up with training setups. |
| 15:56 |
* berick |
suggests an LP for that |
| 15:56 |
berick |
good bite-size bug |
| 16:21 |
Dyrcona |
berick: lp 1467663 |
| 16:21 |
pinesol_green |
Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" (affected: 1, heat: 6) [Low,New] https://launchpad.net/bugs/1467663 |
| 16:22 |
berick |
Dyrcona++ |
| 16:48 |
hopkinsju |
Are we alone in having a hold_type "F" in action.hold_request? |
| 16:49 |
Dyrcona |
hopkinsju: Nope. It is for force holds. |
| 16:49 |
hopkinsju |
Interesting. Thanks. |
| 16:50 |
bshum |
"I find your lack of faith disturbing" |
| 16:53 |
* hopkinsju |
took way too long on that one |
| 16:53 |
bshum |
I suppose the technical term was "force choke" not "force hold", but anyways. |
| 16:54 |
bshum |
"Hokey religions and ancient weapons are no match for a good blaster at your side, kid" |
| 16:58 |
Stompro |
Opensrf process question, should there only ever be one listener process per service on a machine? |
| 16:59 |
berick |
Stompro: under normal circumstances, yes. |
| 16:59 |
Dyrcona |
Stompro: Yes. |
| 16:59 |
* Dyrcona |
turns into a pumpkin. |
| 17:00 |
berick |
you can run multiples, but that's non-vanilla. |
| 17:00 |
Stompro |
Thanks, working on my zabbix rules and just want to set a trigger to alert for 0 or > 1 running listener processes. |
| 17:00 |
berick |
@dessert add Non-Vanilla Ice Cream |
| 17:00 |
pinesol_green |
berick: The operation succeeded. Dessert #37 added. |
| 17:01 |
* berick |
nods |
| 17:02 |
Stompro |
hopkinsju, thanks for the example template BTW. |
| 17:03 |
dbwells |
berick: thanks, it just so happens that is second favorite flavor of ice cream |
| 17:04 |
berick |
dbwells++ |
| 17:04 |
berick |
you see, it's easy to make everyone happy |
| 17:05 |
dbwells |
berick++ |
| 17:06 |
jonadab |
There are ice cream flavors besides chocolate? |
| 17:12 |
|
mmorgan left #evergreen |
| 17:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:39 |
|
remingtron_ joined #evergreen |
| 17:41 |
|
Newziky joined #evergreen |
| 17:42 |
hopkinsju |
Stompro: My pleasure. Hope it is of use. |
| 17:42 |
hopkinsju |
... mtate and I keep saying we are going to present a Zabbix vs Nagios session. Hopefully next year will be the year. |
| 17:42 |
|
hopkinsju joined #evergreen |
| 17:45 |
|
dkyle joined #evergreen |
| 17:53 |
|
hopkinsju joined #evergreen |
| 17:53 |
|
jeff_ joined #evergreen |
| 18:07 |
|
dkyle joined #evergreen |
| 18:19 |
|
finnx joined #evergreen |
| 20:23 |
|
gsams joined #evergreen |
| 20:43 |
|
gsams joined #evergreen |
| 21:30 |
|
artunit joined #evergreen |
| 22:37 |
|
bbqben joined #evergreen |
