| Time |
Nick |
Message |
| 04:02 |
|
geoffsams joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:54 |
|
mrpeters joined #evergreen |
| 07:48 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
rjackson_isl joined #evergreen |
| 08:17 |
|
ericar joined #evergreen |
| 08:49 |
|
mmorgan joined #evergreen |
| 08:59 |
kmlussier |
berick: I was planning to review/probably merge bug 1312699 since Stompro signed off on it this week. Should I hold off now in light of bug 1527342 ? |
| 08:59 |
pinesol_green |
Launchpad bug 1312699 in Evergreen "Editable Checkout History" [Wishlist,Triaged] https://launchpad.net/bugs/1312699 |
| 08:59 |
pinesol_green |
Launchpad bug 1527342 in Evergreen "Maintain patron reading history in a dedicated table." [Wishlist,New] https://launchpad.net/bugs/1527342 - Assigned to Bill Erickson (berick) |
| 09:33 |
|
yboston joined #evergreen |
| 09:41 |
|
maryj joined #evergreen |
| 10:09 |
berick |
kmlussier: i'm a conflicted, but ultimately prefer we not merge it. the UI parts of that code will be useful w/ my proposed changes. all the SQL and other plumbing would have to be ripped back out, though. |
| 10:09 |
berick |
s/a// |
| 10:10 |
berick |
other considerations are that my code will almost certainly not make the 2.9 cut. |
| 10:11 |
berick |
and so far I've only received feedback from jboyer-isl on my move-to-another-table proposal (via #1497335) |
| 10:11 |
kmlussier |
berick: OK. I had been thinking it might make the 2.9, errr 2.10 cut, but if you don't think it will, I would be inclined to merge it. |
| 10:11 |
kmlussier |
berick: I'll get feedback to you before I take off next week. :) |
| 10:12 |
berick |
kmlussier++ |
| 10:12 |
kmlussier |
I was just reading up on it this morning. |
| 10:14 |
berick |
hmm, i would really like to see us agree on some rough code poliices re: column widths. 239-character wide lines make me twitchy. |
| 10:15 |
jboyer-isl |
kmlussier, berick: something else to keep in mind is that the mechanisms behind a feature don’t have to be static or even particularly long-lived. If the existing patch helps patrons and isn’t too large, it can always be replaced, even in the next release. (so long as user-facing changes aren’t too large either.) |
| 10:16 |
jboyer-isl |
If it has to make a ton of changes in a lot of places though, I’d say berick |
| 10:16 |
jboyer-isl |
’s plan is the “right” one in the long run. |
| 10:16 |
|
Shae_ joined #evergreen |
| 10:16 |
berick |
i'm hoping if we merge, there will be no need for user facing changes. it will all be plumbing. |
| 10:16 |
jboyer-isl |
(which would mean don’t merge the existing, I’m having trouble English-ing today.) |
| 10:17 |
jeff |
berick: i'd support kicking a change back for cleanup if it had long line lengths like that, even absent any formal guide |
| 10:17 |
|
Shae_ joined #evergreen |
| 10:18 |
jeff |
berick: I'd be less happy to see a mass-cleanup set of commits all over the place, but in the case of code that you're looking to change, a pre-change cleanup commit limited to the affected context? |
| 10:18 |
kmlussier |
Huh, I thought was had a standard for line widths. But I'm not seeing it. |
| 10:18 |
|
Shae_ joined #evergreen |
| 10:19 |
jeff |
Avoiding "single commit that implements a change and a line length cleanup" is probably good also. |
| 10:20 |
berick |
if anyone's curious, i'm talking about 2nd to last file changed in http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=7c325b27634765f77b41f5b892b119cc602ce260 |
| 10:20 |
kmlussier |
berick / jboyer-isl: Yeah, my opinion is based on the fact that the editable checkout just barely missed the 2.9 cutoff because of a problem in the upgrade script. I hate making people wait another release for a feature once it's working as expected. |
| 10:20 |
berick |
jeff: yeah, agreed we don't want to mix cleanup and changes |
| 10:23 |
berick |
kmlussier: i'm OK with merging. really it will just mean dropping a column |
| 10:23 |
berick |
one of the functions changed in the commit will get dropped in my proposed code |
| 10:23 |
berick |
sql functions, that is |
| 10:24 |
berick |
and we'll have to check the hide_from_usr_history value as part of the migration to the new table, but that's easy enough |
| 10:25 |
kmlussier |
berick++ #Thanks! |
| 11:03 |
|
sarabee joined #evergreen |
| 11:19 |
* tsbere |
wonders if anyone in the community would want his oclc number monitoring code >_> |
| 11:20 |
Stompro |
tsbere, I would love to see it. |
| 11:24 |
* tsbere |
goes ahead and reviews some of it for purposes of "did I hardcode anything sensitive?" |
| 11:28 |
tsbere |
Stompro: http://pastebin.com/UPtzNTw7 |
| 11:33 |
jeff |
Ahh OCLC. Such conflicted feelings. |
| 11:34 |
jeff |
I can't get them to return my inquiries for EZproxy support pricing. |
| 11:34 |
tsbere |
jeff: I am hoping we skip EZproxy and just go with some of my apache module stuff. >_> |
| 11:35 |
* jeff |
nods |
| 11:38 |
tsbere |
Hmmm. Apparently I missed a trigger function. |
| 11:38 |
* tsbere |
goes to update his paste with that |
| 11:39 |
tsbere |
Stompro: I just added a trigger I had forgotten about to the paste there, if you were already looking. |
| 11:44 |
|
Christineb joined #evergreen |
| 11:45 |
jboyer-isl |
So we don’t go chasing a wild goose down a rabbit hole, is there any reason the “Last Receipt” function in standalone should not work normally? We’re getting reports of an error for util.print.simple on line 387 of JSAN.js. If it’s known not to work we’ll drop it, otherwise we’ll start digging. |
| 11:49 |
tsbere |
We use standalone so infrequently I have no clue one way or the other. |
| 11:52 |
Stompro |
tsbere, do you report OCLC holdings for MVLC as a whole? I'm trying to understand if your code handles systems/branches that have their own OCLC holdings. |
| 11:52 |
tsbere |
Stompro: We, as far as I know, only do global OCLC. If any of our members do their own I am unaware of it. |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:06 |
|
jeffdavis1 joined #evergreen |
| 12:08 |
|
Dyrcona joined #evergreen |
| 12:09 |
|
jeffdavis1 left #evergreen |
| 12:32 |
tsbere |
Stompro: If you want help adjusting my oclc code to include an org unit id (based on call number owning lib, maybe?) I can see about helping you with that at some point. |
| 12:36 |
|
rlefaive joined #evergreen |
| 12:38 |
csharp |
Stompro: in our case, OCLC has a translation table that maps org_unit.shortname to their codes |
| 12:38 |
csharp |
so we send them a big PINES-wide file, and they know what to do with it |
| 12:40 |
csharp |
jeff: OCLC was strangely non-communicative about pricing with one of our people recently too - took several months and multiple escalations to get a simple answer |
| 12:40 |
csharp |
(not EZproxy in our case) |
| 12:43 |
Stompro |
csharp, you do that for OCLC holdings withdraws? |
| 12:43 |
csharp |
Stompro: no - we have the libraries handle their own deletions |
| 12:43 |
jeff |
If you send the full file, why is there a need for deletions? |
| 12:44 |
csharp |
jeff: I don't recall the specifics of why, actually ;-/ |
| 12:45 |
Stompro |
I was assuming he meant that for new additions the big file gets sent. |
| 12:45 |
csharp |
yes, that's right |
| 12:45 |
jeff |
Ah. |
| 12:45 |
csharp |
for bibs added since the last upload |
| 12:45 |
csharp |
er... holdings, I mean |
| 12:46 |
jeff |
Sorry, I'm a little unfamiliar with how that works. We don't pay them enough money for them to accept holdings updates beyond "if you download this record from CatExpress, we add you to WorldCat as having it". |
| 12:47 |
Stompro |
I think we have the additions worked out, its just the last copy part of it, where one system still has copies and the other doesn't that I'm trying to find the best way to deal with. |
| 12:47 |
jeff |
And since that's far from comprehensive, nobody has voiced any interest in keeping up on withdrawals/deletions. |
| 12:55 |
csharp |
Stompro: we're in the same boat - if you figure something out, I'd love to hear it ;-) |
| 12:56 |
* jeff |
starts up a service to accept full extracts and maintain state, sending OCLC the required incrementals. |
| 12:56 |
jeff |
With the revenue from that, perhaps we could afford to pay OCLC to update our holdings! |
| 13:00 |
tsbere |
csharp: I don't think it would be too difficult to modify the code in my paste earlier to do per-ou (system? branch? ancestor at depth stuff works wonders...) tracking |
| 13:10 |
csharp |
tsbere: ooh - I'll take a look |
| 13:11 |
tsbere |
csharp: Just need to look at, say, the deleted flag on call numbers instead of bibs. |
| 13:36 |
|
jeffdavis joined #evergreen |
| 13:41 |
|
mdriscoll joined #evergreen |
| 13:51 |
|
sandbergja joined #evergreen |
| 13:51 |
|
jlundgren joined #evergreen |
| 13:55 |
yboston |
heads up the Evergreen for academics group IRC meeting will start at 2 PM EST |
| 14:01 |
yboston |
#startmeeting 2015-12-18 - Evergreen for academics monthly meeting. |
| 14:01 |
pinesol_green |
Meeting started Fri Dec 18 14:01:17 2015 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 14:01 |
pinesol_green |
The meeting name has been set to '2015_12_18___evergreen_for_academics_monthly_meeting_' |
| 14:02 |
yboston |
The agenda can be found here http://wiki.evergreen-ils.org/doku.php?id=evergreen_for_academics:2015-12-18 |
| 14:02 |
yboston |
please start introducing yourselves |
| 14:02 |
Christineb |
#info Christineb is Christine Burns BC Libraries Cooperative / Sitka |
| 14:02 |
yboston |
#info yboston is Yamil Suarez @ Berklee College of Music |
| 14:02 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 14:02 |
yboston |
#chair kmlussier |
| 14:02 |
pinesol_green |
Current chairs: kmlussier yboston |
| 14:02 |
mdriscoll |
#info mdriscoll is Martha Driscoll, NOBLE |
| 14:02 |
sandbergja |
#info sandbergja is Jane Sandberg, Linn-Benton Community College |
| 14:02 |
jeffdavis |
#info jeffdavis is Jeff Davis, BC Libraries Cooperative |
| 14:03 |
|
krvmga joined #evergreen |
| 14:03 |
jlundgren |
#info jlundgren is Jeanette Lundgren, C/W MARS |
| 14:03 |
krvmga |
#info krvmga = Jim Keenan, C/W MARS |
| 14:03 |
jihpringle |
#info jihpringle is Jennifer Pringle BC Libraries Cooperative / Sitka |
| 14:04 |
yboston |
Hello everyone. Today we will focus on the topic of reserves |
| 14:04 |
krvmga |
a favorite! |
| 14:04 |
yboston |
and kmlussier will lead the way with my help (if needed) |
| 14:04 |
kmlussier |
Hi everyone! :) |
| 14:04 |
sandbergja |
I'm excited! |
| 14:05 |
kmlussier |
I thought it would be good just to start with a general discussion on how people are handling reserves with Evergreen since it doesn't have specific reserves functionality. What are you all using? |
| 14:05 |
krvmga |
syrup |
| 14:06 |
|
horganl joined #evergreen |
| 14:06 |
mdriscoll |
syrup |
| 14:06 |
krvmga |
the course reserves software created by art ryno |
| 14:06 |
krvmga |
(sp?) |
| 14:06 |
Christineb |
one of our libraries uses "bookbags" created by laurentian |
| 14:06 |
sandbergja |
We are indexing professor name and course number in MARC fields for searching, and then using item buckets/copy editor to move 'em around and apply appropriate circmods |
| 14:06 |
kmlussier |
Just a note that the Syrup course reserves system lives at http://git.evergreen-ils.org/?p=Syrup.git;a=summary |
| 14:06 |
kmlussier |
#link http://git.evergreen-ils.org/?p=Syrup.git;a=summary |
| 14:07 |
|
suzanne joined #evergreen |
| 14:07 |
yboston |
we use a homemade reserves system using PHP and MySQL. It orignally was meant to work with Horizozn, but then we updated it to work with EG by using direct DB calls. It mostly just uses a copy's barcode |
| 14:08 |
kmlussier |
Christineb: When you say you're using bookbags from Laurentian, what exactly does the code do to work with the bookbags in Evergreen? |
| 14:09 |
kmlussier |
Also, I know there's a link to that code somewhere, but I can't recall where it is |
| 14:09 |
jeffdavis |
The code is here (more or less): https://github.com/dbs/library |
| 14:09 |
kmlussier |
jeffdavis++ #Thanks! |
| 14:09 |
jeffdavis |
Based on my question to dbs the other day, Laurentian themselves are using a newer, Python-based homegrown app. |
| 14:10 |
jeff |
dbs stated yesterday that Laurentian now uses https://github.com/dbs/course-reserves |
| 14:10 |
kmlussier |
#link https://github.com/dbs/library |
| 14:10 |
Christineb |
old post from Dan Scott - https://coffeecode.net/archives/250-Current-state-of-academic-reserves-support-for-Evergreen.html |
| 14:10 |
kmlussier |
#link https://github.com/dbs/course-reserves |
| 14:11 |
jeffdavis |
The app that we are using is just a PHP + SQLite web app for recording & searching course name, instructor name, and a link to an Evergreen bookbag that contains the materials on reserve. |
| 14:12 |
kmlussier |
Oh, I see. So the code creates the listing page, but then the bookbags themselves are just typical Evergreen bookbags. Is that right? |
| 14:12 |
jeffdavis |
yep |
| 14:13 |
kmlussier |
sandbergja: Could you explain your process a little more. The copies themselves are attached to the MARC record for the course rather than a record with bib information? |
| 14:14 |
kmlussier |
Also, if other people have questions, feel free to ask them. |
| 14:15 |
sandbergja |
Sorry, I wasn't clear. We take an ordinary MARC record with bib information, and add course information to it in custom 9xx fields. |
| 14:15 |
sandbergja |
Here's an example: http://libcat.linnbenton.edu/eg/opac/record/507772?expand=marchtml#marchtml |
| 14:15 |
sandbergja |
971 field contains our professor's name, and 972 contains the title of the course |
| 14:16 |
kmlussier |
mdriscoll and krvmga can chime in, but in broad strokes, Syrup is a third-party system, but it tightly integrates with Evergreen so that it can look up instructors from the Evergreen database and then look up copies by barcode when adding them to the course. |
| 14:16 |
jeffdavis |
sandbergja: Do you have a custom search index for those fields? |
| 14:16 |
sandbergja |
jeffdavis: yes -- it was set up before my time |
| 14:17 |
kmlussier |
sandbergja: Ah, I see now. When titles go off of reserves then, do you need to remove those local fields? |
| 14:18 |
sandbergja |
Yes, in theory. I suspect that we miss a few, though. :-) |
| 14:18 |
kmlussier |
#info C/W MARS and NOBLE are using Syrup |
| 14:18 |
mdriscoll |
sandbergja: are you able to get circulation stats by professor? |
| 14:18 |
kmlussier |
#info A library in Sitka uses code from dbs that creates a course listing for reserves that are kept in bookbags |
| 14:18 |
horganl |
I was just wondering if users are satisfied with the functions currently provided locally. We are a noble library using syrup and like it pretty well except we would like it more integrated into evergreen |
| 14:19 |
sandbergja |
mdriscoll: Yes, I was able to put together something in the reporter. |
| 14:19 |
krvmga |
horganl: this is what we'd like to see as well |
| 14:19 |
kmlussier |
#info Linn-Benton Community College uses MARC record with course information in local fields and manages copy parameters in buckets |
| 14:20 |
kmlussier |
#info Berklee uses a homemade reserves system using PHP and MySQL |
| 14:21 |
kmlussier |
Yes, to add on to what horganl is asking, are your local solutions working for you? What works well or doesn't work well? And, generally, would you like to see more baked-in functionality in Evergreen or are you okay with what you're doing now? |
| 14:21 |
kmlussier |
Sorry, lots of questions in one post. |
| 14:22 |
jeffdavis |
The one library using reserves at Sitka is reasonably satisfied AFAIK, but I think potential new members of the consortium would be happier with a more integrated reserves module (it's the kind of think post-secondary libraries ask about when they're looking at an ILS). |
| 14:23 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 14:23 |
kmlussier |
jeffdavis: Yes, I agree that a more integrated reserves module would make Evergreen more attractive to academic libraries. |
| 14:23 |
mdriscoll |
We use a seperate installation of syrup for each consortia member so from a sysadmin point of view it is cumbersome to do that, especially when it comes to updates. |
| 14:24 |
remingtron |
#info Calvin College is using Syrup, with several customizations and bug fixes |
| 14:24 |
sandbergja |
We're pretty happy with ours, but it does rely on a lot of staff time. |
| 14:24 |
horganl |
And you can not look at the data at the item level from within syrup |
| 14:25 |
kmlussier |
remingtron: I would love to see what you have for customizations and bug fixes sometime. For a future discussion. |
| 14:26 |
remingtron |
kmlussier: sure, happy to discuss sometime. |
| 14:26 |
krvmga |
mdriscoll: we do the same in C/W MARS. it can be a bit of a maintenance nightmare |
| 14:26 |
jeffdavis |
Are there other limitations/missing features with Syrup that folks are running into? |
| 14:27 |
jeffdavis |
(Not to get into a long discussion of bugs or whatever.) |
| 14:27 |
kmlussier |
jeffdavis: What I hear most is we want something that better supports consortium the way Evergreen does and overall tighter integration. |
| 14:28 |
mdriscoll |
We have run into issues with muli-branch libraries using one instance of Syrup. |
| 14:28 |
kmlussier |
Usually, when there's a problem, it boils down to the fact that, as much as we've integrated it with Evergreen, it still is really a separate system. |
| 14:28 |
jeff |
Can anyone elaborate what is meant by "tighter integration" or how you'd like to look at "data at the item level from within syrup"? |
| 14:29 |
mdriscoll |
I would define tighter integration as using the existing evergreen tables wherever possible instead of duplicating copy data, user data etc. |
| 14:29 |
kmlussier |
jeff: From my perspective, I would like to see course reserves baked into Evergreen using Syrup as its foundation. |
| 14:30 |
kmlussier |
jeff: I think we could make integration tighter in other ways while keeping it a third-party system, but I think I would rather see it as something you can enable with a setting or two (or more). |
| 14:31 |
jeff |
glossing over things like shared tables / reduced time to set up, what kinds of things are not possible currently? |
| 14:33 |
horganl |
When you look at the item you can tell it is on reserve by the copy location but not for what course, instructor, or semester. |
| 14:33 |
jeff |
Can you give any examples of the issues with multi-branch libraries, or the problems that have boiled down to Syrup being a distinct system? |
| 14:33 |
jeff |
horganl: Ah! Thanks! |
| 14:34 |
horganl |
If there needs to be a change to the circ modifier you can't go there directly from clicking on the link in syrup |
| 14:34 |
kmlussier |
As mdriscoll mentioned, we're copying data over that is already in the Evergreen database. So as things get updated in Evergreen, they don't get updated in Syrup, which can be confusing for staff since they retrieved the data from Evergreen and don't understand why it doesn't get updated in both places. |
| 14:35 |
mdriscoll |
Syrup is associated with a branch so when searching for a professor, it won't find users in another org unit. This is a problem for one of our multi-campus libraries. |
| 14:35 |
horganl |
One of the issues with Multi-branch libraries pertains to adding the instructor. All of our instructors have to be entered in one directory even if they teach on the other campus |
| 14:35 |
krvmga |
mdriscoll: we have the same issue |
| 14:36 |
kmlussier |
jeff: Does that answer your questions? |
| 14:36 |
horganl |
It becomes a training issue for staff.... |
| 14:36 |
jeff |
kmlussier: think so! thanks for obliging! |
| 14:37 |
kmlussier |
jeff: np |
| 14:37 |
jeff |
kmlussier++ mdriscoll++ horganl++ krvmga++ |
| 14:37 |
jihpringle |
do people have training resources they currently use for training staff that are publicly available of that they would be willing to share? |
| 14:37 |
kmlussier |
During the hack-a-way, some of the MassLNC folks looked at what we thought it would take to do the work to get course reserves into Evergreen. |
| 14:37 |
kmlussier |
#link http://wiki.evergreen-ils.org/doku.php?id=scratchpad:course_reserves |
| 14:38 |
sandbergja |
MassLNC++ |
| 14:39 |
kmlussier |
jihpringle: That's a good question. Does anyone have anything they can share now? |
| 14:39 |
kmlussier |
Or maybe if something they can send to the list at a later time? |
| 14:40 |
sandbergja |
jihpringle: here is the documentation that our circ staff uses for our custom-field workaround solution: https://docs.google.com/document/d/1t5X7E6DsIXowBBv_6Q2s0PSdnfmB6Pkdqg1rSUgw2SY/edit?usp=sharing |
| 14:41 |
sandbergja |
as I said, ours is a time-intensive process |
| 14:41 |
jihpringle |
thanks sandbergja |
| 14:41 |
kmlussier |
jihpringle: I don't think it's used for training, but artunit wrote up some docs for us on Syrup at http://git.evergreen-ils.org/?p=Syrup.git;a=tree;f=docs;h=52dd2dfe05fc8ad6892053080e29251658d246e7;hb=HEAD that can be useful for seeing how it works. |
| 14:42 |
kmlussier |
Actually, it's nicely formatted here: http://git.evergreen-ils.org/?p=Syrup.git;a=blob_plain;f=docs/syrup.html;hb=HEAD |
| 14:42 |
jihpringle |
that's great for getting an idea of how it works, thanks |
| 14:43 |
horganl |
Not sure our documentation is current we have changed how we do things since we came up. One of the parts I really like about syrup is that we can control how the course and instructor appear for all records. |
| 14:43 |
kmlussier |
What MassLNC is planning to do, hopefully with local resources, is to see if we can do the work to get course reserves as a baked-in part of Evergreen. |
| 14:43 |
horganl |
In the past and Eng 101 course might be entered in multiple ways |
| 14:43 |
krvmga |
masslnc++ |
| 14:44 |
Christineb |
masslnc++ |
| 14:44 |
kmlussier |
We were thinking it would entail two projects. One would be to create a reserves schema for course information and the interfaces around managing reserves. |
| 14:44 |
jihpringle |
masslnc++ |
| 14:45 |
kmlussier |
But there is also a second project that we think will be useful to lots of sites, which is a way to store copy parameters and then easily revert them when an item is pulled off of reserves. We think this would be useful for display materials, summer reading, etc. |
| 14:46 |
krvmga |
kmlussier: that would be useful |
| 14:46 |
kmlussier |
Syrup already does this for us with our reserves materials, but I think its functionality extends beyond reserves. |
| 14:47 |
kmlussier |
We have some draft requirements for the latter project, but they are already dated as I have some feedback to incorporate in them. |
| 14:47 |
kmlussier |
But I'll share them to give you all an idea of how we envision it working http://masslnc.org/node/3181 |
| 14:48 |
kmlussier |
I had hoped to have more requirements available in time for this meeting, but I'm still working on them. |
| 14:48 |
kmlussier |
We will be sharing them with the community as we go along, though, and I can report back at future meetings too. |
| 14:49 |
kmlussier |
But before I leave off, I have a question. If there were just one thing that would improve your reserves workflow, whatever you are using, what would it be? |
| 14:50 |
kmlussier |
Since we're looking at putting reserves in Evergreen, it would be good to see if we are making workflows easier for people. |
| 14:52 |
jihpringle |
kmlussier: do you have an EG release you plan to target for the integration or is it too early for that? |
| 14:52 |
kmlussier |
jihpringle: It's too early for that. Definitely NOT 2.10. :) |
| 14:52 |
krvmga |
2.12 sounds good. :) |
| 14:53 |
kmlussier |
jihpringle: At this point, I need to finish up the functional requirements so that the tech people can look at them and give us a realistic estimate. But krvmga is probably close. |
| 14:53 |
yboston |
so, we need to start talking about our next meeting |
| 14:54 |
yboston |
and any action tiems that we need to identify |
| 14:54 |
kmlussier |
yboston: Will we be doing a specific topic for the next meeting too? |
| 14:55 |
yboston |
offically, I am not the one that decides that |
| 14:55 |
yboston |
personally I wanted to suggest that we talk about reserves gain next time |
| 14:55 |
jihpringle |
i really like the specific topic meeting, I think this one worked really well |
| 14:55 |
yboston |
*again |
| 14:55 |
yboston |
but I am open to finding another topic |
| 14:55 |
jihpringle |
+1 course reserves |
| 14:56 |
yboston |
also, do we want to meet again in January or wait for february? |
| 14:56 |
krvmga |
yboston: i second that. in the meantime, everyone will have more of a chance to look at what is at the links given. |
| 14:57 |
yboston |
so quickly, shoudl we target Janaury or february for next meerting? |
| 14:57 |
jihpringle |
my vote is for february |
| 14:57 |
mdriscoll |
I vote for February |
| 14:57 |
kmlussier |
I have no opinion, but if it is January, can we do it after the 15th? That's when I'll be meeting with local folks about reserves. |
| 14:57 |
yboston |
#action yboston will email the list with a copy of the meeting minutes |
| 14:57 |
krvmga |
february +1 |
| 14:58 |
yboston |
could I get a volunteer to run a Doodle poll for February dates? |
| 14:58 |
jihpringle |
sure |
| 14:58 |
yboston |
I will email the list witht he meeting minutes and update the wiki |
| 14:58 |
yboston |
thanks |
| 14:59 |
|
sandbergja joined #evergreen |
| 14:59 |
yboston |
#action jihpringle will create a doodle poll for the next group meeting in February |
| 14:59 |
kmlussier |
Thanks yboston! |
| 14:59 |
yboston |
also, we seem to be in agreement on reserves as the topic? |
| 15:00 |
krvmga |
yes, it seems so. |
| 15:00 |
yboston |
I normally like to always check with the general list, but I want to give credit to those that make it to the IRC meetings |
| 15:00 |
yboston |
#agreed the next group meetings topic will be reserves again |
| 15:01 |
yboston |
any final comments or questions? |
| 15:01 |
krvmga |
yboston++ |
| 15:01 |
jihpringle |
is there a list anywhere of the regular meeting days for othergroups, DIG, EOB etc. ? nothing is on the EG calendar for feb at the moment and I don't want to double book |
| 15:01 |
krvmga |
kmlussier++ |
| 15:01 |
sandbergja |
kmlussier++ |
| 15:01 |
yboston |
let me look |
| 15:01 |
kmlussier |
yboston++ |
| 15:01 |
jihpringle |
thanks |
| 15:02 |
kmlussier |
jihpringle: EOB meets regularly (can't recall the day now) so I'm sure there's something scheduled. |
| 15:02 |
kmlussier |
Developer meeting's on the 3rd |
| 15:02 |
yboston |
I need to add the next Board meeting, there is also a standing academics meeting in the calendar that we don't have to stick to. (We could delete that automatic entry) |
| 15:02 |
|
horganl left #evergreen |
| 15:03 |
yboston |
the Board usually meets the 3rd Thursday of the month |
| 15:03 |
jihpringle |
good to know, thanks |
| 15:04 |
yboston |
#endmeeting |
| 15:04 |
pinesol_green |
Meeting ended Fri Dec 18 15:04:08 2015 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:04 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-12-18-14.01.html |
| 15:04 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-12-18-14.01.txt |
| 15:04 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-12-18-14.01.log.html |
| 15:04 |
krvmga |
thanks, everyone! :) |
| 15:05 |
krvmga |
sql/Pg/upgrade script question: all the scripts i've looked at have SELECT evergreen.upgrade_deps_block_check('0898', :eg_version); after BEGIN (where 0898 is the number at the beginning of the name of the script. |
| 15:05 |
kmlussier |
Thanks everyone for sharing your reserves workflows! I found the info very useful! |
| 15:05 |
krvmga |
i don't understand this line. |
| 15:05 |
Stompro |
Has anyone added OCLC number search to your Z39.50 server? I tried adding eg.scn to the search map in oils_z3950.xml, but I think there must be more too it, since that doesn't work. |
| 15:07 |
|
jlundgren left #evergreen |
| 15:08 |
yboston |
jihpringle: I just updated the calendar for February with the board meeting and DIG meeting |
| 15:08 |
kmlussier |
jeff: One additional consideration that I forgot to mention during the meeting, beyond functionality, is that Syrup right now has a very small community of users, which can be challenging with an open source solution. |
| 15:09 |
krvmga |
kmlussier: yes, a very small community of users |
| 15:09 |
kmlussier |
AFAIK, the only sites using it are C/W MARS, NOBLE, Calvin College and Windsor. It makes it difficult for the software to grow, but also presents support challenges. |
| 15:09 |
kmlussier |
Of course, artunit is always available to help us out when we're in trouble and has bailed us out a few times. :) |
| 15:09 |
kmlussier |
artunit++ |
| 15:10 |
krvmga |
i know C/W MARS wants to step up more in this area |
| 15:11 |
krvmga |
artunit++ |
| 15:11 |
jeffdavis |
krvmga: that SQL function checks config.upgrade_log to see if you've already run the current update. |
| 15:11 |
kmlussier |
krvmga: Are you doing an upgrade script that will be part of code you're contributing to Evergreen? |
| 15:11 |
kmlussier |
krvmga: If not, you don't need it. |
| 15:12 |
krvmga |
kmlussier: no, we're just eliminating some lines in vandelay.overlay_bib_record |
| 15:12 |
krvmga |
jeffdavis: thanks |
| 15:14 |
krvmga |
per bshum's bandaid for 012.schema.vandelay.sql |
| 15:14 |
krvmga |
commenting out three lines of code |
| 15:16 |
pastebot |
"krvmga" at 64.57.241.14 pasted "upgrade to 012.schema.vandelay.sql" (72 lines) at http://paste.evergreen-ils.org/13 |
| 15:25 |
jeff |
kmlussier: I'm not sure which I like more -- a small open source project with four users, or a feature of a larger project with four users. :-) |
| 15:26 |
|
kmlussier left #evergreen |
| 15:26 |
|
kmlussier joined #evergreen |
| 15:27 |
kmlussier |
jeff: Well, would it be four users then? If functionality is a baked-in part of the system, don't you think more people would be likely to use it than if it is something you have to install/maintain independently? |
| 15:28 |
* mmorgan |
wonders how many users there are for the baked in Bookings functionality. |
| 15:30 |
mmorgan |
We have a couple of libraries that use booking for a very specific purpose, but if it hadn't been baked in, their use certainly wouldn't have justified maintaining a separate installation |
| 15:48 |
jihpringle |
mmorgan: we have a bunch of libraries try it but only one still using it that we know of - it just doesn't have all the needed functionality |
| 15:52 |
jeff |
dbwells++ for bug 1527731 |
| 15:52 |
pinesol_green |
Launchpad bug 1527731 in Evergreen "Query for OPAC copies can be extremely slow" [Undecided,New] https://launchpad.net/bugs/1527731 |
| 15:53 |
|
jlitrell joined #evergreen |
| 15:56 |
Stompro |
Should there be anything at http://open-ils.org/spec/SRU/context-set/evergreen/v1 as mentioned at the SRU explain page http://egcatalog.larl.org/opac/extras/sru ? |
| 16:01 |
* mmorgan |
reads through 1527731 |
| 16:02 |
mmorgan |
Do these copy queries get executed in a general OPAC search? |
| 16:13 |
dbwells |
mmorgan: It is executed on the record detail page. |
| 16:14 |
dbwells |
When using "next" and "previous", we would see fast, fast, fast, sloooow, fast, slooow, etc. |
| 16:15 |
Stompro |
Is there a gui control to modify config.metabib_search_alias? (getting closer to adding an index to SRU searching I think) |
| 16:15 |
mmorgan |
dbwells: ok, makes sense. Thanks. Good catch! |
| 16:15 |
mmorgan |
dbwells+ |
| 16:15 |
mmorgan |
Oops, make that dbwells++ |
| 16:15 |
dbwells |
:) |
| 16:15 |
jeff |
Stompro: The current state of things shouldn't cause anything to break. Something could be put there, and I've seen some people put things at the URI used for identifiers... |
| 16:17 |
jeff |
Stompro: The SRU spec doesn't make any recommendation other than that it is a string. |
| 16:17 |
dbwells |
In practice, that query is a small part of the overall page load, so we would see either 2-3 second loads, or 9-10 second loads. It was probably easier to notice now since our new server is generally much speedier. |
| 16:18 |
jeff |
Stompro: the other identifiers use info:// uris, like "info:srw/cql-context-set/1/cql-v1.2" |
| 16:19 |
jeff |
Stompro: You can see the info:srw entry in the info URI registry here: http://info-uri.info/registry/OAIHandler?verb=GetRecord&metadataPrefix=reg&identifier=info:srw/ |
| 16:21 |
Stompro |
jeff, thanks, I think I'm figuring it out. I was thinking that the link would have documentation, but I see now that it is more of an identifier. Z39.50 maps -> SRU Index -> defined in the config.metabib_search_alias which refers to the system index. |
| 16:54 |
|
mdriscoll left #evergreen |
| 17:09 |
|
HoloIRCUser2 joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
jeffdavis |
dbwells: as noted in the bug report, I think maybe 1527731 is the same issue as bug 1499086, for which I have shared a fix |
| 17:17 |
pinesol_green |
Launchpad bug 1499086 in Evergreen 2.9 "Slowness/timeout on loading bookbags in OPAC" [Medium,Triaged] https://launchpad.net/bugs/1499086 |
| 17:18 |
jeffdavis |
my fix is your "proposed solution #3" I believe |
| 17:20 |
dbwells |
jeffdavis: Yes, I think you are right. Thanks for pointing this out! Has it caused you folks any issues to run it this way? |
| 17:21 |
|
bmills joined #evergreen |
| 17:22 |
jeffdavis |
No, we've had it in production for a few months now and it seems fine. I did need to tweak my initial attempt; I'll need to double check to make sure that working branch contains all the tweaks. |
| 17:23 |
jeffdavis |
I need to step away briefly but I will review later this afternoon and update the branch if need be. |
| 17:24 |
dbwells |
jeffdavis++ |
| 18:00 |
|
Dyrcona joined #evergreen |
| 18:05 |
|
Dyrcona joined #evergreen |
| 18:20 |
jeffdavis |
ok, confirmed that working branch user/jeffdavis/lp1499086-bookbag-slowness has all necessary tweaks/bugfixes |
| 21:58 |
|
artunit_ joined #evergreen |
