| Time |
Nick |
Message |
| 01:04 |
|
DPearl joined #evergreen |
| 04:14 |
kmlussier |
jonadab: Well, there is the Douglas county model for purchasing ebooks - http://douglascountylibraries.org/content/ebooks-and-DCL |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:35 |
|
rjackson_isl joined #evergreen |
| 07:45 |
|
graced joined #evergreen |
| 07:50 |
|
mrpeters joined #evergreen |
| 07:58 |
csharp |
kmlussier: thanks for sharing that. I love that they took that stand. |
| 07:59 |
* csharp |
is curious about how other EG libraries are dealing with ebooks logistically |
| 07:59 |
csharp |
there's been a long-standing impasse here about whether we are to batchload in ebook MARC records |
| 08:00 |
csharp |
most of the issue is that they are non-OCLC records and we're a single-bib-source shop |
| 08:01 |
csharp |
but I wonder how we would deal with the fact that the ebook providers are constantly changing who has access to what - specifically, do sys admins just constantly add and delete bibs at the same rate they are provided by the ebook vendor? |
| 08:02 |
csharp |
also, we have several ebook providers throughout the consortium with different policies |
| 08:02 |
csharp |
anyway, just musing aloud here because it's something we're discussing internally |
| 08:03 |
|
jboyer-isl joined #evergreen |
| 08:03 |
csharp |
my pie-in-the-sky hope is that we could tie into the ebook providers' APIs (assuming they exist) so that we can load ebook results alongside other catalog results without them actually being in EG |
| 08:04 |
csharp |
@monologue |
| 08:04 |
pinesol_green |
csharp: Your current monologue is at least 9 lines long. |
| 08:10 |
csharp |
huh - I just had the idea to have a "catalog tips" widget with random/rotating ideas about searching (customizable via TT2, maybe?) |
| 08:10 |
csharp |
"Did you know that e-books are available via GALILEO? Learn more (link)" |
| 08:11 |
csharp |
dunno if that would seem too spammy/corporate |
| 08:15 |
|
collum joined #evergreen |
| 08:25 |
|
akilsdonk joined #evergreen |
| 08:26 |
kmlussier |
csharp: I know C/W MARS and NOBLE have different workflows for loading their ebook records. If you send that question to the list, I'm guessing they'll send a response. |
| 08:27 |
kmlussier |
They both have academics, so getting those ebook records in the catalog is an important service for their libraries. |
| 08:27 |
csharp |
kmlussier: thanks - I'll consider that... it's kind of a sensitive issue around here right now, so I need to check around here before asking |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:36 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
remingtron joined #evergreen |
| 08:46 |
|
Shae joined #evergreen |
| 08:53 |
|
Newziky joined #evergreen |
| 08:53 |
|
jwoodard joined #evergreen |
| 09:07 |
|
maryj joined #evergreen |
| 09:35 |
|
DPearl left #evergreen |
| 09:41 |
|
yboston joined #evergreen |
| 09:58 |
|
mllewellyn joined #evergreen |
| 10:01 |
|
montgoc1 joined #evergreen |
| 10:28 |
dbs |
csharp: we tend not to load records for constantly-changing ebook providers. Then again, we try not to purchase subscriptions for content we don't have control over. |
| 10:29 |
dbs |
Nothing pisses off our faculty and students more than an ebook that's there one day (say, when the faculty member prescribes a reading at the start of the academic year) |
| 10:29 |
dbs |
and gone the next (say, when the student goes to actually read it) |
| 10:29 |
dbs |
Otherwise, we load records for any ebooks to which we've purchased permanent access. |
| 10:52 |
|
Newziky left #evergreen |
| 11:04 |
eeevil |
csharp: so, your "tips" idea existed from day 1, but was tossed out with the TPAC |
| 11:06 |
eeevil |
and I wrote a federated search prototype in the long long ago ... all client side JS+xslt, with a proxy shim on the server to get around cross-site XHR restrictions |
| 11:06 |
eeevil |
I think the code's in the evergreen repo... |
| 11:07 |
eeevil |
csharp: and, the original use case for bib source is to easily segregate records coming from different places, so you could purge ebook records easily at update time, for instance |
| 11:16 |
jeffdavis |
hmm, that reminds me to have a look at bug 1178377 ... |
| 11:16 |
pinesol_green |
Launchpad bug 1178377 in Evergreen "Expose bib source in TPAC" (affected: 2, heat: 10) [Wishlist,Incomplete] https://launchpad.net/bugs/1178377 |
| 11:23 |
jeffdavis |
All the pieces are there but the latest branch is based on 2.4. Let me see if I can apply those changes to master. |
| 11:33 |
|
bmills1 joined #evergreen |
| 11:52 |
|
dMiller_ joined #evergreen |
| 12:01 |
jeffdavis |
ok, now there's a branch that can be pulled into master, bug has been updated |
| 12:05 |
csharp |
dbs: that sounds like a sound policy |
| 12:05 |
csharp |
I'll suggest that here |
| 12:06 |
|
gsams joined #evergreen |
| 12:06 |
jeff |
jeffdavis++ |
| 12:07 |
csharp |
eeevil: interesting about the "tips" idea; excellent about bib source |
| 12:07 |
csharp |
I was just musing about "huh, I wonder if there's some way we could mark the ebook records...." |
| 12:09 |
Dyrcona |
We use bib sources for our Overdrive and Safari Books Online records. |
| 12:09 |
Dyrcona |
Other ebook providers have not really made it into the database, yet. |
| 12:30 |
csharp |
so to resume a thread from a number of weeks ago, we're seriously considering OSTicket as our Helpdesk software - anyone else using that? |
| 12:31 |
csharp |
we're evaluating RT as well, but so far setup is pretty non-intuitive and all the "user" docs read like Linux man pages |
| 12:32 |
csharp |
"setup" = "configuration within the UI", btw |
| 12:32 |
tsbere |
We use RT by choice of our members. |
| 12:32 |
* tsbere |
can help with setting RT up as a result |
| 12:32 |
csharp |
tsbere: that's nice to know |
| 12:33 |
csharp |
well, one of the selling points on our end for RT is that it's in use by other EG sites, which might lead to some EG/RT integration ideas in the future? |
| 12:34 |
csharp |
one of the originally envisioned features of Evergreen was helpdesk integration, but it didn't get very far |
| 12:38 |
bshum |
You know, speaking of bib sources... |
| 12:38 |
bshum |
Anyone got a test server with 2.8/master around and can test something for me |
| 12:38 |
bshum |
So I got a report from our staff that loading bibs is causing the bib source to change to the latest source on merges. |
| 12:38 |
bshum |
Instead of staying at the original source. |
| 12:39 |
bshum |
During match-only merge. |
| 12:39 |
bshum |
I'm getting into it shortly, but curious to see if I can verify that it's not just our systems. |
| 12:39 |
Dyrcona |
I could test it, but I'm too busy to do that today. |
| 12:47 |
|
bmills1 joined #evergreen |
| 12:54 |
|
sandbergja joined #evergreen |
| 13:13 |
bshum |
Aha |
| 13:13 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=62510da3171c54bfeb2b34478c4e4a6c2c05acb1 |
| 13:13 |
pinesol_green |
[evergreen|Remington Steed] LP#957466: Update editor/edit_date/source on overlay - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=62510da> |
| 13:14 |
* mmorgan |
was going to point bshum to lp 957466 |
| 13:14 |
pinesol_green |
Launchpad bug 957466 in Evergreen "overlaying a record from vandelay does not update editor/edit_date" (affected: 7, heat: 34) [Medium,Fix released] https://launchpad.net/bugs/957466 |
| 13:15 |
bshum |
Well, apparently having the source updated is highly undesirable for our current cataloging workflows. |
| 13:15 |
kmlussier |
I'm guessing the bib record edit date is updated too? |
| 13:15 |
bshum |
Probably |
| 13:16 |
mllewellyn |
I like the edit date update |
| 13:16 |
mllewellyn |
just want control over the bib source update |
| 13:17 |
mllewellyn |
we have acq vendor records labeled with a different bib source, and when they match, they're changing our OCLC bib source |
| 13:18 |
mllewellyn |
I use that source to identify records I need to overlay to full OCLC records |
| 13:20 |
bshum |
So I think I see the part in the vandelay database function that changes the source. For the short term, mllewellyn, I think I can safely rip it out of our database. |
| 13:20 |
bshum |
But long-term, it sounds like we should file a bug to make this some sort of setting controlled option. |
| 13:21 |
mllewellyn |
like a bib source hierarchy |
| 13:24 |
Dyrcona |
The bib source change was intended to make records get the bib source selected in the vandelay import because we had fresh records loading (not overlay records) and getting a null bib source. |
| 13:24 |
Dyrcona |
The branch was evaluated on that basis, and overlay was not on my radar in the testing that I did. |
| 13:26 |
bshum |
I could see avoiding that being helpful. |
| 13:27 |
* bshum |
rips it out for now so that mllewellyn's work isn't disrupted. |
| 13:27 |
bshum |
I'll file a new bug on the subject in a bit. |
| 13:28 |
kmlussier |
mllewellyn: I was thinking the edit date update was only useful if you were actually updating the bib record. With a match-only merge, it seems like the date should stay the same. |
| 13:29 |
kmlussier |
BTW, bshum, welcome back! |
| 13:29 |
bshum |
kmlussier: Thanks! Sadly I did not actually get to merge anything new while I was abroad :( |
| 13:30 |
mllewellyn |
kmlussier: in this case, it was helpful to find those bibs with the changed source to narrow down what was going on |
| 13:31 |
Dyrcona |
Given that this all happens in a database trigger, I believe the amount of information available for it to determine what to do is limited. |
| 13:32 |
bshum |
Indeed. |
| 13:32 |
Dyrcona |
It would need more arguments or a new implementation to be smarter. |
| 13:34 |
bshum |
I was wondering about that too |
| 13:34 |
bshum |
How best to implement some sort of toggle |
| 13:35 |
bshum |
But it seems annoying to check that every time. |
| 13:35 |
bshum |
I'll have to ponder that more later... next fire. |
| 13:36 |
kmlussier |
A sticky toggle might be useful |
| 13:42 |
kmlussier |
I'm not able to log into webby today. Does webby need a kick or is it just happening to me? |
| 13:42 |
|
akilsdonk joined #evergreen |
| 13:58 |
Dyrcona |
Dunno, but amazingly enough, I've not had a problem with the wifi yet. |
| 13:58 |
bshum |
And................ |
| 13:58 |
bshum |
Nope, still there. |
| 13:59 |
bshum |
You dare the fates to conspire against you Dyrcona. Beware their wrath. |
| 13:59 |
Dyrcona |
heh |
| 14:03 |
bshum |
csharp: I changed the milestones on https://bugs.launchpad.net/evergreen/+bug/1446860 so that it targets all the current round of maintenance release milestones. |
| 14:03 |
pinesol_green |
Launchpad bug 1446860 in Evergreen "staff users can edit their own accounts" (affected: 2, heat: 10) [High,Confirmed] - Assigned to Chris Sharp (chrissharp123) |
| 14:03 |
bshum |
I figure that the fix should be applied everywhere. |
| 14:03 |
bshum |
I'll review it in a bit and get it pushed along. |
| 14:09 |
bshum |
mllewellyn: I filed https://bugs.launchpad.net/evergreen/+bug/1447746 to make sure I didn't forget it. |
| 14:09 |
pinesol_green |
Launchpad bug 1447746 in Evergreen "Do not update bib source on match-only merge" (affected: 1, heat: 6) [Undecided,New] |
| 14:10 |
kmlussier |
berick (or anyone else who knows the answer): I've seen instructions to install hatch on linux and on windows. Will it also work on macs? |
| 14:11 |
jeff |
it is intended to, but I've not been able to test that becase of my ancient version of OS X. |
| 14:12 |
kmlussier |
jeff: OK, thank you! |
| 14:15 |
mllewellyn |
bshum: thank you |
| 14:15 |
bshum |
mllewellyn++ # getting the word out |
| 14:17 |
berick |
kmlussier: yes, i have gotten it to work on a mac before. |
| 14:17 |
kmlussier |
berick: Great! Thank you! |
| 14:21 |
jeff |
Question: Where is 905$u use common? |
| 14:22 |
jeff |
(perhaps not a simple question) |
| 14:24 |
jeff |
oh, we appear to have maintained 905$u on a handful of records. |
| 14:26 |
csharp |
bshum: great - thanks. I don't appear to have access to add more than one version to target. |
| 14:27 |
bshum |
csharp: Easy enough to grant you |
| 14:27 |
bshum |
Do you want the power? (with great power comes great responsibility) |
| 14:28 |
bshum |
csharp: The group you want is https://launchpad.net/~evergreen-drivers |
| 14:29 |
bshum |
If you apply to join that, then you can have series targeting powers. |
| 14:32 |
csharp |
<he_man>I HAVE THE POWER!!!</he_man> |
| 14:34 |
bshum |
And done. |
| 14:35 |
jeff |
Okay, so while commit 7a39120 has been around since 2010, it wasn't until recently that we started seeing evergreen maintain 905$u |
| 14:35 |
pinesol_green |
[evergreen|miker] support 905u (editor by barcode or usrname) in vandelay overlay/merge rules - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a39120> |
| 14:39 |
jeff |
looks like 905$u is now being set for any records that we're bringing in via vandelay. |
| 15:04 |
* csharp |
looks around for a dev meeting... |
| 15:05 |
csharp |
bshum++ # thanks |
| 15:07 |
* jeffdavis |
is also here for the dev meeting |
| 15:10 |
* jeffdavis |
should learn how to facilitate meetings in IRC |
| 15:11 |
* kmlussier |
can't run a meeting today. |
| 15:11 |
jeff |
jeffdavis: no time like the present? http://wiki.evergreen-ils.org/doku.php?id=community:using-meetbot |
| 15:12 |
* berick |
finally arrives |
| 15:12 |
* dbs |
kicks visitor out of office |
| 15:13 |
dbwells |
#startmeeting Development Meeting, 23 April 2015 |
| 15:13 |
pinesol_green |
Meeting started Thu Apr 23 15:13:07 2015 US/Eastern. The chair is dbwells. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:13 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 15:13 |
pinesol_green |
The meeting name has been set to 'development_meeting__23_april_2015' |
| 15:13 |
berick |
dbwells++ |
| 15:13 |
dbwells |
#info Agenda is http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2015-04-23 |
| 15:13 |
dbwells |
#topic Introductions |
| 15:14 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 15:14 |
remingtron |
#info remingtron = Remington Steed, Hekman Library (Calvin College) |
| 15:14 |
jeffdavis |
#info jeffdavis = Jeff Davis, Sitka |
| 15:14 |
berick |
#info berick Bill Erickson |
| 15:14 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 15:14 |
csharp |
#info csharp = Chris Sharp, GPLS |
| 15:14 |
berick |
oops, forgot to add KCLS |
| 15:14 |
csharp |
#info berick is with KCLS, y'all |
| 15:15 |
dbs |
#info dbs = Dan Scott, Laurentian University |
| 15:15 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 15:15 |
phasefx |
#info phasefx = Jason Etheridge, Equinox |
| 15:15 |
berick |
heh |
| 15:15 |
bshum |
#info bshum = Ben Shum, Bibliomation |
| 15:16 |
dbwells |
ok |
| 15:16 |
dbwells |
#topic Action Items from Last Meeting |
| 15:16 |
dbwells |
#info berick, gmcharlt, and eeevil will add a response to the chromium localhost ws bug |
| 15:17 |
berick |
yeah, they shut everyone out |
| 15:17 |
eeevil |
#info eeevil Mike Rylander, ESI |
| 15:17 |
gmcharlt |
#info gmcharlt Galen Charlton, ESI |
| 15:17 |
dbwells |
berick: What exactly does that mean for our concerns? |
| 15:18 |
dbwells |
We're out of luck, or something else? |
| 15:18 |
berick |
that we have limited (no?) ability to affect change |
| 15:18 |
jeff |
https://code.google.com/p/chromium/issues/detail?id=378566#c77 is the best summary. |
| 15:18 |
eeevil |
dbwells: honestly, not much, given https://news.ycombinator.com/item?id=9210484 |
| 15:18 |
dbs |
"Star the bug and maybe we'll think about it" |
| 15:18 |
eeevil |
IMO, I should say |
| 15:18 |
jeff |
> we will not be making action to block these loads until there is a viable, standards-track (although perhaps not necessarily yet standardized) solution that enhances security and preserves utility |
| 15:18 |
jeff |
> If you currently rely on such communication, you MUST be prepared to update your products at a point in the future to whatever is developed to mitigate these issues. The current solution IS NOT viable long-term. |
| 15:20 |
jeff |
The sentence before that is a bit annoying: |
| 15:20 |
jeff |
> Discussion about what a viable long-term path means will happen in the W3C. The most likely place for this discussion is where it was first considered - public-webappsec@. However, public-webappsec@ is presently not chartered for this discussion. |
| 15:20 |
jeff |
essentially, "the list where we think this discussion belongs is not currently charted for this discussion" |
| 15:21 |
dbwells |
Does someone want to summarize an update with a #info tag? I'm not qualified to comment on this at all, I think. |
| 15:21 |
berick |
so when this discussion, which has no place to exist, happens, we can potentially contribute. |
| 15:22 |
dbwells |
Ok, I'm starting to understand the situation now |
| 15:22 |
berick |
jeff: where are you reading that? |
| 15:22 |
jeff |
There were some alternate approaches brainstormed in Boston (useful for cases where you're not able to run Hatch but still want receipt printing) which could bear further brainstorming. For the most part, we're in a "wait and see, remain aware, star the issue and keep our ears/eyes open" mode. |
| 15:22 |
berick |
right |
| 15:22 |
jeff |
berick: mostly from comment 77 on the issue in question -- I linked above: https://code.google.com/p/chromium/issues/detail?id=378566#c77 |
| 15:23 |
berick |
jeff: oh, duh, thanks |
| 15:24 |
dbwells |
ok, so |
| 15:24 |
dbwells |
#info For the most part, we're in a "wait and see, remain aware, star the issue and keep our ears/eyes open" mode. |
| 15:24 |
dbwells |
Any more on this before moving ahead? |
| 15:24 |
jeff |
Not from me. |
| 15:24 |
berick |
nor from me |
| 15:24 |
jeff |
I'm interested in further discussions on the subject at the conference. |
| 15:25 |
eeevil |
+1 to that |
| 15:25 |
dbwells |
#topic OpenSRF Release Update |
| 15:25 |
dbwells |
Nothing in the agenda, any update on that? (gmcharlt, or others)? |
| 15:26 |
gmcharlt |
#info gmcharlt will cut an OpenSRF release by the EG conference - or AT the conference, if it comes to it |
| 15:26 |
dbwells |
gmcharlt++ # thank you |
| 15:27 |
dbwells |
moving on... |
| 15:27 |
dbwells |
#topic Evergreen Release Updates |
| 15:28 |
dbwells |
berick: please go ahead, even just to reiterate what's already in the agenda, if you don't mind. |
| 15:28 |
berick |
sure thing |
| 15:28 |
berick |
2.8.0 was set loose upon the world |
| 15:28 |
berick |
2.8.1 probably after the EG conf, unlesss there's a need to do it sooner |
| 15:29 |
kmlussier |
If there were no conference, what we typically be the point release date? |
| 15:29 |
bshum |
So actually I was hoping to get a release out sooner for 2.7 |
| 15:30 |
dbwells |
berick: There was the bug I worked on with bshum affecting fine generation for catch-up fines on lost-returned items. I'd hope to see that out sooner rather than later. |
| 15:30 |
bshum |
Since there's some backlog of stuff |
| 15:30 |
jeff |
kmlussier: calendar says April 15, May 20 |
| 15:30 |
bshum |
And yeah, some pretty critical fixes for 2.8 |
| 15:30 |
kmlussier |
IIRC, there has been a fine generator fix since the release, which seemed like it might be important to get out. |
| 15:30 |
bshum |
That we probably don't want people upgrading into |
| 15:30 |
kmlussier |
Oh, sorry. dbwells is too quick for me. :) |
| 15:30 |
eeevil |
and there's the common-attribute search speed fix |
| 15:30 |
berick |
kmlussier: 3rd Wed. of each month, I believe |
| 15:30 |
eeevil |
which is running nicely in production |
| 15:31 |
kmlussier |
eeevil: That's good news. |
| 15:31 |
bshum |
We're a bit behind schedule, but maybe we can commit to getting a release cut this month anyways. |
| 15:31 |
berick |
alright.. sounds like we may have a release to cut sooner than later |
| 15:32 |
* jeff |
bookmarks the descripton on commit 749e63f |
| 15:32 |
pinesol_green |
[evergreen|Dan Wells] LP#1443952 Move overdue restore above lost void/adjustment - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=749e63f> |
| 15:32 |
csharp |
eeevil: were you able to assuage your concerns about the inverse use case with uncommon attributes still working quickly? |
| 15:32 |
kmlussier |
Also, when I did the web site updates, I didn't put 2.6 in security release only mode because we hadn't reached a full year after its release. Should it get one more point release before we move it to security only? |
| 15:32 |
dbwells |
We've got one more standard release for 2.6. I'm game to cut it whenever bshum and berick are ready with theirs. |
| 15:32 |
berick |
next week works for me |
| 15:33 |
eeevil |
csharp: in a word: yep |
| 15:33 |
csharp |
eeevil++ # awesome |
| 15:33 |
bshum |
Next week sounds good to me too actually. Wednesday? |
| 15:33 |
dbwells |
Wednesday works for me. |
| 15:33 |
berick |
same here |
| 15:34 |
dbwells |
#info 2.8.0 was set loose upon the world |
| 15:35 |
dbwells |
#agreed 2.8.1 and other maintenance releases will be cut on Wednesday, April 29 |
| 15:35 |
dbwells |
#topic QA Discussion |
| 15:36 |
berick |
i added that... |
| 15:36 |
jeff |
berick++ |
| 15:36 |
berick |
so, it didin't really take hold for 2.8 for various reasons. |
| 15:36 |
berick |
i'd really like some input on the wiki doc before we start forcing anything |
| 15:37 |
berick |
and if we're goign to start requiring QA contributions for 2.9, we need to solidify the plan now-ish |
| 15:37 |
jeff |
short of boiling the ocean, what do you think our approach should be for "this changes the behavior of something large and complex which has no existing tests"? |
| 15:37 |
jeff |
(not that this particular ocean doesn't deserve boiling...) |
| 15:38 |
berick |
jeff: do you mean areas of the code where there is no test structure? |
| 15:38 |
jeff |
case-by-case exception with a high bar, but discretion to the RM? |
| 15:38 |
jeff |
berick: yes, exactly. |
| 15:38 |
berick |
honestly, if we could people started on using the test structure we have, that would be a big win |
| 15:38 |
bshum |
Speaking of RM, who'll that be for 2.9 :) |
| 15:39 |
berick |
bshum: yeah, this conversation makes me think again about nominating RM's earlier in the process |
| 15:40 |
bshum |
Yeah, I think we should start thinking like that. |
| 15:40 |
dbwells |
If we want the RM to make calls on "tested enough"-ness, we'll more or less need the RM to approve everything. That's pretty far from what we've done before, but certainly exists in other projects, from what I'm told. |
| 15:40 |
kmlussier |
I don't feel qualified to comment on the wiki page, but if there is anything somebody like me can do to help with this, let me know. |
| 15:41 |
jeff |
dbwells: I was thinking more along the lines of "has tests == good, anyone can merge", vs "no tests because REASONS, merge is at RM discretion" |
| 15:41 |
dbwells |
jeff: makes sense, thanks for clarifying |
| 15:41 |
gmcharlt |
dbwells: from somebody who has been RM in such a kind of project... that is a big burden to put on the RM |
| 15:42 |
dbs |
Are tests in place for the web staff client, along the lines of https://docs.angularjs.org/guide/unit-testing ? |
| 15:42 |
dbwells |
gmcharlt: I can imagine. |
| 15:43 |
berick |
expanding on jeff's last comment.. "no tests because no framework exists to test this" would cover a lot things |
| 15:43 |
berick |
that would leave a fairly limited number of cases where the RM would have to decide |
| 15:43 |
gmcharlt |
now giving the RM more mental space to throw things back if not done enough -- and have those decisions not be nibbled to death by the Ducks of Merge It Now -- is something that would be a step forward |
| 15:44 |
dbwells |
the endless nibbling! |
| 15:44 |
csharp |
probably an obvious point, but it also raises the bar for a qualified RM |
| 15:44 |
jeffdavis |
Is there a tag in LP meaning "has code, needs tests"? |
| 15:44 |
bshum |
jeffdavis: needsignoff ? |
| 15:45 |
jeffdavis |
Do we want something more specific? |
| 15:46 |
* gmcharlt |
is inclined to think so - at least to try it out |
| 15:46 |
jeffdavis |
Signoff to me implies "I've tried this, it works on my system." |
| 15:46 |
gmcharlt |
"needstest"? |
| 15:46 |
jeff |
needstests? needsqa? |
| 15:46 |
gmcharlt |
er, needstests |
| 15:46 |
gmcharlt |
(not One Test To Rule Them All) |
| 15:46 |
* csharp |
is having deja vu |
| 15:46 |
jeff |
csharp: that might be bad. is it bad? |
| 15:47 |
dbs |
#qualityisjob1 |
| 15:47 |
kmlussier |
dbs++ |
| 15:47 |
jeffdavis |
heh |
| 15:47 |
csharp |
jeff: I thought we'd had this same discussion, but it was probably for another LP tag :-) |
| 15:48 |
gmcharlt |
csharp: different tag |
| 15:48 |
dbwells |
Well, this topic could be a meeting unto itself, but we need to keep moving. These are good thoughts, so feel free to add them as ideas to the wiki document, or keep chewing on them, and we can reconvene the conversation during the conference. Does that sound alright? |
| 15:48 |
csharp |
gmcharlt: thanks ;-) |
| 15:48 |
bshum |
dbwells: +1 to discussing at the next dev meeting (which is likely at conference) |
| 15:49 |
* gmcharlt |
tosses out a wild idea |
| 15:49 |
gmcharlt |
do we want to make QA the Official Theme (TM) of the dev portion of hackfest/ |
| 15:49 |
gmcharlt |
? |
| 15:49 |
jeff |
dbs: there are some tests for the angular bits, using karma. commit 75e466e contains one example. i can't say what coverage is like. |
| 15:49 |
pinesol_green |
[evergreen|Bill Erickson] LP#1402797 browser client interval parser - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=75e466e> |
| 15:50 |
|
bmills1 joined #evergreen |
| 15:50 |
jeff |
gmcharlt: if nothing came out of the hackfest but every interested contributor was better equipped to write tests... i'm not sure i'd be disappointed. |
| 15:51 |
* gmcharlt |
sources a troop of cats to give out at the conferences |
| 15:51 |
gmcharlt |
very special cats |
| 15:51 |
gmcharlt |
cats who hiss ... if one does a git push with adding something to t/ |
| 15:51 |
gmcharlt |
*without |
| 15:51 |
jeffdavis |
"hiss" is, fortunately, gentler than I had anticipated |
| 15:51 |
* eeevil |
dons his headphones of hiss avoidance |
| 15:52 |
dbwells |
gmcharlt: I'd be up for QA time during the hackfest. |
| 15:52 |
csharp |
#info gmcharlt's Cats of Doom: http://cat.evergreen-ils.org.meowbify.com/ |
| 15:52 |
jeff |
"QA time" might be easier to pull off. :-) |
| 15:53 |
jboyer-isl |
I could certainly use an intro. I felt a little bad about how much went into the "delete acpl" commits without any tests but human ones. |
| 15:53 |
* gmcharlt |
is more than happy to put together some starting material for a QA time |
| 15:53 |
dbwells |
#action AllTheDevs will read and think about berick's QA page, and come to the conference ready to discuss and take action |
| 15:53 |
berick |
you_all++ |
| 15:54 |
kmlussier |
you_all++ |
| 15:54 |
jeff |
too late for meetbot, but there is a thread on the localhost websockets thing that might be worth reading for those keeping tabs: https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0135.html |
| 15:54 |
dbwells |
New Business |
| 15:54 |
dbwells |
#topic berick proposes we vote on a set day / time for monthly meetings |
| 15:55 |
jeff |
+1 |
| 15:55 |
bshum |
+1 |
| 15:55 |
bshum |
We used to do that though. |
| 15:55 |
bshum |
It didn't always work out, but we can try again. |
| 15:56 |
jeffdavis |
+1 |
| 15:56 |
berick |
i'm happy to post a poll |
| 15:57 |
gmcharlt |
+1 |
| 15:57 |
berick |
to see if we can get a decent looking time |
| 15:57 |
bshum |
berick++ |
| 15:57 |
berick |
if it's all over the place, maybe reconsider |
| 15:57 |
dbwells |
They have all recently been at 3:00pm Eastern, but the day shifts around. Can we agree on 3:00pm already? |
| 15:57 |
kmlussier |
I'm in favor of it, but I think we should monitor it. If it looks like people forget about meetings (which is what previously happened), we may want to reconsider. |
| 15:57 |
csharp |
dbwells: works for me |
| 15:57 |
kmlussier |
However, meeting reminders should help with that issue. |
| 15:58 |
dbwells |
I guess we can just wait for the poll, too. |
| 15:59 |
jeff |
or possibly a single-option doodle poll to help determine if a given month's meeting will be lightly attended and thus should be re-scheduled. dunno. let's try a change and see. |
| 15:59 |
dbwells |
#action berick will set up a poll for a set meeting day/time for dev meetings |
| 15:59 |
dbwells |
#topic Release notes for point releases (kmlussier) |
| 15:59 |
berick |
cool, thanks everyone |
| 15:59 |
kmlussier |
I'll keep this quick. There has been some discussion here recently about adding point releases to the release notes. |
| 16:00 |
kmlussier |
I wonder if there is general consensus that we should move in this direction. |
| 16:01 |
kmlussier |
If so, I would be willing to work with berick on the 2.8 point releases to get the release notes added. |
| 16:01 |
csharp |
+1 |
| 16:01 |
jeff |
+1 |
| 16:02 |
berick |
kmlussier: like, at the bottom of the 2.8 release notes, we would append the 2.8.1. notes, then 2.8.2, etc.? |
| 16:02 |
berick |
instead of overwriting the 2.8 original notes |
| 16:02 |
dbwells |
I was going to ask something similar. |
| 16:03 |
kmlussier |
Yes, I think bshum had suggested that approach at one point. I like that idea. |
| 16:03 |
csharp |
that's what I had in my mind |
| 16:03 |
bshum |
Right, I started a new section concept for it in the rel's |
| 16:03 |
bshum |
But we have to adopt it permanently, etc. |
| 16:03 |
dbwells |
Looking at this page: http://docs.evergreen-ils.org/2.8/ , would they show up as addenda in section II? |
| 16:03 |
* bshum |
could have named it better |
| 16:03 |
kmlussier |
I dont' think we want to run a script every time we have a point release like we do for the major releases. |
| 16:04 |
bshum |
Right, I just called it "Bug Fixes" |
| 16:04 |
bshum |
But didn't name the exact number release of when they occur |
| 16:04 |
gmcharlt |
well, if it's actually fully scripted... |
| 16:04 |
jeff |
grouping by point release would probably be helpful. |
| 16:04 |
kmlussier |
Yes, I was thinking having a 2.8.1 as a section under bug fixes, then 2.8.2, etc. |
| 16:05 |
dbs |
top (most recent first) rather than bottom is more typical I think? |
| 16:05 |
csharp |
this is what postgres does: http://www.postgresql.org/docs/9.4/static/release.html |
| 16:05 |
jeff |
it's nice to have something other than launchpad/git logs confirm in which point release we think a specific bug was fixed. |
| 16:05 |
kmlussier |
dbs: Ah, yes, right. That would make sense. |
| 16:05 |
dbs |
but +1 |
| 16:06 |
dbwells |
Ok, it seems like we're generally all on the same page, and we can wait and see what kmlussier, et al come up with. |
| 16:06 |
berick |
+1 |
| 16:06 |
dbwells |
kmlussier++ |
| 16:06 |
dbwells |
Moving on to Feedback for New Features Under Development |
| 16:06 |
dbwells |
#topic Web client: Keyboard shortcut issues |
| 16:07 |
eeevil |
That's mine |
| 16:08 |
eeevil |
so, they exist. and work. except ... when an input form element is selected |
| 16:08 |
eeevil |
I'd like to get more eyes on that problem |
| 16:08 |
jeff |
since you've raised it as an issue, i'm guessing that's an inherent limitation and not just a bug? |
| 16:09 |
eeevil |
jeff: right. it seems to be, at least, a limitation of the angular wrapper to mousetrap |
| 16:09 |
eeevil |
as mousetrap itself supplies a way to make them work when form input elements (specifically, text, textarea, and select) are focused |
| 16:10 |
eeevil |
but, because angular builds the interface in stages |
| 16:10 |
eeevil |
inner-scope form elements don't get the appropriate event handlers injected |
| 16:10 |
eeevil |
(AFAICT) |
| 16:10 |
jeff |
do you have a branch or bug for those with interest? |
| 16:11 |
eeevil |
it's just all of the code. it's existed since sprint1 |
| 16:11 |
berick |
eeevil: i'm curious if you've tried stock cfp.hotkeys stuff without the local eg-navbar-template stuff in navbar.js |
| 16:11 |
jeff |
eeevil: ah, even easier |
| 16:12 |
dbwells |
#info keyboard shortcuts are failing when an input form element is selected. Suspected cause is the angular wrapper to mousetrap. eeevil is asking for more eyes on the problem. |
| 16:12 |
eeevil |
berick: since it's not creating an isolate-scope, I haven't |
| 16:12 |
berick |
so, there's hotkeys, hotkeys within angular, then our local directive to make hotkeys look a little more like how they looked in the xul client. if that last part is the problem, we could remove/modify that pretty easily, i imagine |
| 16:12 |
berick |
eeevil: k |
| 16:12 |
jeff |
Hrm. webby doesn't like F1/F2. I get a 404. Will poke further. |
| 16:13 |
kmlussier |
F1 works for me |
| 16:13 |
eeevil |
berick: right, I don't think it's your wrapper. |
| 16:13 |
berick |
eeevil: ah, ok |
| 16:13 |
eeevil |
WFM also... :) |
| 16:14 |
jeff |
logging in at https://webby.evergreencatalog.com/eg/staff/ and hitting F1 takes me to https://webby.evergreencatalog.com/circ/patron/bcsearch/webby.evergreencatalog.com/eg/staff/ |
| 16:14 |
jeff |
(off topic for meeting) |
| 16:14 |
* berick |
remapped F1 to 'switch to desktop 1' locally because I can't be bothered with modifier keys |
| 16:15 |
eeevil |
my one idea so far is to use mousetrap directly and have hotkeys wire themselves up after the UI is fully rendered |
| 16:15 |
dbwells |
Sounds like we have a couple parties interested in offering assistance here, but we should try to wrap up the meeting before we get too deep, I think. Is that alright? |
| 16:16 |
berick |
hm, it's an angular package |
| 16:16 |
berick |
i mean, it's designed for angular. |
| 16:16 |
berick |
i'm not sure how it would work w/o angular |
| 16:16 |
eeevil |
dbwells: yep, that's fine |
| 16:16 |
dbwells |
eeevil: thanks, moving along for now... |
| 16:17 |
dbwells |
#topic ACQ blanket orders proposal |
| 16:18 |
dbwells |
berick: It sounds interesting. I don't think we do anything like that here. |
| 16:18 |
kmlussier |
I think we might have some libraries that might be interested in using it. |
| 16:19 |
berick |
so, yeah, just curious if anyone else does this kind of thing. i could swear i heard the concept from non-kcls people |
| 16:19 |
berick |
but i could be crazy |
| 16:19 |
kmlussier |
One question that was raised here was what happens at end of fiscal year if they are configured to roll over encumbrances. Will the direct charges roll over too? |
| 16:19 |
berick |
kmlussier: yes, all fund debits (encumbrances in this case) are treated equally for rollover |
| 16:20 |
jeffdavis |
I'll pass along the bug to our acq folks for comment. |
| 16:20 |
berick |
thanks, jeffdavis |
| 16:20 |
kmlussier |
berick: We do have libraries that do blanket invoices. I'm thinking they might like to add then to the PO so that the funds could be encumbered before the items are received. |
| 16:20 |
csharp |
same here |
| 16:20 |
kmlussier |
s/then/them |
| 16:21 |
berick |
kmlussier: cool, that's the idea |
| 16:21 |
* kmlussier |
plans to load it on a VM when she has time |
| 16:22 |
berick |
kmlussier++ |
| 16:22 |
berick |
thanks everyone. |
| 16:22 |
dbwells |
berick: I'll ask our acq people about it, too. You never know what they might be doing to make things work :) |
| 16:22 |
berick |
dbwells: :) |
| 16:23 |
dbwells |
so, last but not least |
| 16:23 |
dbwells |
#topic Overdrive API |
| 16:23 |
kmlussier |
I added that one to the agenda. I'm still not clear as to what steps need to be taken to move it forward. |
| 16:23 |
kmlussier |
We have a lot of interest here in seeing it merged to Evergreen. |
| 16:24 |
jeff |
there were some missing parts last i looked, with regard to support in consortium and different auth methods |
| 16:24 |
jeff |
i looked just enough to say "this won't work for us", but didn't go much further. |
| 16:24 |
jeff |
have others reviewed it more? |
| 16:25 |
jeffdavis |
jeff: Would you be willing to file a bug report about that? I've done a small amount of tweaking in that regard but not a lot. |
| 16:25 |
kmlussier |
I suspect our auth methods would line up with what Sitka's using. |
| 16:25 |
jeffdavis |
LP project page is https://launchpad.net/overdrive-eg-opac, bugs can be filed there |
| 16:26 |
jeffdavis |
I can think of two pieces that might help to get more folks trying it out. |
| 16:26 |
jeffdavis |
1. Documentation. This has been on my todo list for a while. |
| 16:26 |
jeff |
jeffdavis: can you summarize your environment with regard to auth methods, what patron identifier is used, and if you have just a single overdrive account for the entire consortium or if you have per-system, and if there's any use of "overdrive advantage" (where systems participate in a large collection but can then ALSO add items that only their patrons get)? |
| 16:26 |
jeffdavis |
2. Testing credentials that can be shared among EG developers. |
| 16:26 |
dbwells |
#link https://launchpad.net/overdrive-eg-opac |
| 16:28 |
dbwells |
jeffdavis: I think testing credentials would be great. I'm not sure how many of us have access otherwise to OverDrive. |
| 16:28 |
* csharp |
might be able to get credentials, but not sure if he could share them :-/ |
| 16:28 |
jeffdavis |
I can commit to contacting Overdrive about that. |
| 16:29 |
jeff |
My experience with getting API access from them (prod and/or testing) has been... yeah. |
| 16:29 |
dbwells |
#info jeffdavis suggests that any potential testers file bugs at the link given above |
| 16:30 |
jeffdavis |
They do have a testing environment which in theory shold not be tied to anyone's "real" OverDrive accounts, so it's at least a theoretical possibility, IIUC. |
| 16:30 |
kmlussier |
Thanks all! |
| 16:30 |
* kmlussier |
needs to disappear |
| 16:30 |
dbwells |
#action jeffdavis will pursue contacting OverDrive to ask about test credentials / a test environment |
| 16:30 |
* csharp |
too |
| 16:31 |
dbwells |
Ok, wrapping things up unless someone speaks up... |
| 16:31 |
jeffdavis |
jeff: we have two OverDrive accounts, each used by a different chunk of our libraries |
| 16:31 |
jeffdavis |
I should add that we have this code in production for all our OD subscriber libraries |
| 16:32 |
jeffdavis |
auth is based on patron barcode, some libraries require PIN to be checked and others don't |
| 16:32 |
jeffdavis |
happy to go into more detail, but dunno if we want to do that as part of this meeting? |
| 16:32 |
jeff |
just after is fine. let's let dbwells #endmeeting :-) |
| 16:33 |
dbwells |
jeffdavis: I'm interested in at least seeing this in action at some point. |
| 16:33 |
dbwells |
Ok, thanks all. |
| 16:33 |
dbwells |
#endmeeting |
| 16:33 |
pinesol_green |
Meeting ended Thu Apr 23 16:33:36 2015 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:33 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-04-23-15.13.html |
| 16:33 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-04-23-15.13.txt |
| 16:33 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-04-23-15.13.log.html |
| 16:33 |
bshum |
dbwells++ |
| 16:33 |
jeff |
dbwells++ |
| 16:33 |
jeffdavis |
dbwells++ |
| 16:33 |
|
mglass_ joined #evergreen |
| 16:33 |
jeff |
jeffdavis: what method do you use for overdrive to auth your patrons? |
| 16:34 |
remingtron |
dbwells++ |
| 16:34 |
jeff |
(i may have asked this before -- i should check logs) |
| 16:35 |
jeffdavis |
the API code follows the patron auth process described here: http://developer.overdrive.com/apis/patron-auth |
| 16:36 |
jeff |
checked logs, don't see that i've asked. |
| 16:36 |
jeffdavis |
Overdrive itself has historically authenticated against our SIP server |
| 16:36 |
jeff |
jeffdavis: outside of the integration you've done, or before you did that integration, how did you auth? |
| 16:36 |
jeff |
ah. |
| 16:36 |
jeff |
[involuntary cringe] |
| 16:36 |
jeff |
do you still maintain a SIP connection with OverDrive? |
| 16:37 |
jeffdavis |
yes |
| 16:38 |
jeffdavis |
the API integration should allow patrons to do checkouts etc via the TPAC, so in theory no SIP would be required |
| 16:38 |
jeff |
and in your environment, when you make the POST to /patrontoken, does OverDrive then make a SIP query to verify the values you provided for username= and password=? |
| 16:39 |
jeffdavis |
er, sorry I'm wrong there |
| 16:39 |
jeff |
If there's no call (SIP or otherwise) being made on the backend by OverDrive to Evergreen, then why does the value of password_required matter? |
| 16:39 |
jeff |
Ah, okay. |
| 16:39 |
jeffdavis |
(trying to order my thoughts, which is always a pain where OD is concerned :) |
| 16:40 |
jeffdavis |
we have some libraries where password is required, and some where it is not |
| 16:40 |
|
mglass joined #evergreen |
| 16:40 |
jeff |
we require patrons to log in with their evergreen username+password or barcode+password, but OverDrive never sees anything other than an opaque token representing the patron (they also get their email address if the patron provides it when making a hold request) |
| 16:40 |
jeff |
so the ways in which i've thought about overdrive integration are different from the current implementation that you have in production. |
| 16:41 |
jeff |
i'm just trying to wrap my head around how it works in your environment vs ours. |
| 16:41 |
|
TaraC joined #evergreen |
| 16:41 |
jeffdavis |
I know the Co-op manages OD subscription some libraries where "authentication" is based on barcode pattern, rather than on a list of actual valid barcodes or live authentication via SIP. |
| 16:43 |
jeff |
They [OverDrive] have begun actively discouraging that. |
| 16:43 |
jeffdavis |
I'm actually not sure whether it's true for any Sitka libraries (the Co-op handles OD licensing for some non-Sitka libraries). I should double-check that. |
| 16:48 |
jeffdavis |
I wonder if the OD API "granted auth" method is a good fit for the "opaque token" approach: http://developer.overdrive.com/granted-auth |
| 16:50 |
jeff |
Likely. |
| 16:51 |
jeff |
Looks... ugly. |
| 16:51 |
jeff |
especially "Each time users access a digital collection through EZProxy or Federated Authentication, they must select Allow Once when approving your service." |
| 16:51 |
jeff |
I'm going to re-open our dialog with OverDrive and see if I can get anywhere this time. |
| 16:52 |
eeevil |
jeff: I fixed the splash-page hotkey issue |
| 16:52 |
jeff |
eeevil++ thanks! |
| 16:56 |
jeff |
eeevil: do you know who/what uses 905$u? asking since i see your name on a commit from back in 2010 adding support for it |
| 16:56 |
jeff |
commit 7a39120 |
| 16:56 |
pinesol_green |
[evergreen|miker] support 905u (editor by barcode or usrname) in vandelay overlay/merge rules - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a39120> |
| 17:00 |
eeevil |
jeff: IIRC, there's a way to cause that to turn into the editing and creating user of the bib |
| 17:00 |
eeevil |
905 is used for overlay/edit templates |
| 17:01 |
|
bbqben joined #evergreen |
| 17:02 |
jeff |
I'm just wondering if it's something a particular library / workflow / vendor makes use of... |
| 17:02 |
jeff |
but it was 2010, so that information may be difficult to track down :-) |
| 17:04 |
eeevil |
it was, IIRC, for kcls in conjunction with marc_stream_importer |
| 17:06 |
jeff |
thanks! |
| 17:06 |
jeff |
now i can move on to pestering berick! ;-) |
| 17:08 |
eeevil |
jeff++ |
| 17:11 |
|
mmorgan left #evergreen |
| 17:22 |
|
bmills1 joined #evergreen |
| 17:39 |
|
buzzy joined #evergreen |
| 18:23 |
|
mglass_ joined #evergreen |
| 18:27 |
|
mglass joined #evergreen |
| 19:20 |
|
akilsdonk joined #evergreen |
| 21:47 |
kmlussier |
@later tell eeevil is c4859aa loaded on webby? I just retested bug 1442836 and still see the same problem. |
| 21:47 |
pinesol_green |
kmlussier: The operation succeeded. |
| 21:47 |
kmlussier |
bug 1442836 |
| 21:47 |
pinesol_green |
Launchpad bug 1442836 in Evergreen "Web staff client: Checkout for item with open circulation fails" (affected: 1, heat: 6) [Undecided,Fix committed] https://launchpad.net/bugs/1442836 |
| 21:50 |
eeevil |
kmlussier: I have personally had trouble with browser caching. I often have to open the dev tools and then shift-refresh to get everything to clear. including across browser restarts |
| 21:50 |
kmlussier |
eeevil: So if I clear my cache, you think it will resolve the issue? |
| 21:51 |
* kmlussier |
generally clears her cache on a regular basis, but can try again. |
| 21:51 |
eeevil |
yes. same thing happened to me this afternoon in that ui |
| 21:53 |
eeevil |
I'll take a screencast of it working tomorrow. and of the browser buttons working for me in firefox on linux, if you like. more data points and all that |
| 21:53 |
* eeevil |
heads away from the keyboard... |
| 21:55 |
* kmlussier |
wishes she could head away from the keyboard. :) |
| 22:03 |
|
akilsdonk joined #evergreen |
