| Time |
Nick |
Message |
| 00:49 |
|
AliceR joined #evergreen |
| 02:36 |
|
AliceR joined #evergreen |
| 06:33 |
|
eeevil joined #evergreen |
| 06:33 |
|
mtate joined #evergreen |
| 06:34 |
|
BigRig joined #evergreen |
| 06:34 |
|
Callender joined #evergreen |
| 06:44 |
|
Callender joined #evergreen |
| 07:07 |
|
eeevil joined #evergreen |
| 07:13 |
|
kmlussier joined #evergreen |
| 07:13 |
|
Callender_ joined #evergreen |
| 07:14 |
|
mtate joined #evergreen |
| 07:22 |
|
wsmoak joined #evergreen |
| 07:22 |
|
wsmoak joined #evergreen |
| 07:27 |
|
TaraC joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 08:04 |
|
akilsdonk joined #evergreen |
| 08:06 |
kmlussier |
Good morning #evergreen |
| 08:23 |
|
mrpeters joined #evergreen |
| 08:31 |
|
phasefx joined #evergreen |
| 08:32 |
|
Shae joined #evergreen |
| 08:42 |
|
Dyrcona joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:54 |
|
akilsdonk joined #evergreen |
| 08:54 |
|
jwoodard joined #evergreen |
| 08:56 |
|
ericar joined #evergreen |
| 08:57 |
|
maryj joined #evergreen |
| 09:03 |
|
rjackson-isl joined #evergreen |
| 09:10 |
|
RoganH joined #evergreen |
| 09:13 |
|
julialima joined #evergreen |
| 09:20 |
Dyrcona |
Heh. I just used NCIPServer to place a hold for pickup at a certain library that could only be filled by a certain library on my dev server in order to test something totally unrelated to NCIP. |
| 09:21 |
kmlussier |
Dyrcona: Nice! |
| 09:22 |
|
RoganH joined #evergreen |
| 09:22 |
mrpeters |
reciept template fun! Re: https://bugs.launchpad.net/evergreen/+bug/1396307 -- is there a way (I know some javascript could probably do it, but I don't know if it would be merged into master) to have the row for %noncat_count% only display when the item(s) in question are of the noncat type? |
| 09:22 |
pinesol_green |
Launchpad bug 1396307 in Evergreen "Standalone - Nonbarcoded Checkouts " (affected: 1, heat: 6) [Wishlist,Triaged] |
| 09:25 |
mrpeters |
i would also say that it is a bug, not a wishlist, that the template doesn't properly account for the number of non-cat items checked out when the macro is already available |
| 09:25 |
jeff |
kmlussier: morning! |
| 09:27 |
kmlussier |
jeff: :) |
| 09:27 |
Dyrcona |
Yeah, it was the fastest way I could think of to place the hold: open a test script, edit two fields, and run it. |
| 09:27 |
Dyrcona |
Now, to experiment with suspending on shelf holds that have not been picked up.... |
| 09:29 |
|
yboston joined #evergreen |
| 09:31 |
|
julialima joined #evergreen |
| 09:34 |
tsbere |
mrpeters: I have ideas for how to handle some things, if you are using mozilla print |
| 09:35 |
mrpeters |
im looking at this as a way to fix for all, not just the reporter |
| 09:35 |
mrpeters |
i dont know the print strategy |
| 09:35 |
|
Callender_ joined #evergreen |
| 09:38 |
mrpeters |
we need template toolkit reciept templates or somethin :P |
| 09:39 |
tsbere |
mrpeters: With the "swap slip" codes you can say "if number of noncat checkouts is empty, swap out a different div" - If you want I can try and come up with a quick example for ya |
| 09:39 |
mrpeters |
but that would only fix mozilla print, right? |
| 09:40 |
mrpeters |
which, i suppose most people do use....but i'd feel like i only did a half ass job if only fixing one print strategy |
| 09:41 |
tsbere |
mrpeters: The alternative is "hard-code the language string" which some other variants already do... |
| 09:42 |
mrpeters |
i guess the question is, which one is more likely to get merged? |
| 09:43 |
tsbere |
mrpeters: The one more likely to be merged is the one where we actually change code. My swap slip trick is a "oh, you can do this in your templates" thing and isn't an actual change to code. |
| 09:43 |
mrpeters |
thats what i figured if i tried to do some javascript or something too |
| 09:45 |
|
mdriscoll joined #evergreen |
| 09:45 |
Dyrcona |
And, we ran out of cstore drones..... |
| 09:46 |
Dyrcona |
Makes me wonder if we're being spidered or if it is something in the update. |
| 09:46 |
tsbere |
mrpeters: I can tell you how to change things if you want. Not interested in doing so myself, mind you. ;) |
| 09:46 |
mrpeters |
no, im up for doing the work. i dont want to waste my time on something that will get rejected though. |
| 09:47 |
tsbere |
I have no idea how accepted it will be with the webclient stuff kicking around |
| 09:47 |
tsbere |
And no idea how to make the webclient support it, for that matter |
| 09:47 |
Dyrcona |
We bumped the config to 200 this time. We'll see if it happens again. |
| 09:47 |
mrpeters |
eh, true |
| 09:49 |
|
mllewellyn joined #evergreen |
| 09:50 |
|
BigRig joined #evergreen |
| 09:54 |
|
sandbergja joined #evergreen |
| 09:59 |
tsbere |
mrpeters: http://pastebin.com/pH3zxKcC |
| 10:00 |
mrpeters |
tsbere: are there other templates doing this? |
| 10:00 |
|
ericar joined #evergreen |
| 10:00 |
mrpeters |
(reading your article at http://masslnc.cwmars.org/node/2528 now) |
| 10:02 |
tsbere |
mrpeters: Er, I don't think stock templates do....but we have libraries that use it internally for some things. (note: I didn't test that code) |
| 10:02 |
mrpeters |
nah thats fine i understand it -- i just didn't know this functionality existed |
| 10:03 |
tsbere |
mrpeters: For example, making it so that a "short slip" prints out for specific shortnames is one of the primary reasons the "swap slip" exists - The entire main slip is discarded and an alternate used instead when the shortname matches |
| 10:03 |
mrpeters |
so, it looks at the value of the macro and decides whether or not to display the div? how is that happening? |
| 10:04 |
tsbere |
mrpeters: There is javascript code that runs in the receipt. There are ways to add to it as well, for that matter. |
| 10:05 |
mrpeters |
this is very cool, it does work (needs some tweaking -- still shows "Number of Non-Cataloged Items:" on the actual barcode checkout too |
| 10:05 |
tsbere |
mrpeters: see print_win.js in chrome/content/util/ |
| 10:05 |
mrpeters |
err, that could be becuase i put it in the template wrong |
| 10:06 |
tsbere |
mrpeters: Also a print_custom.js will be loaded if it exists (create a print_custom function to call the original *and* new ones you want to be able to use) and there is a library setting (print.custom_js_file) that can be filled with a similar file for more granular control. |
| 10:07 |
mrpeters |
alright, cool. you make a good point about web client's release approaching so ill just fix this in this one case with your solution, or maybe try and see what i can come up with and move on |
| 10:08 |
Bmagic |
We are using acq for the first time. When assigning copies to a branch and copy location, we are noticing that the availble copy locations are limited to only your workstation registered branch. What's up with that? |
| 10:11 |
jboyer-isl |
I didn't know print_custom.js would be loaded in standalone. (I suppose the setting is cached somewhere?) In that case, anyone bothered about them can change them extensively. |
| 10:12 |
jboyer-isl |
I even have some things they can use: http://loquaciousthesis.blogspot.com/2012/01/receipt-series-1-isnt-good-enough-good.html (There are 2-3 related posts, the linked print_custom.js file is the interesting bit) |
| 10:14 |
tsbere |
jboyer-isl: print_custom.js would be a "static" override. The OU setting variant would not work in standalone. |
| 10:16 |
jboyer-isl |
Then I misread what you were saying. :/ So it could be done, but would be more work. |
| 10:16 |
jboyer-isl |
Oops. |
| 10:16 |
tsbere |
jboyer-isl: Specifically, if you load print_custom.js into your system before you build and deploy staff clients you get it in standalone. ;) |
| 10:16 |
tsbere |
(which means if you keep it in the proper place in git you are generally going to be all set) |
| 10:17 |
|
RoganH joined #evergreen |
| 10:18 |
jboyer-isl |
That's interesting. A shame I'm only finding this out shortly before the whole thing changes. (I don't know what's coming with hatch, but that's where I'll probably start looking into this sort of thing) |
| 10:18 |
tsbere |
jboyer-isl: Further, the other documentation that mrpeters linked to is what happens without any custom files. |
| 10:20 |
jboyer-isl |
I tend to forget what can be done out of the box, especially as I'm so far removed from receipts now. :( |
| 10:20 |
tsbere |
jboyer-isl: I dislike your xf-Trim though. %-TRIM% and %TRIM-% trim spaces before or after the macro ;) |
| 10:22 |
jboyer-isl |
It does cause a bit of span spam, but I have never cared to make use of any whitespace, fore or aft. (As soon as you start to depend on it, then you start finding records that don't have it getting popular.) |
| 10:22 |
|
sarabee joined #evergreen |
| 10:22 |
Bmagic |
bshum: 1315038 is a duplicate of 1368754 I was just browsing and noticed |
| 10:22 |
tsbere |
jboyer-isl: %SOME_MACRO%%-TRIM% would remove all trailing whitespace from the output of %SOME_MACRO% |
| 10:22 |
mrpeters |
heh jboyer-isl you used to be the receipt guru!!! |
| 10:22 |
mrpeters |
everyone <3'd you ! |
| 10:24 |
* tsbere |
also prefers using the actual shelf expire time instead of adding days from today onto the receipt. With the actual shelf expire time you don't have a later date if someone has to re-print the receipt. |
| 10:25 |
jboyer-isl |
tsbere, yes, but if I used those I'd have always used %TRIM-%%WHATEVER%%-TRIM% just to be sure. As for the shelf expire time, I was having issues getting that macro to work when I last updated that file, I just never went back to it. |
| 10:25 |
jboyer-isl |
I definitely agree using the actual date is preferable these days. |
| 10:26 |
bshum |
Bmagic: Yeah that happens all the time :) |
| 10:26 |
jboyer-isl |
I don't remember if the trim macros existed when I wrote that file either, I had to get something going immediately after an upgrade and didn't have time to find much documentation. |
| 10:27 |
bshum |
Easy enough to mark a bug as duplicate, the important thing is making sure if there's any new facts or information that needs to be added to whichever bug becomes the primary one |
| 10:27 |
Bmagic |
bshum: one of those reports is mine, just thought I would tell someone that they need to be merged |
| 10:27 |
jboyer-isl |
Like most of my StakOverflow answers, I've not taken time to update old info. |
| 10:34 |
Dyrcona |
Bmagic bshum: Since the higher bug number is confirmed and the older still "new," I'd be inclined to mark the old as a duplicate. |
| 10:38 |
dbs |
I hate marking older bugs as dupes of newer bugs. |
| 10:39 |
bshum |
I usually go with the one with more confirmed "affects me" |
| 10:39 |
bshum |
Or has better written description. |
| 10:40 |
* bshum |
is in meetings, but will take a look afterwards, unless someone else gets there first. |
| 10:44 |
DPearl |
I think my posting from yesterday got lost in a MARC discussion. I will repost... |
| 10:45 |
DPearl |
I continue to have trouble getting my API routine "asset.move_attached_parts" to work. It seems to be OK up to a json_query to invoke a function in the database to do the work. The osrfsys.log does not contain any obvious errors, but the postgres log does have some complaints about something in the json_query process; needless to say, the db function is not executed. Is my json_query argument formed correctly? http://paste.ev |
| 10:47 |
eeevil |
DPearl: we missed the end of that pasted url |
| 10:48 |
mmorgan |
Here's the one from yesterday: http://paste.evergreen-ils.org/19 |
| 10:48 |
csharp |
Bmagic: I responded to your question on the Dev list before seeing it here |
| 10:48 |
Bmagic |
csharp: I read it, thanks for the reply |
| 10:48 |
dbs |
by way of explanation, I hate marking older bugs as dupes because it feels like rewriting history. |
| 10:48 |
Bmagic |
csharp: you are using acq? |
| 10:48 |
|
sandbergja joined #evergreen |
| 10:48 |
csharp |
Bmagic: we're in a test period with a planned go-live on a couple of libraries in early spring |
| 10:48 |
DPearl |
eeevil: Thanks |
| 10:49 |
csharp |
but, yeah, I've learned way more about acq than I wanted to :-P |
| 10:49 |
Bmagic |
csharp: And you plan on registering the appropriate users to the system level? |
| 10:49 |
DPearl |
mmorga++ |
| 10:49 |
csharp |
I think we're just making sure the acq perms are set to System level |
| 10:49 |
Bmagic |
csharp: we currently do not allow users to register at the system level |
| 10:49 |
DPearl |
mmorgan++ |
| 10:50 |
Bmagic |
csharp: the permissions are set to system, that doesn't seem to fix the copy locations UI issue |
| 10:50 |
csharp |
Bmagic: can users with the System level select the system as the context unit from a drop-down or something? |
| 10:51 |
* csharp |
doesn't use the UI, except when troubleshooting for our Acq person |
| 10:51 |
Bmagic |
csharp: that would be great, similar to the way tha the copy locations editor UI works, but no, didn't see that in the UI/xul |
| 10:52 |
csharp |
hmm |
| 10:52 |
Bmagic |
csharp: I am hesitant to report a bug because I can't believe that no body else is having this issue |
| 10:53 |
csharp |
Bmagic: yeah, a lot of acq bugs aren't being reported well IMHO - looks like the agencies using acq find workarounds without taking the extra step of a bug report |
| 10:53 |
csharp |
I'm trying to filter most of the complaints I'm aware of into bug reports |
| 10:53 |
bshum |
Or the workflows are just different. |
| 10:53 |
bshum |
:) |
| 10:54 |
csharp |
but so far, a lot of it comes down to config (which is poorly documented - or was last time I looked) |
| 10:54 |
csharp |
or like bshum says, differing workflows/expectations |
| 10:54 |
hopkinsju |
Bmagic: Have you reached out to Jennifer? |
| 10:55 |
Bmagic |
hopkinsju: lol, hi Justin from down the hall |
| 10:55 |
hopkinsju |
I'm joinging the conversation with people who aren't down the hall. Quit giving me a hard time! |
| 10:55 |
csharp |
jihpringle is definitely a big resource for us |
| 10:55 |
hopkinsju |
jihpringle++ |
| 10:56 |
hopkinsju |
She trained us on how to use it, but we aren't sure if any of her libraries are doing acq centrally. Given what we are seeing, I don't see how it could be done |
| 10:56 |
Bmagic |
no doubt! - I have not brought this paticular issue up with her yet, perhaps it's time |
| 10:56 |
csharp |
our Acq person is not usually on IRC but she would be a good person to talk to also |
| 10:56 |
hopkinsju |
Other than logging in/out every time they wanted to add another library's shelving location to a list. |
| 11:09 |
|
RoganH joined #evergreen |
| 11:10 |
|
wsmoak joined #evergreen |
| 11:13 |
kmlussier |
Bmagic: We have a lot of libs using acquisitions too. I don't know the answer to your question, but I do think many of our libraries upload most of their orders with the copy location information included in the holdings tag. |
| 11:14 |
kmlussier |
Bmagic: But you may have better luck sending that e-mail to the general list instead of the dev list since I expect most acq people aren't on the dev list. |
| 11:15 |
Bmagic |
kmlussier: I will do that! Thanks |
| 11:17 |
hopkinsju |
kmlussier: We're actually looking at this problem as it relates to creating funds IIRC |
| 11:17 |
hopkinsju |
The workaround that Blake's found is that you can make the same assignments by going through funding sources, but that seems like quite a bit more effort. |
| 11:18 |
hopkinsju |
It also doesn't help that the library in question has created a huge number of funds - more than the 50 that will display in the drop down. |
| 11:18 |
kmlussier |
This is all fuzzy in my brain, now, but I think we handled that by having the system own the funds instead of the branch. |
| 11:18 |
hopkinsju |
So, next question: Any idea why the drop down has an imposed limit of 50 items? |
| 11:19 |
hopkinsju |
How does that jive with branches all having the same or similarly named Shelving locations? |
| 11:19 |
kmlussier |
hopkinsju: It highly recommend that you contact somebody at C/W MARS. They have a library with a huge number of funds. |
| 11:20 |
* hopkinsju |
nods |
| 11:20 |
* kmlussier |
checks on the fund setup |
| 11:21 |
|
sandbergja joined #evergreen |
| 11:22 |
mmorgan |
Dpearl: I am not pretending to understand most of what's in your paste, but from the error message it looks like you're looking for a row in ccvm where the id is blank, so maybe a blank value for ccvm.id::TEXT is getting passed to the function? |
| 11:29 |
kmlussier |
hopkinsju: Is there an existing LP bug on that limit to 50 funds. It sounds familiar to me, but I'm not seeing anything |
| 11:45 |
|
graced joined #evergreen |
| 11:45 |
DPearl |
mmorgan: It does look that is a problem, but that is not my code; I think it is somewhere within json_query. I will have to delve in and try and figure that code out, unless someone could give me a pointer. |
| 11:46 |
DPearl |
mmorgan: The SELECT query in the osrflog seems to be mostly OK, and it does say that it was successful, but it is not successful: it never executes. I remain puzzled. |
| 11:46 |
hopkinsju |
kmlussier: I'm not ready to call it a bug since it's explicitly coded with the limit. I wanted to see if anyone else had thoughts about it before doing so. |
| 11:50 |
dbs |
osrFlog++ |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:28 |
|
nhilton joined #evergreen |
| 12:40 |
|
buzzy joined #evergreen |
| 12:57 |
|
nhilton_ joined #evergreen |
| 13:26 |
|
kmlussier joined #evergreen |
| 13:27 |
|
kmlussier_ joined #evergreen |
| 13:38 |
|
kmlussier joined #evergreen |
| 13:45 |
|
nhilton joined #evergreen |
| 13:50 |
|
artunit joined #evergreen |
| 13:50 |
|
rjackson-isl joined #evergreen |
| 13:51 |
|
sbrylander joined #evergreen |
| 13:56 |
kmlussier |
Hi all! The Evergreen for Acadmics meeting is scheduled to begin here in about 5 minutes. |
| 14:01 |
* RoganH |
exits stage left |
| 14:02 |
|
Christineb joined #evergreen |
| 14:03 |
kmlussier |
#startmeeting 2014-12-11 - Evergreen for Academics meeting |
| 14:03 |
pinesol_green |
Meeting started Thu Dec 11 14:03:22 2014 US/Eastern. The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:03 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:03 |
pinesol_green |
The meeting name has been set to '2014_12_11___evergreen_for_academics_meeting' |
| 14:03 |
kmlussier |
#info The meeting agenda is available at http://wiki.evergreen-ils.org/doku.php?id=evergreen_for_academics:2014-12-11 |
| 14:03 |
|
D0nB joined #evergreen |
| 14:03 |
kmlussier |
#topic Introductions |
| 14:04 |
kmlussier |
Please feel free to introduce yourselves with the #info command. |
| 14:04 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 14:04 |
yboston |
#info yboston is Yamil Suarez - Berklee College of Music |
| 14:04 |
mdriscoll |
#info mdriscoll is Martha Driscoll, NOBLE |
| 14:04 |
phasefx |
#info phasefx is Jason Etheridge - Equinox (and lurking) |
| 14:04 |
sandbergja |
#info sandbergja is Jane Sandberg, Linn-Benton Community College |
| 14:05 |
D0nB |
#info D0nB is Don Butterworth - Asbury Theological Seminary |
| 14:05 |
|
jck_ joined #evergreen |
| 14:06 |
jihpringle |
#info jihpringle is Jennifer Pringle, BC Libraries Cooperative |
| 14:06 |
kmlussier |
Welcome everyone! :) |
| 14:06 |
Christineb |
#info Christineb is Christine Burns, BC Libraries Cooperative |
| 14:06 |
kmlussier |
People can continue introducing themselves as they come in. |
| 14:07 |
kmlussier |
#topic Action Items fromthe Last Meeting |
| 14:08 |
kmlussier |
#info kmlussier sent an e-mail to the list to ask about academic PAC flavor ideas |
| 14:08 |
kmlussier |
I offered to take over that action item from yboston since he volunteered to step up for authorities. |
| 14:08 |
kmlussier |
#link http://markmail.org/message/ficcz33r4gb6ngwh |
| 14:09 |
kmlussier |
We did get some ideas for the Academic PAC flavor, but I have yet to incorporate them on the wiki page. |
| 14:10 |
kmlussier |
One concern I have is that the ideas are representative over the broader academic community using Evergreen. |
| 14:10 |
kmlussier |
There were several libraries who indicated they wanted to see an Academic PAC flavor on the survey. However, we aren't hearing from many of those libraries. |
| 14:11 |
kmlussier |
I'm just not sure how to reach out to those sites to get their feedback on the ideas. |
| 14:11 |
jck_ |
Do you know who the libraries are by name? |
| 14:12 |
kmlussier |
jck_: The ones who filled out the survey? |
| 14:12 |
yboston |
should we narrow are focus on one or two issues and send out another letter about it? just in case the narrower focus gets them interested |
| 14:12 |
yboston |
alternatively, we can find volunteers to reach out to those libraries to get feedback |
| 14:12 |
jck_ |
Yes, the libraries that indicated interest on the survey. |
| 14:12 |
kmlussier |
jck_: I can find that information. I can't remeber who they were off the top of my head. |
| 14:13 |
jck_ |
I can contact them if any were C/W MARS libraries. |
| 14:13 |
kmlussier |
We did get good feedback from Asbury, which is nice. I just don't know if their ideas are things a lot of other academics would like to see or not. |
| 14:13 |
dbs |
#info dbs is Dan Scott, Laurentian University |
| 14:13 |
kmlussier |
jck_: I think there may have been a couple. :) |
| 14:14 |
D0nB |
Everybody always like Asbury suggestions ;-) |
| 14:14 |
kmlussier |
I would say there was a lot of interest in the "Read More" feature D0nB recommended. But I think there's interest in seeing it done in the main PAC, so maybe we can file a wishlist bug for that. |
| 14:15 |
kmlussier |
So maybe jck_ and I can take an action item to follow up directly with some academics who showed interest in this work? |
| 14:16 |
yboston |
I defiently expect that some of the changes that we identify in this group will end up just being default changes fro EG going forward; or just become features that just need to eb turned on |
| 14:16 |
kmlussier |
#action jck_ and kmlussier to follow up directly with libraries that showed interest in an academic PAC flavor. |
| 14:17 |
kmlussier |
yboston: Yes, and that might be a better approach than the academic flavor approach. |
| 14:17 |
jck_ |
kmlussier: Okay |
| 14:18 |
kmlussier |
#mdriscoll sent a message to Evergreen list to get feedback on requirements for batch patron load and for batch batch patron updates/deletes through patron buckets |
| 14:18 |
kmlussier |
Bah! Let me try that again. |
| 14:18 |
kmlussier |
#info mdriscoll sent a message to Evergreen list to get feedback on requirements for batch patron load and for batch batch patron updates/deletes through patron buckets |
| 14:18 |
kmlussier |
#link http://markmail.org/message/nfxovop3xxerxs33 |
| 14:19 |
kmlussier |
mdriscoll: Do you have anything you want to report on that? |
| 14:19 |
mdriscoll |
I got a lot of feedback which I have incorporated into the wiki page |
| 14:19 |
yboston |
Another approach is that we end up with "example" Academic TPAC templates, like there are currently "example" cron files or example OSRF config files in the intalation file for libraries to use as starter values as they customize their local system |
| 14:20 |
mdriscoll |
One person said the functions would be of interest to a public library. Certainly batch update and delete would be. |
| 14:20 |
kmlussier |
yboston: Yes, that was my thought on the way to go with the academic flavor route. Files in a template directory. |
| 14:21 |
kmlussier |
#link http://wiki.evergreen-ils.org/doku.php?id=evergreen_for_academics:batch_patron_functions |
| 14:21 |
phasefx |
possibly related low-hanging fruit might be patron buckets.. the infrastructure exists, just no UI for it |
| 14:21 |
kmlussier |
mdriscoll: I agree it could be useful for a lot of libraries. |
| 14:21 |
yboston |
phasefx: +1 |
| 14:22 |
kmlussier |
phasefx: That's good to know. |
| 14:22 |
jck_ |
phasefx: +1 |
| 14:22 |
mdriscoll |
phasefx: +1 |
| 14:22 |
kmlussier |
mdriscoll: Do you feel like the requirements are in a semi-finished state or do you think they need more time for feedback? |
| 14:22 |
yboston |
mdriscoll++ good job updating the wiki |
| 14:23 |
kmlussier |
mdriscoll++ indeed |
| 14:23 |
mdriscoll |
There are probably some more tweaks to do, but I think its a good start. |
| 14:24 |
kmlussier |
It looks like there are a couple of outstanding questions in there too. |
| 14:24 |
mdriscoll |
Galen mentioned patron addresses and its still an unanswered question of how many addresses to provide for. |
| 14:24 |
* kmlussier |
will try to give some thought to those questions before the week ends. |
| 14:25 |
jck_ |
I think most of C/W MARS patron records have 1 or 2 addresses. |
| 14:26 |
mdriscoll |
I vote for 2 addresses because that's what I do. I don't know if anyone would need more, but it seems like providing for more than one is a good idea. |
| 14:26 |
kmlussier |
Yeah, I was thinking that 2 was a good number. |
| 14:26 |
jck_ |
I agree on 2 addresses. |
| 14:26 |
jihpringle |
two addresses sounds good to me |
| 14:27 |
yboston |
I assume it would be OK to only have 1 address? |
| 14:27 |
kmlussier |
yboston: yes |
| 14:27 |
kmlussier |
It sounds like we have a consensus here. |
| 14:28 |
kmlussier |
mdriscoll: Can you expand on your authorization question? |
| 14:28 |
mdriscoll |
I'll update the wiki and say 2 addresses. If anyone objects, they can speak up. |
| 14:28 |
mdriscoll |
I mean permissions to update/delete the records. Can you update records that don't "belong" to your library. |
| 14:29 |
kmlussier |
mdriscoll: I'm thinking it should be done in a similar fashion as the patron update permissions. |
| 14:30 |
kmlussier |
But my question is: do we want a separate permission to handle a batch of patron updates/deletes or should it just be tied to the current permissions for updating/deleting patron records? |
| 14:31 |
jck_ |
A separate permission for batch updates and actually a separate permission for batch deletes would be safest. |
| 14:32 |
jihpringle |
agreed |
| 14:32 |
mdriscoll |
I would have to think of some use cases. In our situation, a public library patron can be edited by other public libraries. That could be more permission than is safe in a batch function. |
| 14:32 |
mdriscoll |
jck_: agreed |
| 14:32 |
kmlussier |
Yes, of course. I was forgetting that. So more reasons for the separate permission. |
| 14:33 |
kmlussier |
OK, I'm going to move on to other past action items now, but maybe later we can talk briefly about what we do with these requirements now that we have them. :) |
| 14:33 |
kmlussier |
Overall, I think they look really good. |
| 14:33 |
kmlussier |
mdriscoll++ |
| 14:34 |
kmlussier |
yboston: I have an action item that you would take charge of the authorities group. But I don't know if there were any real "actions" related to that item. |
| 14:34 |
kmlussier |
Do you have anything to report or should I just move on to the next action item? |
| 14:34 |
yboston |
I did write a tiny little bit of authorities code, but I have not shared the branch so I can get feedback yet |
| 14:35 |
yboston |
I will do it by next week |
| 14:35 |
kmlussier |
OK. |
| 14:35 |
kmlussier |
#action yboston to share authorities code he has been working on. |
| 14:36 |
kmlussier |
#info D0nB identified reaining LC Call Number issues and reported back to the group. |
| 14:36 |
kmlussier |
#link http://markmail.org/message/ppf4dmovfjy2lw4j |
| 14:36 |
kmlussier |
D0nB: Do you have anything to add on that front? |
| 14:36 |
D0nB |
Not particularly |
| 14:37 |
D0nB |
Response from the group at large was pretty small |
| 14:37 |
D0nB |
Not sure if there is little interest |
| 14:38 |
D0nB |
But there is a big list of tweaks that can be worked on by programmer types |
| 14:38 |
kmlussier |
D0nB: It's hard to say. I don't think we've heard that call numbers have been a particularly thorny issue for our libraries. But there was some interest on that survey that went out. |
| 14:38 |
D0nB |
Anybody have any questions? |
| 14:39 |
D0nB |
What little feedback I have gotten I'll get on the wiki |
| 14:40 |
kmlussier |
D0nB: Just a thought. One way to get those tweaks in the direct line of sigh for those proramer types is to file LP bugs on the problems. |
| 14:40 |
kmlussier |
I know there are already some bugs reported, but I think some may be new too. |
| 14:40 |
D0nB |
OK |
| 14:40 |
* kmlussier |
will move on to the next action item. |
| 14:40 |
yboston |
We have had plenty of small issues, though I have had hard a time explaining our issues since I am not a cataloger and we have a brand new cataloger |
| 14:41 |
D0nB |
I am an experienced cataloger |
| 14:41 |
D0nB |
Just let me know how/if I can help |
| 14:41 |
kmlussier |
yboston: Maybe when the new cataloger is up to speed, they can help explain them. |
| 14:42 |
yboston |
that is what I hope to do |
| 14:42 |
kmlussier |
#info posted testing feedback for bug 1389403 and has signed off on it. |
| 14:42 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:42 |
yboston |
kmlussier++ |
| 14:43 |
kmlussier |
OK, moving on to new business, I think we covered most updates during the action item updates. |
| 14:43 |
yboston |
quick question |
| 14:43 |
kmlussier |
Sure, go ahead. |
| 14:43 |
yboston |
can that patch be a candidate for being backposrted to older versions of EG? |
| 14:43 |
yboston |
*backported |
| 14:44 |
kmlussier |
yboston: I think it's up to the release maintainers, but I would think so. It's a bug fix, not a new feature. |
| 14:44 |
yboston |
I plan to ask ESI to load it on our 2.6 server anyway, but I wanted to bring it up for the sake of others |
| 14:44 |
kmlussier |
dbwells may be a better person to answer that question, though. |
| 14:44 |
yboston |
is bshum the release manager of 2.6? |
| 14:45 |
kmlussier |
Actually, the milestone on the bug is 2.7, which is a backport. |
| 14:45 |
yboston |
no, he is 2,7 I beleive |
| 14:45 |
kmlussier |
bshum is the 2.7 release maintainer. dbwells is 2.6 |
| 14:45 |
yboston |
thanks |
| 14:46 |
kmlussier |
Although we've had updates for the sub-groups, I think it's worthwhile to discuss some next steps, especially for something like patron loading, which seems to be in very good shape. |
| 14:46 |
kmlussier |
#topic Next steps for projects |
| 14:46 |
kmlussier |
Now that we have some solid requirements for one of the projects, where do we go from here? |
| 14:48 |
kmlussier |
Are there institutions interested in funding the projects? Or does somebody want to take the next step to see how much interst there is in the community to fund it? |
| 14:48 |
kmlussier |
This question could also be directed towards any of the other projects we've been discussing. |
| 14:49 |
mdriscoll |
It would be interesting to know what kind of cost something like this would be. That may affect interest in funding it. |
| 14:50 |
kmlussier |
Sure. |
| 14:50 |
mdriscoll |
How does the web client development affect something new like this? |
| 14:50 |
kmlussier |
Given what phasefx said about the patron bucket infrastructure being there, I also wonder if that's a good project to start with. |
| 14:51 |
kmlussier |
Or maybe it's better to look at all of it at once. |
| 14:51 |
yboston |
mdriscoll: that is an excellent question |
| 14:51 |
kmlussier |
mdriscoll: Given that this is related to patrons, I think it would have to be developed for the web client since patron functionality has already been ported over. |
| 14:51 |
eeevil |
(sorry to butt in, but...) regarding cost (and reducing it), ESI wrote a student/faculty info loader for UPEI long ago and then updated it to work with the core staging schema (when that happened)... you may want to reach out to them. I think my copy of the code was lost with SVN :( |
| 14:52 |
jck_ |
Buckets can have limits to the number of updates that can be done efficiently so we should identify if that will be a limitation. |
| 14:52 |
jihpringle |
I'd be interested in seeing mock-ups of what we want the user interfaces to look like (thinking of the patron batch loading) |
| 14:52 |
kmlussier |
eeevil: But is it available in the client? |
| 14:52 |
eeevil |
kmlussier: it was completely automated, no staff interface required. insert and update as needed |
| 14:53 |
kmlussier |
eeevil: I think most of the academics here have some kind of script, but are looking at building it into the client to make it easier for libraries to handle their own updates. |
| 14:53 |
eeevil |
ah, well, I'll step back then :) |
| 14:53 |
phasefx |
jck_: buckets as exposed in the current xul client have limitations, but new code could be written server-side to bypass those |
| 14:53 |
kmlussier |
eeevil: No, that's fine. It's always best to know that we aren't missing something that's already there. |
| 14:54 |
jeffdavis |
It might be worth looking at some of the different custom patron batch load tools to see the range of desired features, but I thought mdriscoll did a great job of accounting for a lot of considerations. |
| 14:54 |
phasefx |
jck_: in other words, do batch edits on the server rather than in the client, implementation-wise |
| 14:54 |
jck_ |
phasefx: Thanks. I was thinking buckets on the client side. |
| 14:55 |
|
Christineb left #evergreen |
| 14:55 |
kmlussier |
mdriscoll: I'm looking at the performance section for the patron loader. It might be nice to have a similar section for the buckets. |
| 14:55 |
mdriscoll |
jeffdavis: that would be interesting! |
| 14:55 |
mdriscoll |
kmlussier: I'll add that. |
| 14:55 |
yboston |
BTW, I would be OK to continue to use a non-GUI batch import solution, if it has some/most of the features we have put up on the wiki list |
| 14:56 |
yboston |
also, there is often some limitaton to using GUI tools, like a mximun number of students that can be batched at once |
| 14:56 |
eeevil |
yboston: the reason I raised the UPEI code is that it covers things like statcats and addresses (including updates to both) ... fwiw. but, no user UI |
| 14:57 |
yboston |
it would be great if there was a singular back end logic that could be tapped irregardless if one uses a GUi batch loader versus a GUI tool |
| 14:57 |
mdriscoll |
I have had academic IT staff ask me if we had a web interface to send the records to. A hands-off solution is not out of the question. |
| 14:57 |
mdriscoll |
eeevil: statcats++ |
| 14:57 |
yboston |
mdriscoll: good to know |
| 14:57 |
kmlussier |
Would somebody be interested in taking an action item to gather the scripts that are already being used? |
| 14:57 |
jeffdavis |
kmlussier: I'll do that. |
| 14:58 |
kmlussier |
jeffdavis++ |
| 14:58 |
mdriscoll |
jeffdavis++ |
| 14:58 |
yboston |
jeffdavis++ |
| 14:58 |
|
alynn26 joined #evergreen |
| 14:58 |
kmlussier |
#action jeffdavis to put out a call for current patron loading scripts that are already in use. |
| 14:58 |
jeff |
jeffdavis++ |
| 14:58 |
kmlussier |
What about the mock-ups jihpringle mentioned? Do we want to work on those? |
| 14:59 |
* kmlussier |
notes that we're quickly reaching the one-hour mark. |
| 14:59 |
mdriscoll |
Maybe wait for the scripts to make sure we have the feature set complete? |
| 14:59 |
yboston |
which mock-ups are those? |
| 14:59 |
kmlussier |
yboston: jihpringle had said it might be good to see make some mock-ups of what we would like to see in the client for the patron loader. |
| 15:00 |
kmlussier |
But waiting on the feature set works for me too. |
| 15:00 |
kmlussier |
OK, it sounds like we have some next steps for these projects. |
| 15:00 |
jihpringle |
we also may want to do a mockup of an academic flavoured pac |
| 15:00 |
kmlussier |
Does anyone have any other topics they would like to bring up? |
| 15:01 |
kmlussier |
jihpringle: D0nB has created a mock-up for the pac. |
| 15:01 |
kmlussier |
It would be good, though, to make sure we have some consensus on what an academic pac means. |
| 15:02 |
|
sandbergja left #evergreen |
| 15:02 |
D0nB |
I think it would be great if others would try their hand at a mockup |
| 15:03 |
D0nB |
Given the "read more" comments, I would want to revise my original try |
| 15:03 |
kmlussier |
Does anybody want to work on that? |
| 15:03 |
* kmlussier |
feels like she needs feedback from more libraries before trying to create anything. |
| 15:04 |
kmlussier |
Well, let's leave it as a task that's available for anyone who has the tuits. |
| 15:05 |
kmlussier |
Any other comments before I end the meeting? |
| 15:05 |
yboston |
I would focus for a bit on the |
| 15:05 |
yboston |
title versus copy holds |
| 15:05 |
yboston |
issues of the PAC. |
| 15:06 |
yboston |
That is what I think a good area that will need a toggle switch |
| 15:06 |
kmlussier |
A toggle to do what? |
| 15:06 |
yboston |
turn it on or off |
| 15:06 |
yboston |
or is there such a thing already and we only need better documentation? |
| 15:07 |
kmlussier |
I could be wrong, but I think you just need to give the right permission to patron to surface the volume/copy holds in the pac. |
| 15:07 |
* kmlussier |
hasn't tested it, though. |
| 15:07 |
dbs |
it's hard-coded right now as staff-only |
| 15:08 |
kmlussier |
dbs: OK, thanks for correcting me then. |
| 15:08 |
yboston |
dbs: thanks |
| 15:08 |
kmlussier |
Maybe I'm thinking of jspac |
| 15:08 |
dbs |
around line 160 of Open-ILS/src/templates/opac/parts/record/copy_table.tt2 "IF ctx.is_staff" |
| 15:08 |
kmlussier |
I'm going to wrap up the meeting now, but we can continue discussions if we want to. |
| 15:08 |
kmlussier |
#endmeeting |
| 15:08 |
pinesol_green |
Meeting ended Thu Dec 11 15:08:54 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:08 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-12-11-14.03.html |
| 15:08 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-12-11-14.03.txt |
| 15:08 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-12-11-14.03.log.html |
| 15:09 |
yboston |
kmlussier++ |
| 15:09 |
kmlussier |
dbs: So you basically would just need to remove that part if you wanted to display copy holds for your system? |
| 15:09 |
dbs |
Making it a toggle would seem to be fairly easy, yep |
| 15:09 |
dbs |
(but you would have to add permissions) |
| 15:10 |
kmlussier |
dbs: Fairly easy for some. :) |
| 15:10 |
dbs |
I'll do it for a bazillionty dollars! |
| 15:10 |
yboston |
I'll do it for 1/2 of that |
| 15:10 |
yboston |
actually, I will look into it |
| 15:10 |
kmlussier |
dbs: Can I just send you some bills from my Monopoly game? |
| 15:11 |
yboston |
though I will defer to what the more expereinced programmers woudl think is a more elegant solution |
| 15:11 |
bshum |
"Working code wins" |
| 15:12 |
dbs |
yboston: step 1 would be to add a config.tt2 variable like "enable_patron_copyvol_holds"; then "IF ctx.is_staff OR enable_patron_copyvol_holds;" instead of "IF ctx.is_staff" |
| 15:12 |
dbs |
for bonus points, make it a YAOUS instead of config.tt2 variable. |
| 15:13 |
yboston |
I was prepping a YAOUS joke, but you beat me to it |
| 15:13 |
dbs |
but it looks like it's just a three-line code change if you go the config.tt2 route (need to do the same for search results as in record details) |
| 15:13 |
yboston |
(Yet another Organization Unit Setting) |
| 15:13 |
yboston |
OK |
| 15:14 |
yboston |
there are so many ways to achive the effects of an Academic PAC |
| 15:14 |
kmlussier |
dbs: But that doesn't handle the permissions piece of it, does it? |
| 15:14 |
yboston |
a lot of YAOUS is a way, or just "example" tempaltes |
| 15:15 |
dbs |
kmlussier: nope, but that's "just" documentation :) |
| 15:15 |
yboston |
what permission part, there is a permission to allow these holds that needs turnign on? |
| 15:15 |
dbs |
Staff need permission to place copy / vol holds too, so it's just an extension of that |
| 15:16 |
kmlussier |
Oh, see I was thinking of permissions in that you wouldn't want to display the place copy hold link if somebody did have permission to do it. |
| 15:16 |
dbs |
VOLUME_HOLDS and COPY_HOLDS |
| 15:17 |
dbs |
oh, well then you would have to be logged it to determine whether or not the link should be shown |
| 15:18 |
kmlussier |
dbs: Yes, of course. You're right. |
| 15:18 |
dbs |
There's already logic to control visibility based on whether the items / copy locations themselves allow holds, so that's nice at least |
| 15:20 |
kmlussier |
dbs++ |
| 15:20 |
yboston |
I can see an academic library wanting the links to (almost) always show without being logged in, though I assume the patron would be prompted to log in once the lcick on the holds link |
| 15:20 |
yboston |
I bet my library would want that |
| 15:21 |
kmlussier |
yboston: Yes, I agree. I just wasn't thinking clearly. |
| 15:21 |
kmlussier |
yboston: I'm curious, though. What is the advantage of patrons being able to place copy holds over title holds? |
| 15:22 |
dbwells |
yboston: kmlussier: I have targeted bug #1389403 at 2.6.5. We've run it on our 2.6 system with no ill effects. |
| 15:22 |
yboston |
just like what Don was mentioning |
| 15:22 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 15:22 |
kmlussier |
dbwells++ |
| 15:22 |
yboston |
dbwells++ |
| 15:24 |
yboston |
kmlussier: when there are items that have seprate volues. Like the a multi disc set of COlumbia records, and you only want to olace a hold on disc 7 (if I recall correctly) |
| 15:24 |
kmlussier |
OK. We use parts for that. |
| 15:25 |
jihpringle |
kmlussier: sorry, had to step away to answer a call from a library - I'd be happy to try my hand at creating some mockups but won't have time until January |
| 15:26 |
kmlussier |
jihpringle: Sounds good. |
| 15:27 |
kmlussier |
yboston: Overall, I think you're right that some of these academic PAC flavor topics can be handled by adding configuration options. |
| 15:28 |
kmlussier |
I think what we're surfacing aren't precisely "academic" issues, but issues of handling different uses of the system. So the copy-level holds issues isn't so much an "academic" issue but one needed by libraries that don't use parts. |
| 15:28 |
kmlussier |
All of our academics are members of consortia, and copy-level holds don't work as well in that environment. |
| 15:30 |
|
asimon joined #evergreen |
| 15:31 |
|
sandbergja joined #evergreen |
| 15:31 |
|
sandbergja left #evergreen |
| 15:32 |
asimon |
The following error appears in the osrfsys.log file when the system tries to send an email notice: SendEmail Reactor: unable to send email: $VAR1 = bless( {'prop' => {},'string' => 'Can\'t send data','type' => 'failure','errno' => 1}, 'Return ::Value' ); What do I need to change to correct this error? |
| 15:37 |
|
RoganH joined #evergreen |
| 15:39 |
dbs |
kmlussier / yboston: Yeah, the big problem with exposing copy & volume holds is that a user might inadvertently place a copy hold when they really just want a title hold. |
| 15:39 |
kmlussier |
RoganH: If I knew it only took an Evergreen for Academics announcement to chase you out of the #evergreen channel, I would have started scheduling these meetings long ago. ;). |
| 15:39 |
dbs |
That's why I generally agree with parts as the solution for the "But I want Volume X of the Encyclopedia!" problem |
| 15:39 |
RoganH |
kmlussier: It was only a red herring, I lurked anyway. I can't give you satisfaction that easily. :) |
| 15:40 |
dbs |
I can't even get our cataloguers to do parts, though :/ |
| 15:40 |
* kmlussier |
is sure she can come up with something else. |
| 15:40 |
RoganH |
dbs: I can't get mine too either. |
| 15:40 |
kmlussier |
dbs / RoganH: May I ask what's behind the reluctance to use parts? |
| 15:40 |
* RoganH |
thinks kmlussier will try but Calvin from Calvin and Hobbes is his spirit animal. |
| 15:41 |
RoganH |
kmlussier: in my consortium's case I think it's just inertia |
| 15:41 |
* dbs |
is with RoganH |
| 15:41 |
dbs |
Maybe I'll use our upgrade to 2.7 to force part adoption |
| 15:41 |
dbs |
@karma parts |
| 15:41 |
pinesol_green |
dbs: Karma for "parts" has been increased 29 times and decreased 28 times for a total karma of 1. |
| 15:42 |
RoganH |
lol |
| 15:42 |
* kmlussier |
has been giving positive karma to parts in IRC off hours. |
| 15:43 |
kmlussier |
And mmorgan has been helping me. |
| 15:43 |
collum |
parts add a little bit of overhead, but somehow I convince our catalogers that it was worth it. |
| 15:44 |
kmlussier |
collum: Overall, have you been happy with parts? |
| 15:44 |
kmlussier |
All joking about parts karma aside, I am truly interested in what can be done to make parts work better for everyone. |
| 15:45 |
collum |
Yep. |
| 15:45 |
collum |
At first all of the catalogers could delete parts, but now it's me and one other catalogers. |
| 15:46 |
collum |
That way I avoid a lot of the orphan problem. |
| 15:46 |
bshum |
collum: It'll get better once you get on a version that allows part merging. It's swanky. |
| 15:46 |
bshum |
That said, parts-- |
| 15:46 |
collum |
cool |
| 15:46 |
bshum |
And parts++ |
| 15:46 |
kmlussier |
bshum: Ha! |
| 15:47 |
kmlussier |
collum: We're hoping to fix the problem that happens when parts with holds are deleted. |
| 15:47 |
kmlussier |
Just need to get some quotes to get moving on that one. |
| 15:47 |
bshum |
kmlussier: Do any of your people work with Brodart for acq EDI? (Or anyone else out there for that matter...) |
| 15:48 |
bshum |
By your people, I meant the consortiums you work with. :) |
| 15:48 |
csharp |
@who is one of YOUR PEOPLE? |
| 15:48 |
pinesol_green |
BigRig is one of YOUR PEOPLE. |
| 15:49 |
kmlussier |
bshum: I don't think so, but I could be wrong. |
| 15:50 |
BigRig |
Not I |
| 15:50 |
* kmlussier |
supposes she could check. |
| 15:53 |
|
kmlussier1 joined #evergreen |
| 15:53 |
|
kmlussier1 left #evergreen |
| 15:57 |
bshum |
I guess the thing I'm trying to solve is http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/950.data.seed-values.sql;h=ba59c4b816089d1a1305fa72a716c8ba36563cce;hb=HEAD#l8874 |
| 15:58 |
bshum |
8874 of the seed data template describes a block for if the VENDOR_BRODART is used, and it'll look for something called the Spec Code from the lineitem_details.note field. |
| 15:58 |
bshum |
But I'm not sure this actually gets passed up to anything |
| 15:58 |
bshum |
Or it is put into ftx_vals I guess? |
| 15:58 |
bshum |
And then that's supposed to be called up in the free-text block in the next area |
| 15:59 |
bshum |
But I don't see anything like that in sample orders we're sending. The free-text block ends up being empty. |
| 15:59 |
bshum |
This is weird PO JEDI template stuff I guess. |
| 15:59 |
bshum |
Specific to Brodart, but just learning the in's and out's |
| 16:14 |
|
akilsdonk joined #evergreen |
| 16:17 |
kmlussier |
Ha ha. I'm looking at the FB photo of eeevil talking to his daughter's class and can't help but wonder if that boy in the back is sleeping. |
| 16:17 |
berick |
kmlussier: you mentioned the other day there was going to be an EG conf planning meeting. (for yesterday, i think). do you know if anything came of that as far as registration dates or any other useful info? |
| 16:18 |
kmlussier |
berick: Yes, buzzy should be sending out an e-mail soon with dates. |
| 16:18 |
berick |
kmlussier: awesome, thanks |
| 16:18 |
kmlussier |
But I'm responsible for the registration form and plan to have it up by the end of the month at the latest. |
| 16:18 |
kmlussier |
But it will probably be sooner. |
| 16:18 |
berick |
even better, thanks |
| 16:19 |
* kmlussier |
should go work on that now instead of looking at the ESI FB page. |
| 16:20 |
eeevil |
kmlussier++ # but, no, they all stayed awake. barely. |
| 16:21 |
kmlussier |
eeevil: I'm sure you did a great job. Are any of them ready to work on Evergreen yet? |
| 16:24 |
|
ericar joined #evergreen |
| 16:25 |
|
jwoodard joined #evergreen |
| 16:27 |
|
AliceR joined #evergreen |
| 16:28 |
|
AliceR joined #evergreen |
| 16:33 |
eeevil |
kmlussier: I'm trying to convince their teacher to use angularjs tutorials, but not yet ;) (j/k... maybe) |
| 16:34 |
* kmlussier |
should take an angularjs tutorial |
| 16:50 |
|
AliceR joined #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 17:11 |
|
mdriscoll left #evergreen |
| 17:12 |
jeff |
one solution to "large print edition sometimes shows first in search results and lots of people put holds on it, and not the regular print edition with dozens of copies": display-time appending of " (LARGE PRINT)" to titles. |
| 18:17 |
bshum |
jeff: Do you think that's easier in 2.6+ with the new format icons? |
| 18:19 |
|
RBecker joined #evergreen |
| 20:06 |
|
artunit joined #evergreen |
| 21:53 |
jeff |
bshum: i don't know yet. |
| 21:53 |
jeff |
bshum: maybe both. |
| 21:54 |
jeff |
it's a bit of an experiment for now, and we won't be on anything greater than 2.5 for a month or more. |
| 21:56 |
jeff |
previous to this change, the only clue in our catalog on the initial search result page was that the call number often started with "LP" |
| 21:57 |
jeff |
i'm still keeping an eye out for (and considering running some additional queries to find) examples where the current criteria i'm using are getting either false positives or false negatives. |
| 21:58 |
jeff |
current criteria: https://github.com/tadl/Evergreen_templates_tadlskin/commit/28cedb7d1a2f475d69ebeb09771a80e96d87759f |
| 22:06 |
kmlussier |
jeff: That very problem was one of the reasons (among others) that we wanted to see the new icons. |
| 22:06 |
kmlussier |
I haven't heard from anyone yet if they've seen a reduction in those holds since moving to 2.6+ |
| 22:22 |
jeff |
kmlussier: looks like this for us in production: https://catalog.tadl.org/eg/opac/results?query=fault+in+our+stars&qtype=keyword&locg=22 |
| 22:23 |
kmlussier |
jeff: That's pretty clear |
| 23:55 |
|
RBecker joined #evergreen |
