Time |
Nick |
Message |
02:38 |
|
RBecker joined #evergreen |
04:46 |
|
dbwells_ joined #evergreen |
04:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
07:10 |
|
wsmoak joined #evergreen |
07:10 |
|
wsmoak joined #evergreen |
07:17 |
|
kmlussier joined #evergreen |
07:35 |
|
kmlussier joined #evergreen |
07:39 |
|
jboyer-isl joined #evergreen |
07:46 |
|
collum joined #evergreen |
07:46 |
|
drigney joined #evergreen |
08:08 |
|
akilsdonk joined #evergreen |
08:13 |
|
rjackson-isl joined #evergreen |
08:17 |
|
phasefx_ joined #evergreen |
08:20 |
|
Dyrcona joined #evergreen |
08:34 |
|
ericar joined #evergreen |
08:38 |
|
mrpeters joined #evergreen |
08:41 |
|
mmorgan joined #evergreen |
09:22 |
|
Shae joined #evergreen |
09:24 |
|
Shae joined #evergreen |
09:29 |
|
yboston joined #evergreen |
09:55 |
|
sarabee joined #evergreen |
10:39 |
|
jwoodard joined #evergreen |
10:52 |
kmlussier |
Are metarecord holds included in the hold count that's listed on the bib record in the OPAC? |
10:53 |
|
jeffdavis joined #evergreen |
10:54 |
kmlussier |
Actually, maybe I should be posing this question to tsbere. Should I be seeing metarecord holds included in the count with the patch for https://bugs.launchpad.net/evergreen/+bug/1322341? |
10:54 |
pinesol_green |
Launchpad bug 1322341 in Evergreen "Part level holds do not display in OPAC" (affected: 2, heat: 10) [Undecided,New] |
10:55 |
kmlussier |
They dont' seem to be included, which is fine with me as long as that's the intended behavior. |
10:56 |
tsbere |
kmlussier: All I added was part holds. I did not add metarecord. If we want metarecord I think more needs to be done. |
10:57 |
tsbere |
that and including metarecord counts could be confusing. "Do we just include them all, or only when the hold could possibly include this bib based on selections?" |
10:57 |
kmlussier |
tsbere: OK, that's fine. I just wasn't sure if they were counted prior to the patch being loaded. If not, then the patch looks good to me. |
10:58 |
|
Callender_ joined #evergreen |
11:01 |
|
Callender_ joined #evergreen |
11:06 |
|
sarabee joined #evergreen |
11:12 |
|
tspindler joined #evergreen |
12:07 |
|
akilsdonk joined #evergreen |
12:22 |
jeff |
jrucker++ BDL++ for https://www.branchdistrictlibrary.org/professional/mieg_overdues.php -- never know when that will come in handy. :-) |
12:32 |
jeff |
today it was "bridging the gap between what the previous ILS had generated notices for and between when this library is live with postal notices via Unique" |
12:47 |
|
Callender_ joined #evergreen |
12:50 |
bshum |
So this is fun |
12:50 |
bshum |
The relator term for some bibs are being included as part of the author search link for search results. |
12:51 |
bshum |
For example, the second bib in this link: https://acorn.biblio.org/eg/opac/results?query=shakespeare+star+wars&qtype=keyword&fi%3Asearch_format=&locg=39&sort= |
12:51 |
|
Callender_ joined #evergreen |
12:51 |
bshum |
Which makes the author link entry as "Doescher, Ian, author." |
12:51 |
bshum |
With the full record view, it properly separates the "author" part out of the query link |
12:51 |
bshum |
Bug I guess? |
12:56 |
dbs |
ah, search results |
12:56 |
bshum |
dbs: Yeah I think it's something in the way that the author attribute is generated from misc_util |
12:56 |
dbs |
yeah, I think "bug", unless you want searches to go specifically to "Doescher, Ian, editor" vs. "Doescher, Ian, author" |
12:56 |
bshum |
But I'm still looking around |
12:57 |
* dbs |
looks forward to eventually being on EG 2.6 or 2.7 instead of decrepit old 2.4 |
12:57 |
bshum |
I think it's the same sort of problem I saw where the graphic_880 dance was grabbing all subfields for a given tag instead of just the bits and pieces. |
12:58 |
dbs |
probably |
12:58 |
bshum |
dbs: For fun, we set a date for our next upgrade to be the weekend after I'm supposed to cut 2.7.0. |
12:58 |
bshum |
So.... maybe it'll be on-time and not too broken. |
12:58 |
bshum |
:) |
13:00 |
dbs |
hah, no pressure |
13:01 |
|
DPearl joined #evergreen |
13:02 |
* bshum |
will file a bug when he gets to the office on this issue |
13:02 |
bshum |
I stopped on my way there to troubleshoot an unhappy DB server. |
13:07 |
|
jihpringle joined #evergreen |
13:54 |
* eeevil |
reads up an thinks wistfully of display_fields |
13:54 |
jeff |
display_fields++ |
13:54 |
berick |
display_fields++ |
13:55 |
kmlussier |
display_fields++ |
13:56 |
gmcharlt |
http://evergreen-ils.org/southeast-regional-evergreen-conference-october-8-9-2014/ |
14:01 |
kmlussier |
I'm curious. Is there a lot more work that needs to be done on Display Fields or just some minor tweaks? |
14:11 |
jeffdavis |
bshum: I've added release notes for bug 868653 per kmlussier's request (and sorry for the delay, I was on vacation) |
14:11 |
pinesol_green |
Launchpad bug 868653 in Evergreen "secondary permission groups (permission.usr_grp_map)" (affected: 3, heat: 20) [Wishlist,Fix committed] https://launchpad.net/bugs/868653 |
14:12 |
collum |
gmcharlt: it looks like the last part of your announcement was truncated. |
14:12 |
gmcharlt |
oy |
14:12 |
gmcharlt |
collum: thanks for the catch |
14:13 |
collum |
No problem. Just trying to determine if KY is South East. It was VA at one time. |
14:13 |
kmlussier |
jeffdavis: Ugh, sorry! I apparently forgot to add a comment to that LP bug. I wrote up a release notes entry shortly after it went in. |
14:14 |
jeffdavis |
ha, ok! kmlussier++ |
14:14 |
kmlussier |
jeffdavis++ |
14:14 |
jeffdavis |
I could've double checked and saved myself 5 whole minutes of work ;) |
14:14 |
csharp |
collum++ |
14:23 |
eeevil |
kmlussier: probably just a little work due to ingest code drift |
14:25 |
csharp |
@band add Ingest Code Drift |
14:25 |
pinesol_green |
csharp: I see nothing, I know nothing! |
14:27 |
gmcharlt |
collum: fixed |
14:27 |
gmcharlt |
collum: also, the conference is now open to anybody who cares to make their way to Raleigh |
14:27 |
collum |
Thanks gmcharlt. Sounds good. |
14:42 |
|
sarabee joined #evergreen |
15:01 |
pinesol_green |
[opensrf|Mike Rylander] LP#1337401: Only care about our own processes - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=cb56fd3> |
15:15 |
|
ericar joined #evergreen |
15:29 |
|
Dyrcona joined #evergreen |
15:30 |
eeevil |
@marc 214 |
15:30 |
pinesol_green |
eeevil: unknown tag 214 |
15:30 |
eeevil |
just as I suspected... |
15:33 |
kmlussier |
214? |
15:33 |
eeevil |
kmlussier: that's what I said... |
15:33 |
kmlussier |
Never heard of such a thing. But I'm not a cataloger. :) |
15:35 |
collum |
Became obsolete in 1993. http://www.loc.gov/marc/bibliographic/bd20x24x.html (under Content Designator History) |
15:37 |
eeevil |
collum++ |
15:44 |
kmlussier |
Ah! I wasn't a librarian in 1993. |
15:45 |
dbs |
so... would display_fields not display the "editor" part then? Or would it be smart enough to generate "Doescher, Ian, editor" for display but make the link just search "au:Doescher, Ian"? |
15:45 |
* dbs |
has not read through all of the code for bug 1251394 |
15:45 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" (affected: 3, heat: 16) [Wishlist,Triaged] https://launchpad.net/bugs/1251394 - Assigned to Bill Erickson (erickson-esilibrary) |
15:48 |
eeevil |
dbs: I haven't looked in a long time ... a question, though ... which is more correct? or, maybe the right thing is to have separate display fields for different name uses ... editor, creator, etc, separately displayable (from different index defs, to supply the context) |
15:48 |
|
Dyrcona joined #evergreen |
15:52 |
dbs |
eeevil: Undoubtedly, the answer will depend on the context. Some users / librarians will be outraged that clicking on "Doescher, Ian, author" didn't return results where he was an artist or editor. |
15:52 |
|
Dyrcona joined #evergreen |
15:52 |
|
jwoodard joined #evergreen |
15:52 |
dbs |
Others will be outraged if clicking on "Doescher, Ian, author" returns all results for Ian Doescher, and not just the ones where he is explicitly listed as an author by the good graces of $4 / $e. |
15:53 |
dbs |
STRANGE GAME. THE ONLY WINNING MOVE IS NOT TO PLAY. |
15:56 |
eeevil |
ah ... so, it's really "does this link (aka index def) cause a class-wide search or a field specific search". that could certainly be added as a flag on the index def. then, have separate definitions which supply the use context in the UI |
15:57 |
eeevil |
or even 2 links, like subject links on the detail page, that are "this name, anywhere in the class" and, on the contextual label, "this name, used this way" |
15:58 |
dbs |
eeevil: yeah, I was thinking the latter, too. Even though some people dislike that as well. Meh. |
16:10 |
eeevil |
@marc 21 |
16:10 |
kmlussier |
+1 to the flag. Making it configurable seems like a good approach. |
16:10 |
pinesol_green |
eeevil: unknown tag 21 |
16:31 |
|
tspindler left #evergreen |
16:33 |
tsbere |
Testing VM building scripts can be a PITA because you can't tell if they work unless you wait for an entire VM to build. >_> |
16:49 |
Dyrcona |
Well, yeah.... |
16:53 |
berick |
vbox_snapshots_and_cloning++ |
16:59 |
tsbere |
berick: That doesn't help when you want to have a script build you a fully clean one. From scratch. ;) |
16:59 |
* tsbere |
heads home for the day |
17:02 |
berick |
tsbere: ah, no it does not |
17:08 |
|
mdriscoll left #evergreen |
17:13 |
|
akilsdonk_ joined #evergreen |
17:15 |
|
mmorgan left #evergreen |
17:15 |
pinesol_green |
[evergreen|Yamil Suarez] Docs: Removed use of deprecated file suffix for eg_db_config in install docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b831871> |
17:28 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
19:04 |
pinesol_green |
Showing latest 5 of 36 commits to OpenSRF... |
19:04 |
pinesol_green |
[opensrf|Bill Erickson] LP#1268619: websocket: avoid sharedworker for firefox 29 - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=9fdef97> |
19:04 |
pinesol_green |
[opensrf|Bill Erickson] LP#1268619: JS libs capture all method errors - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=17ae5ca> |
19:04 |
pinesol_green |
[opensrf|Bill Erickson] LP#1268619: JS status codes can come across as numbers; stringify for match - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=c65c6d9> |
19:04 |
pinesol_green |
[opensrf|Bill Erickson] LP#1268619: update JS/WS/SSL code comment - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=755a586> |
19:04 |
pinesol_green |
[opensrf|Bill Erickson] LP#1268619: disable shared workers pending browser issues - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=2677f8e> |
19:09 |
bshum |
berick++ gmcharlt++ |
19:11 |
gmcharlt |
bshum: this may be useful for Apache 2.4 - http://paste.lisp.org/display/143442 |
19:11 |
bshum |
Cool! Thanks. |
19:12 |
gmcharlt |
that reflects tweaks I made to get it working on Debian testing |
19:13 |
bshum |
Gotcha |
19:13 |
gmcharlt |
also - it's necessary that the SSL certificate that your test system uses be valid |
19:13 |
bshum |
Okay, that shouldn't be a problem. |
19:13 |
gmcharlt |
if you need to test with a self-signed cert on Chrome or Chromimum, one workaround is to start the browser with --ignore-certificate-errors |
19:15 |
bshum |
Good tips, thanks Galen! |
19:35 |
|
drigney joined #evergreen |
20:40 |
|
mrpeters joined #evergreen |
20:41 |
|
mrpeters left #evergreen |
23:05 |
|
dbwells_ joined #evergreen |