| 00:35 |
|
boson joined #evergreen |
| 03:29 |
|
Jillianne joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
agoben joined #evergreen |
| 08:17 |
* csharp |
wonders how many other gmail users end up on the Italian Linux Society's website when clicking git.evergreen-ils.org links that break across mulitple lines |
| 08:30 |
jeff |
it's a combination of Launchpad breaking the URL across multiple lines, and some mail clients (including gmail) turning url-looking strings in text messages into links. |
| 08:31 |
csharp |
ah - that makes sense |
| 08:32 |
jeff |
so the first part of the url gets linked beause it starts with http://, and the second part gets linked presumably because it starts with a domain-looking string and in all other ways looks like a url where someone didn't include the leading "http://" |
| 08:38 |
JBoyer |
miker, good call on the TT fixes on lp 1274999, but now I'm stuck on something else; the Next link isn't appearing anymore. I tested this thing multiple times (it was annoying looking for titles with exactly 10 copies, etc...) can you see anything obviously wrong? |
| 08:38 |
pinesol_green |
Launchpad bug 1274999 in Evergreen "Next 10 Link erroneously available at the end of holdings in OPAC, intermittent " [Undecided,Confirmed] https://launchpad.net/bugs/1274999 |
| 08:39 |
JBoyer |
Or anyone else that would like to poke at templates! Feel free to tell me how I've err'd, because this is maddening. :/ |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:42 |
JBoyer |
D: The worst! Works as expected on a migration server, falls over on dev and production. Sparta? This is madness! |
| 08:44 |
csharp |
JBoyer: is there a good concerto record to test on? |
| 08:45 |
csharp |
nevermind - I found one |
| 08:46 |
JBoyer |
You need a couple, one with exactly copy_limit (usually 10) copies, and one with more than that |
| 08:48 |
Stompro |
jeffdavis, is the Sitka new items carousel for wordpress plugin available for others to use? |
| 08:52 |
csharp |
JBoyer: with miker's branch I'm not seeing the "Next X" link either, if that helps |
| 08:55 |
JBoyer |
csharp, miker, even with my branch they're not working correctly on 2/3 servers here. For instance: http://evergreen.lib.in.us/eg/opac/record/8205944 has no link, but 15 copies. Put mig. in from of evergreen and it does work. :( |
| 08:55 |
csharp |
actually, I'm not seeing it with your branch either |
| 08:55 |
JBoyer |
Same changes! |
| 08:55 |
csharp |
yeah - I can confirm that behavior on my master test server |
| 08:56 |
csharp |
if I revert both commits, it works |
| 08:56 |
JBoyer |
Well, "works," that's where you need a record with total copies == copy_limit. |
| 08:57 |
csharp |
well, I mean that the link reappears |
| 09:00 |
JBoyer |
Well that's embarrassing... The mig server where I monkey patched this to test has ctx.copy_offset + ctx.copy_limit < total_copies, but my patch has ctx.copy_offset + ctx.copy_limit > total_copies which is completely backward... |
| 09:00 |
JBoyer |
csharp++ for looking. |
| 09:01 |
* JBoyer |
goes to fix the branch, and our servers. |
| 09:02 |
csharp |
JBoyer: happy to help! |
| 09:05 |
miker |
JBoyer: sorry for not testing the branch, I just wanted to clean up the syntax. feel free to squash my commit into yours if you keep it |
| 09:06 |
JBoyer |
I'm definitely making your changes also. And it's evident *I* didn't fully test the branch either, so no harm there. :/ |
| 09:07 |
JBoyer |
I'll probably force update my branch to have a single commit that matches your changes (AND work), but if you'd like to sign off on it after that that would be great. |
| 09:21 |
|
yboston joined #evergreen |
| 09:28 |
|
kmlussier joined #evergreen |
| 13:19 |
mmorgan |
I do know about that "Request Item" function, and that it does not set notifications. AFAIK, these holds were not placed that way. |
| 13:29 |
rjackson_isl |
There is still an open bug where SMS carrier can be left blank and have Hold Notification Format set to SMS with a Defalt SMS/Text Number entered - bug 1098685 |
| 13:29 |
pinesol_green |
Launchpad bug 1098685 in Evergreen "User can select SMS notify without providing a valid address" [Undecided,Confirmed] https://launchpad.net/bugs/1098685 |
| 14:16 |
bshum |
well, for giggles, Debian Stretch (9.0) testing has not yielded a working OpenSRF. It blows up with the libraries and can't find the stuff to start up opensrf.math or dbmath processes. So I guess that's changed somewhere, somehow. |
| 14:20 |
bshum |
On the plus side, the ejabberd 16.x stuff we wrote for Xenial seemed to work, along with the basic packages from xenial too for defining what to install. |
| 14:47 |
Stompro |
rjackson_isl, I hate that bug. |
| 15:16 |
|
bmills joined #evergreen |
| 16:08 |
kmlussier |
@dessert [someone] |
| 16:42 |
|
dkyle1 joined #evergreen |
| 16:43 |
|
_bott_1 joined #evergreen |
| 16:53 |
|
Jillianne joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:05 |
Bmagic |
I just received a feature request where the staff would like to be able to place a copy level hold on a copy from the item status screen. Any thoughts on that idea? |
| 17:29 |
Stompro |
Bmagic, I think you can already do that, right click -> request item. |
| 00:34 |
|
eady joined #evergreen |
| 04:42 |
|
Guest25107 joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 06:56 |
|
kmlussier joined #evergreen |
| 07:01 |
kmlussier |
Good morning #evergreen! |
| 07:01 |
kmlussier |
@coffee [someone] |
| 10:27 |
pinesol_green |
[evergreen|Galen Charlton] LP#1666933: note that the minimum supported Pg version is 9.3 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=215bb67> |
| 10:39 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Some corrections to hatch information in 2.12 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1a631f8> |
| 10:44 |
berick |
kmlussier: hatch doc changes look good |
| 10:44 |
bshum |
"Evergreen 2.8 has been tested on..." (it's said 2.8 since forever. Should we just make it just say "Evergreen" and omit the specific version number?) |
| 10:44 |
bshum |
In the README for Linux distro support |
| 10:44 |
kmlussier |
Well, I can say with confidence that 2.8 has been tested on all those distros. |
| 10:45 |
kmlussier |
2.12? Not so sure. |
| 10:45 |
bshum |
Fair... but kind of meaningless in all these current README docs |
| 10:45 |
bshum |
For newer versions anyways |
| 10:45 |
bshum |
So maybe it shouldn't say that either |
| 10:48 |
kmlussier |
Sounds good to me |
| 10:48 |
Bmagic |
Anyone created a report that shows an "average age" of groups of items, on a shelf for example? |
| 10:49 |
csharp |
Bmagic: interesting that you bring that up because we had a similar request this week (it was for a meeting that passed before I got to it, though, so I didn't create it) |
| 10:49 |
gmcharlt |
Pg t/ tests pass on both newly seeded and upgraded-from-2.11.3 databases |
| 10:49 |
csharp |
our request was "what is the average life of audiobooks in PINES" |
| 10:49 |
Bmagic |
csharp: I am working on it, but I don't think its possible with the report engine |
| 10:50 |
csharp |
it might be view-worthy |
| 10:52 |
bshum |
csharp: I'll take that approach in mind as I toy with wording (and other stuff) in the README. I'm getting ISOs for Wheezy, Jessie, and the new thing (Stretch) to try some stuff out |
| 10:53 |
bshum |
With Stretch frozen, I figure it's time to play with Debian 9.0 and start finding out what fun adventures await... |
| 10:54 |
gmcharlt |
OK, active pull request for bug 1666928 for review ASAP, please |
| 10:54 |
pinesol_green |
Launchpad bug 1666928 in Evergreen "Build tests are failing for Overdrive and OneClickdigital modules" [Low,Confirmed] https://launchpad.net/bugs/1666928 |
| 10:54 |
gmcharlt |
or rather, would be if Launchpad DID NOT KEEP TIMING OUT |
| 10:54 |
gmcharlt |
so, I'd like to request review and merge of user/gmcharlt/lp1666928_deal_with_failing_tests |
| 11:03 |
kmlussier |
gmcharlt: works for me. I'll merge it in a sec |
| 11:05 |
|
mmorgan joined #evergreen |
| 11:05 |
berick |
not an issue for Hatch, but certainly put pressure on localStorage for non-hatch users |
| 11:07 |
kmlussier |
gmcharlt: done |
| 11:08 |
pinesol_green |
[evergreen|Galen Charlton] LP#1666928: fix build tests for ebook API Perl modules - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8dce9e6> |
| 11:25 |
|
khuckins_ joined #evergreen |
| 11:35 |
jeffdavis |
bah, thanks for that fix gmcharlt |
| 11:36 |
gmcharlt |
jeffdavis: you're weclome! |
| 11:38 |
dbs |
gmcharlt: nice find on relator maps, id.loc.gov would be a good way to go. |
| 11:39 |
* dbs |
throws bug 1584891 onto the heap, but it should have a test :/ |
| 11:39 |
pinesol_green |
Launchpad bug 1584891 in Evergreen "marc_export -i gives incorrect record length in the leader when call numbers include UTF8 characters" [Undecided,Confirmed] https://launchpad.net/bugs/1584891 |
| 11:57 |
|
sandbergja joined #evergreen |
| 12:06 |
* dbs |
is pretty sure he fixed that problem last year but can't find the bug or branch so... |
| 15:44 |
kmlussier |
Would be nice if the only known web client issue was that surveys are inaccessible from the patron account. |
| 15:44 |
berick |
you don't /have/ to update it ;) |
| 15:45 |
tsbere |
kmlussier: Define all other web client issues as "features" and hope nobody notices? ;) |
| 15:45 |
kmlussier |
heh |
| 15:46 |
kmlussier |
We might get more libraries willing to test it in production. |
| 15:48 |
* kmlussier |
starts to write 'the ability to delete patrons via the web client is missing.' Quickly corrects it to say 'the ability to delete patron accounts...' |
| 15:48 |
|
khuckins__ joined #evergreen |
| 15:49 |
mmorgan |
Heh. That former might be pretty popular... |
| 15:49 |
kmlussier |
bug 1517595 |
| 16:50 |
csharp |
gmcharlt++ # ha! |
| 16:54 |
* kmlussier |
thinks bug 1437106 has been resolved, but hasn't tried keyboard shortcuts in the web client in months. |
| 16:54 |
pinesol_green |
Launchpad bug 1437106 in Evergreen "keyboard shortcuts in the web staff client" [Undecided,Confirmed] https://launchpad.net/bugs/1437106 |
| 16:54 |
kmlussier |
It might be a good thing for somebody tot test during Bug Squashing week to see if it's still an issue. |
| 16:55 |
berick |
Stompro++ # bug 1667115 -- I keep meaning to do something about that.. |
| 16:55 |
pinesol_green |
Launchpad bug 1667115 in Evergreen "Log Noise - retrieve config.hard_due_date called with no ID..." [Undecided,New] https://launchpad.net/bugs/1667115 |
| 17:00 |
kmlussier |
berick: bug 1472316 was covered by the Hatch Omnibus bug, right? |
| 17:00 |
pinesol_green |
Launchpad bug 1472316 in Evergreen "Enabling/Disabling Hatch in browser client causes loss of settings" [Undecided,New] https://launchpad.net/bugs/1472316 |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
berick |
kmlussier: yeah, i'd say so. the "copy settings to hatch" and "copy settings to local storage" actions provide a manual solution to the problem. |
| 17:02 |
berick |
we may eventually want to automate that, but it's at least work-around-able now |
| 17:02 |
kmlussier |
Hooray for successful tests! |
| 17:05 |
mmorgan |
Yay!! |
| 17:06 |
gmcharlt |
berick: heh, although "copy settings to Evergreen server" also looks attractive :) |
| 17:06 |
gmcharlt |
though just for actual workstatino settings, not cases like the tag table where we're just using local storage as a fast cache |
| 01:32 |
|
Jillianne joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 07:29 |
|
Dyrcona joined #evergreen |
| 07:42 |
csharp |
c0c60f45 |
| 07:42 |
pinesol_green |
csharp: [evergreen|erickson] use the event def template for the bill note (thanks, miker) instead of using a param. Created a system billing type of Notification Fee, also so none is needed via event param. Added first billing type const (yay). - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c0c60f4> |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
rhamby |
there's a strange moment when you're going through the stock test data and find a Goodread review you wrote in a 520 tag of a bib |
| 08:57 |
Dyrcona |
Callender_++ gmcharlt++ # They know why. :) |
| 08:57 |
Dyrcona |
rhamby++ # That's funky. :) |
| 08:58 |
* Dyrcona |
is about to let staff back into the client... |
| 09:33 |
|
kmlussier joined #evergreen |
| 09:35 |
kmlussier |
Good morning #evergreen! |
| 09:38 |
mmorgan |
kmlussier: Good Morning! |
| 09:39 |
kmlussier |
bshum and I spent a bit of time last night looking into perl live test failures resulting from new records added to the test dataset. |
| 09:40 |
kmlussier |
bshum has a branch he posted at https://bugs.launchpad.net/evergreen/+bug/1541559/comments/19 that addresses the current perl live test failures that came from the new ebook records, but doesn't address the PgTAP test that had previously been failing. |
| 09:40 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,Fix committed] |
| 09:41 |
kmlussier |
I'm wondering if anyone has other ideas for loading new records to the dataset so that it doesn't move copy numbers around in a way that breaks our tests. I'm not sure bshum's branch is the best long-term solution. |
| 09:52 |
tsbere |
kmlussier: I have ideas....that may not work at all for what I am assuming the problem may be. :/ |
| 09:55 |
* tsbere |
isn't actually 100% positive what the issue is |
| 09:55 |
kmlussier |
tsbere: Well, I'm hoping for a long-term solution that might allow us to add bib records to the test data in a way that puts them to the back in the line so that they don't disrupt the ids for the existing test records. |
| 09:56 |
kmlussier |
tsbere: The issue is that when we add new bib records to the test dataset, it shifts the copy ids around in such a way that the tests are no longer pointing to the correct data. |
| 09:56 |
kmlussier |
I don't know that the ideal, long-term solution is something we can put in place for today's beta release. |
| 09:57 |
bshum |
tsbere: http://testing.evergreen-ils.org/~live/test.24.html <-- it shows up here in the recent live test runs. Test 2 dies, so does 3, 4, 9 (yikes neg balances), and 14. |
| 09:57 |
bshum |
Due to the shifted copies as kmlussier says |
| 09:57 |
* tsbere |
takes a quick look at things and throws his previous ideas out the window |
| 10:00 |
kmlussier |
@coffee |
| 10:00 |
* pinesol_green |
brews and pours a cup of Panama Gesha 2011, and sends it sliding down the bar to kmlussier |
| 10:03 |
tsbere |
I have another idea, but I want to check something first before I elaborate |
| 10:08 |
dbs |
hmm, I'm not surprised checking for a specific database ID (like in 02_simple_circ.t) isn't robust. bshum's approach is expedient, but we should pursue a better longer-term fix post-beta? |
| 10:10 |
tsbere |
I actually wonder why the extra bibs being moved further down is fixing things. Or is this a "the call numbers got moved around due to located URIs" issue? |
| 10:10 |
bshum |
dbs: I've been wondering if we shouldn't consider either adapting the test data to always create specific copies that are intended for passing the tests properly, and leave the rest random, or if we need to make the whole thing less randomly generated to begin with. and do X bibs random, Y bibs more specifically, and Z bibs exactly one way |
| 10:10 |
dbs |
tsbere: it's how we create copies |
| 10:11 |
dbs |
tsbere: when we had one set of bib records, it was easy enough to say "Create a batch of call numbers, and then a batch of copies, based on this set of MARC" |
| 10:11 |
bshum |
but then I worry about curbing the helpfulness of the tests |
| 10:11 |
JBoyer |
I don't actually see any benefit to the random generation and think that a fully hard coded test set would make things a lot simpler in the long run. (Especially in those instances where someone resets a server every day, say, and goes to some lengths to make sure everything ends up the same... ;) ) |
| 10:12 |
dbs |
bshum: well, looking at 02-simple_circ.t, I'm not convinced it's a great test either |
| 10:12 |
bshum |
dbs: That too crossed my mind :) |
| 10:12 |
JBoyer |
Then ids in failed tests also become a lot more useful. |
| 10:12 |
dbs |
JBoyer: here's the thing, the call numbers and barcodes are already unique |
| 10:13 |
dbs |
so using the database IDs in the tests is probably not a great practice |
| 10:13 |
dbs |
JBoyer: they're not randomly generated, they have a very specific pattern |
| 10:13 |
JBoyer |
That's also true. |
| 10:14 |
* csharp |
votes for *not* relying on DB serial IDs for tests |
| 10:14 |
bshum |
Given that the generated call numbers and barcodes are based on the bib ID numbers right? Isn't it safe to assume to they'll usually generate out the same way as long as the bib order loading proceeds as expected? |
| 10:14 |
bshum |
Well maybe not, it is a little random I guess |
| 10:14 |
* bshum |
stops talking and runs to his next meeting |
| 10:15 |
dbs |
bshum: yeah, database doesn't guarantee specific ids when it hands out serial types, it just ends up that way |
| 10:15 |
tsbere |
So, looking at things *very* quickly, I suspect that just skipping the marcxml_import table (insert directly like the auth_concerto.sql file does) and putting the various "assets" lines after the appropriate "bibs" line in load_all would be at least a little more robust to future changes. |
| 10:15 |
JBoyer |
Agreed on not depending on ids, that's not why I'd like a more static sample. We've considered putting together a small static set for training purposes and have been (ab?)using concerto for that through the years. |
| 10:20 |
kmlussier |
For today, I'm thinking we can use bshum's approach to make the tests temporarily happy. rhamby is also working to take a similar approach with the records from bug 1665626. |
| 10:20 |
pinesol_green |
Launchpad bug 1665626 in Evergreen "Need more metarecord groups in sample dataset" [Undecided,New] https://launchpad.net/bugs/1665626 |
| 10:21 |
kmlussier |
And then we can consider other options for better loading of test data / better tests in the near-term future? |
| 10:21 |
dbs |
sounds good |
| 10:21 |
* kmlussier |
can try out tsbere's suggestion to see how it works. But not today. |
| 10:23 |
kmlussier |
As I told bshum in a pm, the good news is the fact we are seeing so many test failures speaks to the fact that we've gotten very good about adding live tests since the last time new records were added to the dataset. |
| 10:23 |
kmlussier |
We just need to robust-ify them. |
| 10:25 |
|
tspindler joined #evergreen |
| 10:29 |
dbs |
+1 |
| 10:30 |
|
Jillianne joined #evergreen |
| 10:50 |
JBoyer |
csharp, I pulled up some buckets at various sizes, the only one that was really miserable had around 4000 items in it, though even the 75 and 100-ish ones I wouldn't call "fast." :/ |
| 10:50 |
csharp |
JBoyer: hmm - weird |
| 10:50 |
rhamby |
"just when things look darkest, they go black." - John Newman |
| 10:50 |
csharp |
thanks for testing after me |
| 10:50 |
JBoyer |
Given that they're supposed to only pull details about the 30-ish or so you can see does make that seem odd. |
| 10:51 |
berick |
csharp: i don't remember if the tpac references any IDL strings, but if I had to guess, i'd say it doesn't. |
| 10:51 |
csharp |
berick: k - thanks |
| 11:46 |
Dyrcona |
"Take your hat off, boy, when you're talking to me." ;) |
| 11:47 |
kmlussier |
bshum++ |
| 11:49 |
dbs |
And then Tanya and Kim Deal got together to create The Breeders which blew my mind as a Throwing Muses/Belly/Pixies fan |
| 11:49 |
pinesol_green |
[evergreen|Ben Shum] LP#1541559: Change order of test bib loading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1a9b812> |
| 11:50 |
rhamby |
dbs: The Breeders were awesome. Iliked Belly and Pixies too but never got into Throwing Muses. |
| 12:01 |
dbs |
I was hooked when I got Garoux des Larmes on a mixtape from a girl I didn't know in California :) |
| 12:06 |
Dyrcona |
dbs: There's a Monty Python retort in there somewhere, but I'm too busy. |
| 12:27 |
csharp |
JBoyer: with one of the 100+ buckets, could you try clicking "Show Status"? |
| 12:28 |
tspindler |
Dyrcona: "And now for something completely different" |
| 12:31 |
JBoyer |
csharp, Intense unhappiness. A tiny window with no contents opened in the middle of the screen and everything is frozen. I expect it to time out soon. |
| 12:32 |
csharp |
ok - that's the complaint |
| 12:32 |
csharp |
I'm about to fire up a 2.9.1 client to see if it happens on our old test server |
| 12:32 |
JBoyer |
Or, you could click the X on the little window to make it go away, though it doesn't seem to do much. |
| 12:32 |
csharp |
actually, I'm not seeing the window - just nothing happening and frozen client |
| 12:36 |
Dyrcona |
tspindler: More like "farsical aquatic ceremonies." |
| 13:07 |
mmorgan |
Hmm. Just killed my client. Clicked Show Status while viewing the copy bucket, THEN tried to scroll down the list of items. |
| 13:07 |
csharp |
yeah - that's what we're hearing from the wild |
| 13:11 |
Bmagic |
I have not received a report about this issue but it sure sounds like it's a real issiue |
| 13:14 |
kmlussier |
OK, I've squashed rhamby |
| 13:14 |
kmlussier |
Ugh. Didn't mean to hit <enter>. I didn't really squash Rogan. |
| 13:15 |
kmlussier |
I've squashed rhamby's commit and added my own commit to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1665626-fix-metarecord-test-rebase |
| 13:15 |
rhamby |
I assumed I was being abused as normal /shrug |
| 13:15 |
JBoyer |
Sometimes I don |
| 13:15 |
JBoyer |
t like the single quote being right next to Enter. |
| 13:15 |
kmlussier |
But it isn't working for me. When I load the new bibs, I'm getting a bunch of perl live test failures. I'm putting it out there for additional eyes. |
| 13:19 |
csharp |
@who squashed rhamby? |
| 13:19 |
pinesol_green |
phasefx_ squashed rhamby. |
| 13:21 |
* kmlussier |
has a theory. |
| 13:21 |
kmlussier |
Unfortunately, it takes many minutes to test out my theories. |
| 13:42 |
|
collum joined #evergreen |
| 14:31 |
kmlussier |
All tests successful. |
| 14:32 |
kmlussier |
Now I just need to squash some commits and update the metarecord test. I should have something for somebody to merge in the next 15 minutes. |
| 14:38 |
|
collum joined #evergreen |
| 14:45 |
mmorgan |
kmlussier++ |
| 14:56 |
kmlussier |
working/user/kmlussier/lp1665626-fix-metarecord-test-rebase is ready for testing and, hopefully, signoff and merging. |
| 14:56 |
kmlussier |
Once that fix gets into master, we'll close off new code for 2.12beta and hand things over to gmcharlt to perform his magic. |
| 14:57 |
gmcharlt |
speaking of which |
| 14:57 |
gmcharlt |
the OpenSRF beta tarball will definitely be available today |
| 14:57 |
gmcharlt |
but the Evergreen one may not be until tomorrow |
| 14:58 |
kmlussier |
Works for me! gmcharlt++ |
| 14:58 |
kmlussier |
Also, bshum++ rhamby++ # Helping with tests. |
| 15:02 |
Dyrcona |
Chtulhu Fhtagn! |
| 15:03 |
Dyrcona |
At least, I can end today with most things working, thanks in part to gmcharlt and Callender_. |
| 15:03 |
kmlussier |
gmcharlt++ Callender++ |
| 16:27 |
JBoyer |
(spoiler alert: any time the total number of copies mod copy_limit == 0 you get a Next link, even if there are only copy_limit copies total.) |
| 16:27 |
kmlussier |
Speaking of release notes, I just remembered there are still some stray entries from 2.11 that need to be cleared out. |
| 16:27 |
JBoyer |
kmlussier, That's how I was leaning, miiiiight be able to squeeze it in today yet in that case. :) |
| 16:29 |
kmlussier |
JBoyer: Might be a nice thing to test during Bug Squashing week. :) |
| 16:30 |
JBoyer |
kmlussier++ |
| 16:46 |
|
hbrennan joined #evergreen |
| 16:48 |
bshum |
All tests pass for me in the branch |
| 16:48 |
bshum |
Anyone else testing and signing off to push? |
| 16:48 |
* bshum |
will go ahead and get it in otherwise |
| 16:50 |
* bshum |
whistles a happy tune |
| 16:52 |
pinesol_green |
[evergreen|Rogan Hamby] LP#1665626: adding new records to the meta group and breaking into new file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ecb690> |
| 16:52 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1665626: Change order of test bib loading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44644b4> |
| 16:52 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1665626: Update metarecord_constituent_result_reroute.pg test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=02a62c2> |
| 17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:01 |
bshum |
Aw, not fast enough. Didn't get the latest commits in that test run. Have to wait till tomorrow I guess. |
| 17:02 |
* phasefx |
can force another run |
| 17:02 |
bshum |
The build test failure though, hmm |
| 17:02 |
bshum |
That's something else |
| 17:02 |
phasefx |
oh, in that case, no need for me to force it |
| 17:03 |
bshum |
Yeah, best to figure out what that one is about too and then fix all the things |
| 17:03 |
bshum |
But later |
| 18:11 |
Dyrcona |
hm... The line where filename is set suddenly looks wrong, there's a space: $self-> ftp_get. I think that should be all right, but I'll verify. |
| 18:13 |
Dyrcona |
yeah, a space there should not be a problem. |
| 18:14 |
Dyrcona |
oh, duh. it's _ my block cursor on the line below obscured it. |
| 18:14 |
Dyrcona |
Even so, a space still seems to work from a quick test. |
| 18:14 |
* Dyrcona |
calls it a day. |
| 19:07 |
|
brahmina joined #evergreen |
| 19:43 |
bshum |
Hmm, confirmed that the make check fails on the build test with 23-OpenILS-Application-EbookAPI.t |
| 19:43 |
bshum |
At least, confirmed for me on my own VM, not just the builder test |
| 20:37 |
pinesol_green |
[evergreen|Galen Charlton] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a67e294> |
| 21:54 |
|
denials_exile joined #evergreen |
| 21:55 |
denials_exile |
In case anyone is looking for the Planet, it will be down until this is fixed: https://status.linode.com/incidents/2ns3cw1dsymf (hopefully soon, sigh) |
| 01:06 |
|
stozza joined #evergreen |
| 01:37 |
|
stozza joined #evergreen |
| 04:51 |
|
stozza joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 05:26 |
|
stozza joined #evergreen |
| 07:29 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 08:51 |
|
kmlussier joined #evergreen |
| 09:06 |
|
JBoyer joined #evergreen |
| 09:19 |
gmcharlt |
by the way, as a reminder and/or heads-up - I will be cutting the 2.5 beta release tomorrow in conjuction with Evergreen 2.12-beta |
| 09:28 |
kmlussier |
There are a few things I'm still working on with the release, so we still have a small window today where people can test/merge code if there is something they want to get into 2.12beta. |
| 09:30 |
kmlussier |
I'm planning to look again at bug 1541559, hopefully with some help from jeffdavis, but I'm at a stopping point right now because I'm getting a 500 response from the Overdrive server, which *may* be an issue on the OD side of things. |
| 09:30 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,New] https://launchpad.net/bugs/1541559 - Assigned to Jeff Davis (jdavis-sitka) |
| 09:31 |
kmlussier |
I would love to get more eyes on that code. I know it's something a lot of libraries would love to see in Evergreen. |
| 09:32 |
kmlussier |
I also don't know how many people are working today. :) |
| 09:32 |
Dyrcona |
Unfortunately, I don't think I can test it. |
| 09:32 |
kmlussier |
Dyrcona: Are you doing your database upgrade today? |
| 09:32 |
Dyrcona |
Not exactly. |
| 09:32 |
Dyrcona |
We're upgrading the O/S packages, etc. |
| 09:33 |
Dyrcona |
The database upgrade is postponed for lack of free disk space. |
| 09:33 |
kmlussier |
:( |
| 09:33 |
Dyrcona |
I'm planning to take Friday as the holiday in compensation, which dovetails nicely with vacation next week. :) |
| 09:34 |
kmlussier |
I also want to make sure all of our tests are succeeding before gmcharlt cuts the release. I'm pretty sure I told phasefx at the hack-a-way that QA test failures would be showstoppers. :) |
| 09:35 |
kmlussier |
rhamby: Did you have a chance to pull together some bib records from a metarecord group for the Concerto data? |
| 09:35 |
rhamby |
rhamby: I got the bibs pulled together for three that will join the same metarecord and don't have $n $p to avoid that issue but I haven't had time to bundle it into a patch yet |
| 09:36 |
rhamby |
kmlussier: ^^ |
| 09:36 |
* rhamby |
needs a gallon of coffee still this am |
| 09:36 |
kmlussier |
@coffee rhamby |
| 09:36 |
rhamby |
apparently |
| 09:36 |
* pinesol_green |
brews and pours a cup of Guatemala La Conception, and sends it sliding down the bar to rhamby |
| 09:37 |
kmlussier |
The other feature I had hoped to get into 2.12, but won't have a chance to test today is bug 1612752. |
| 09:37 |
pinesol_green |
Launchpad bug 1612752 in Evergreen "Feature Request: Cancel Transits, Don't Delete Them" [Wishlist,Confirmed] https://launchpad.net/bugs/1612752 |
| 09:37 |
rhamby |
all Sunday dissolved into chaose as new foster dogs (puppies) arrived at the house |
| 09:37 |
kmlussier |
We can put that one off until the next release, but I put it out there in case anyone is looking for something to test. |
| 09:37 |
rhamby |
chaos even /sigh ... it's going to be one of those typing days |
| 09:37 |
kmlussier |
Ooh, puppies! |
| 09:39 |
gmcharlt |
Stay on target! </GoldFive> |
| 10:48 |
|
Christineb joined #evergreen |
| 10:52 |
|
stozza left #evergreen |
| 11:18 |
|
jeff_ joined #evergreen |
| 11:37 |
kenstir |
JBoyer: open-ils.storage.direct.config.sms_carrier.retrieve.all does not work, it does not fail but returns an empty payload. |
| 11:37 |
kenstir |
Looking at config.pm I do not see how it would be registered, so I also tried open-ils.storage.direct.config.copy_status.retrieve.all, which also returns an empty payload. Onto the next test. |
| 11:39 |
Dyrcona |
kenstir: You tried this where? |
| 11:40 |
kenstir |
gapines |
| 11:40 |
JBoyer |
Sorry about that, when Dyrcona said storage wouldn't work that's what he meant. Requesting it through pcrud is likely what you have to do. |
| 11:40 |
kenstir |
No problem, took me a while to get my testing infrastructure bootstrapped. Trying pcrud now |
| 11:40 |
Dyrcona |
Yeah, it won't work remotely, only directly on the server talking to the private osrf router. |
| 11:53 |
|
kmlussier joined #evergreen |
| 11:55 |
kenstir |
pcrud.search.csc.atomic is not working for me yet. I feel like I'm close but getting empty array as a payload. My query is http://gapines.org/osrf-gateway-v1?service=open-ils.pcrud&method=open-ils.pcrud.search.csc.atomic&param=%22auth_token%22&param=%7B%22active%22:true%7D |
| 14:42 |
JBoyer |
Thanks for the tips everyone! |
| 14:42 |
JBoyer |
kmlussier++ |
| 14:42 |
JBoyer |
dbwells++ |
| 14:51 |
JBoyer |
preliminary testing (i.e. a hand insert of a single row in metabib.author_field_entry) does show that that's enough to get this up and going. Hmm. |
| 14:53 |
JBoyer |
How to find the "best" auth record to pull from when the bib is indexed may be interesting. OR, that could just be done at the time that authority_control_linker.pl is run, as then there'll be a $0 and it's smooth sailing... |
| 14:54 |
kmlussier |
JBoyer: Yes, I was thinking it would use whatever is in subfield 0. |
| 14:55 |
JBoyer |
Which means that everything needed to turn this on happens in metabib.reindex_something_something. |
| 15:32 |
kmlussier |
OK, I want to look at this a little more closely, but since I have Overdrive connectivity working, I would like to merge the code from bug 1541559 today for inclusion in 2.12. |
| 15:32 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,New] https://launchpad.net/bugs/1541559 - Assigned to Jeff Davis (jdavis-sitka) |
| 15:34 |
jeffdavis |
kmlussier: yay! |
| 15:34 |
kmlussier |
However, I also want to go on record as saying I have not tested OneClickDigital because our libraries do not have an subscription that I can use for testing. I just want to put that out there in case anyone has concerns about me merging the code without testing the code with the other vendor that is supported. |
| 15:35 |
kmlussier |
IIRC, I also signed off on EDI code way back in the day after only testing it with one vendor, so I think there might be precedent. |
| 15:38 |
jeffdavis |
I should note there is a minor issue with the OneClickdigital API: it does not currently work with non-numeric barcodes. This is an issue on their end, not Evergreen's. They assure me that this will be fixed with an update in early March. |
| 15:39 |
jeffdavis |
In the meantime, numeric barcodes worked fine with Oneclick for me, but it would be nice if someone else were able to test. |
| 15:58 |
jeffdavis |
One change in that branch that could definitely use some developer eyeballs is the new OpenILS::Utils::HTTPClient Perl module: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=98eff96 |
| 15:58 |
jeffdavis |
It's a utility for sending HTTP requests to external servers and handling responses, basically a wrapper around LWP::UserAgent. |
| 16:25 |
|
Jillianne joined #evergreen |
| 16:32 |
bshum |
@dessert |
| 16:32 |
* pinesol_green |
grabs some Mint Chocolate Chip Ice Cream for bshum |
| 16:39 |
stephengwills |
i'll re-make the extras and try again. thanks Ben |
| 16:39 |
stephengwills |
hi Kathy :) |
| 16:39 |
* stephengwills |
picks a few keys out of his forehead and wades back in ... |
| 16:52 |
kmlussier |
OK - I'm wrapping up testing for bug 1541559 and will be working on the fix to the metarecord test. Is there anything else anyone is reviewing or wants to have reviewed for inclusion in 2.12? |
| 16:52 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,New] https://launchpad.net/bugs/1541559 |
| 16:52 |
|
teletype01 joined #evergreen |
| 16:54 |
kmlussier |
Looks like gmcharlt is working on bug 1665933 for inclusion in tomorrow's release. |
| 16:54 |
pinesol_green |
Launchpad bug 1665933 in Evergreen "Ability to skip building staff client in make_release" [Wishlist,New] https://launchpad.net/bugs/1665933 |
| 16:54 |
kmlussier |
Also, if you want something to be reviewed, it should be something small. :) |
| 16:56 |
jeffdavis |
kmlussier++ |
| 16:58 |
kmlussier |
jeffdavis / gmcharlt: Regarding https://bugs.launchpad.net/evergreen/+bug/1541559/comments/13, in one of my earlier tests, I updated the code to https in two places. That code was in place during my first successful test. |
| 16:58 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,New] |
| 16:59 |
kmlussier |
Is that all that needs to be done to get https by default? jeffdavis, would you have concerns about setting the default there? |
| 16:59 |
|
NawJo joined #evergreen |
| 16:59 |
kmlussier |
If it doesn't work in someone's environment, they could then make the choice to change it to http using the LSE? |
| 17:01 |
* kmlussier |
tries out the change to Overdrive.pm just to make sure she's remembering that it did indeed work. |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:08 |
jeffdavis |
kmlussier: yes, changing OverDrive.pm so that the default values for circulation/discovery base URIs use HTTPS should be all that's necessary. Strictly speaking, it would be good to update the SQL changes as well since the description for those settings says "http" not "https". |
| 17:08 |
jeffdavis |
Want me to push a commit for that? |
| 17:08 |
kmlussier |
jeffdavis: Yes, please. |
| 17:56 |
jeffdavis |
HTTPS fix and CSS signoff pushed |
| 17:57 |
jeffdavis |
also updated the bug with details on the issues I had with HTTPS: https://bugs.launchpad.net/evergreen/+bug/1541559/comments/17 |
| 17:57 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,New] |
| 18:22 |
kmlussier |
If anyone is still around, I could use a signoff to the fix for our recent test failure. bug 1665626 |
| 18:22 |
pinesol_green |
Launchpad bug 1665626 in Evergreen "Need more metarecord groups in sample dataset" [Undecided,New] https://launchpad.net/bugs/1665626 |
| 18:23 |
* kmlussier |
turns her attention to jeffdavis' branch and then gets ready to cut off merging for 2.12beta. |
| 18:25 |
Dyrcona |
Well, I'm setting a temporary replacement NFS server, so no time. |
| 18:26 |
Dyrcona |
I'll probably be back asking about filesystem tree structure, but I imagine I won't get answers until the morning. |
| 18:26 |
Dyrcona |
More than full... |
| 18:27 |
bshum |
kmlussier: Let me know if I can help. |
| 18:27 |
kmlussier |
bshum: Do you want to verify that the test succeeds and sign off on/merge it? |
| 18:28 |
bshum |
kmlussier: It'll take a few minutes for me to spin up a new system. But yeah I can check it over. |
| 18:28 |
bshum |
Point me at the bug / branch |
| 18:28 |
kmlussier |
bug 1665626 |
| 18:28 |
pinesol_green |
Launchpad bug 1665626 in Evergreen "Need more metarecord groups in sample dataset" [Undecided,New] https://launchpad.net/bugs/1665626 |
| 18:28 |
kmlussier |
You'll need the new sample data for the test to work. |
| 18:36 |
kmlussier |
ebook integration will have to wait until kmlussier eats dinner. |
| 18:58 |
kmlussier |
Calling 1027 and 1028 |
| 18:59 |
bshum |
I always have to look up how to run live tests :) |
| 18:59 |
bshum |
Rebuilding a fresh DB now and then running the tests shortly kmlussier |
| 19:00 |
kmlussier |
bshum++ |
| 19:05 |
* kmlussier |
is going to put off writing release notes for now since they need to be more extensive than 'we haz e-book statuses.' |
| 19:05 |
kmlussier |
That's all about all I could handle writing right now. |
| 19:07 |
bshum |
Hmm |
| 19:07 |
bshum |
It blew up on my first runthrough |
| 19:07 |
bshum |
Some of the other tests seemed unhappy |
| 19:08 |
bshum |
Going to rebuild the DB again, start up services and retest |
| 19:08 |
pinesol_green |
Showing latest 5 of 12 commits to Evergreen... |
| 19:08 |
pinesol_green |
[evergreen|Jeff Davis] LP#1541559: eliminate duplicate entries in ebook API transaction details - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2729bbb> |
| 19:08 |
pinesol_green |
[evergreen|Jeff Davis] LP#1541559: improve display of ebook API transaction details in My Account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=45b0f2a> |
| 19:08 |
pinesol_green |
[evergreen|Jeff Davis] LP#1541559: remove non-functional sort on ebook API transaction details in My Account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1d599f4> |
| 19:08 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1541559: Minor tweaks to e-books circ in My Account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d3ada6d> |
| 19:08 |
pinesol_green |
[evergreen|Jeff Davis] LP#1541559: Use HTTPS for OverDrive requests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6d721a8> |
| 19:09 |
bshum |
Oh I see, we're testing the pgtap test. Not the perl live tests. |
| 19:09 |
* bshum |
can try that too |
| 19:10 |
bshum |
The perl live tests seem unhappier |
| 19:11 |
kmlussier |
Yes, sorry, it's the pgTap test that has been failing. |
| 19:11 |
bshum |
But maybe it's something I did wrong in my testing run |
| 19:11 |
bshum |
Or maybe it's the new bibs doing something |
| 19:11 |
kmlussier |
The perl live tests have been doing okay in the twice-daily test runs. |
| 19:17 |
bshum |
Fwiw, it passes pg tests successfully now |
| 19:17 |
bshum |
Let me try the live tests both ways to be sure and then I'll go ahead and commit it |
| 19:17 |
bshum |
But probably after I eat dinner |
| 19:21 |
bshum |
Or you know, right now |
| 19:21 |
bshum |
Cause I'm super curious... |
| 19:22 |
bshum |
Okay, so reverting the new bib change from rhamby, and the perl live test succeeds, except for something with the hold targeter. Probably a bad install on my end |
| 19:22 |
bshum |
I'll double check all my install configs to be sure the hold targeter stuff is setup right |
| 19:22 |
bshum |
This is a reinstalled system so maybe I need to update something |
| 19:23 |
bshum |
When i ran the live tests against the new test bibs, things blew up for stuff all the way down to some of the early tests with bills and circs |
| 19:24 |
bshum |
So maybe we moved a bib assignment or something for an early test |
| 19:24 |
* bshum |
goes to get dinner first now |
| 19:24 |
Dyrcona |
dinner would be nice, but the family is not home, yet. |
| 19:24 |
Dyrcona |
the wife wants to make pasta or hambugers or something. |
| 19:24 |
Dyrcona |
I hinted that she should get pizza and chicken wings on the way home. |
| 19:25 |
kmlussier |
bshum: Which tests are failing? |
| 19:26 |
Dyrcona |
What's not failing would be a shorter list for me.... |
| 19:26 |
kmlussier |
I had been thinking Rogan's new bibs got later ids, but I see they jumped ahead of a few records in the dataset. |
| 19:26 |
|
dcook left #evergreen |
| 19:28 |
kmlussier |
So, generally, when people add new records to the test dataset, I think they add a new sql file, rather than appending it to an existing sql file. Maybe we need to do that with these records to make sure it doesn't bump anything being used by the tests. |
| 19:29 |
Dyrcona |
And, they get home while I'm trying to concentrate on writing an email and the dog goes nuts barking. |
| 19:32 |
* kmlussier |
can try to make that happen while she waits for her VM to fire up. |
| 19:43 |
jeffdavis |
kmlussier: I will write release notes for the ebook API stuff, hopefully tomorrow |
| 21:00 |
bshum |
I think it's still unstamped |
| 21:01 |
kmlussier |
I didn't push those? |
| 21:01 |
kmlussier |
Huh, I know I did those. |
| 21:02 |
bshum |
I'm circling back to finishing testing the test stuff |
| 21:02 |
kmlussier |
I'm still working on that. I just fixed an issue with a missing comma. |
| 21:03 |
bshum |
Oh okay |
| 21:03 |
bshum |
:) |
| 21:30 |
Dyrcona |
I did build new clients on the replacement. |
| 21:31 |
Dyrcona |
but of course, the upgrade files are missing. |
| 21:33 |
Dyrcona |
bshum: That's what I'll do, I'll rename the xul version directory temporarily and I'll delete the old ones still hanging around on some of the servers. |
| 22:08 |
kmlussier |
To follow up on fixing our tests, bshum and I have found that the addition of any new bib records to the test dataset is busting our perl live tests. See my comment at https://bugs.launchpad.net/evergreen/+bug/1665626/comments/4 |
| 22:08 |
pinesol_green |
Launchpad bug 1665626 in Evergreen "Need more metarecord groups in sample dataset" [Undecided,New] |
| 22:09 |
Dyrcona |
Yay! more f'd up legacy server configuration that only manifests when you try to restart stuff. |
| 22:09 |
bshum |
kmlussier++ # trying to fix tests with me |
| 22:09 |
kmlussier |
I would like to hold off on merging that code until we can see if there is a way we can add bibs to the dataset without shifting the existing data. Or, maybe, we just need to accept that we have to fix up a bunch of perl live tests every time we add bibs. |
| 22:10 |
Dyrcona |
This and hardware failure is why a "simple" upgrade has taken 12 hours so far. |
| 22:10 |
kmlussier |
bshum++ |
| 22:12 |
kmlussier |
@swill Dyrcona |
| 22:12 |
* pinesol_green |
grabs a forty of Jeremiah Weed and sends it sliding down the bar to Dyrcona |
| 22:39 |
bshum |
kmlussier: This is a really terrible hack |
| 22:39 |
bshum |
But hey, it works: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/move-test-ebook-bibs |
| 22:40 |
bshum |
And all live tests succeed for me after I move the ebook bibs out of the way of being loaded the first time around |
| 22:40 |
Dyrcona |
yay. at least something works for somebody. |
| 22:40 |
Dyrcona |
Simple day of installing o/s and security updates, turns into a 3-hour tour on the SS Minnow. |
| 22:41 |
bshum |
"Those poor people..." |
| 12:00 |
dbwells |
yeah, the "reset" just deletes data above a certain id in certain tables. It isn't exactly future- or fool-proof by any stretch. |
| 12:08 |
kmlussier |
bug 1661754 seems more like a bug fix than new feature to me. Does anyone object to my backporting it? |
| 12:08 |
pinesol_green |
Launchpad bug 1661754 in Evergreen "Staff users should be prevented from marking a Long Overdue item Lost" [Undecided,Confirmed] https://launchpad.net/bugs/1661754 - Assigned to Kathy Lussier (klussier) |
| 12:11 |
berick |
dbwells: Dyrcona: yeah, i don't have any big plans. just some light griping. |
| 12:11 |
berick |
i'm going to avoi the issue for now by testing data that other scripts don't touch |
| 12:13 |
|
NawJo joined #evergreen |
| 12:18 |
miker |
kmlussier: I tend to agree. and I think there are policy decisions being made by the code that might not work for existing use cases (I have no hard examples, though) |
| 12:19 |
berick |
yeehaw, all tests pass now |
| 12:20 |
kmlussier |
berick++ |
| 12:22 |
berick |
kmlussier: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1596595-hold-target-tests-update -- i took the liberty of tagging it w/ the same hold targeter LP # |
| 12:22 |
kmlussier |
miker: Thanks. I think there is general agreement that we would like to eventually see a full-featured resolution with bug 1562061 |
| 12:22 |
pinesol_green |
Launchpad bug 1562061 in Evergreen "Marking a Long Overdue transaction Lost adds a second bill to the patron record" [Undecided,New] https://launchpad.net/bugs/1562061 |
| 12:22 |
berick |
if you want a new LP, i can add one |
| 12:23 |
kmlussier |
berick: No, I think that's fine. I'll look at that one before I move on to NawJo's and bshum's rtl-support branch. |
| 12:23 |
berick |
cool, thanks |
| 12:27 |
|
jihpringle joined #evergreen |
| 12:28 |
kmlussier |
Actually, I think I need to test this on a clean database. |
| 12:31 |
pinesol_green |
[evergreen|Galen Charlton] LP#1662902: do not re-download EDI files that failed processing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3573009> |
| 12:31 |
pinesol_green |
[evergreen|Bill Erickson] LP#1662902: do not re-download EDI files that failed parsing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=82732c5> |
| 12:33 |
jeff |
"I think that's what he says, but I need to hear it on a Maxell." |
| 12:55 |
pinesol_green |
[evergreen|Jason Boyer] Add Release Note for new helper - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb37d04> |
| 12:58 |
bshum |
NawJo++ |
| 13:00 |
NawJo |
:) |
| 13:01 |
kmlussier |
LOL - https://twitter.com/gmcharlt/status/832621006191669248 |
| 13:04 |
kmlussier |
berick: All tests successful. Huzzah! |
| 13:10 |
berick |
@bartender #evergreen |
| 13:10 |
* pinesol_green |
fills a pint glass with Hitachino Nest Japanese Classic Ale, and sends it sliding down the bar to #evergreen (http://beeradvocate.com/beer/profile/697/16429) |
| 13:11 |
pinesol_green |
[evergreen|Bill Erickson] LP#1596595 Hold targeter Perl live test repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=86cce7f> |
| 13:11 |
Dyrcona |
So, stock concerto, should I have a record match set option in vandelay? |
| 13:11 |
Dyrcona |
Do I need to make one? |
| 13:12 |
kmlussier |
Dyrcona: I usually don't set one when I'm doing imports in testing. |
| 13:12 |
kmlussier |
Especially if I know they aren't in the stock data. I just select the option to import new records, and, if a matchpoint isn't set, it sees all the records as new. |
| 13:13 |
Dyrcona |
Well it says the value enterd is invalid, but I haven't tried importing. |
| 13:13 |
kmlussier |
It should work. I do it all the time. |
| 13:14 |
Dyrcona |
OK. thanks. i'll give it a whirl. |
| 13:18 |
Dyrcona |
jabok_library++ |
| 13:19 |
Dyrcona |
Even has a URL: Digitalizovaný dokument |
| 13:19 |
kmlussier |
Huzzah again! |
| 13:20 |
Dyrcona |
So, I'll figure out how to add these to concerto after I do some more testing. |
| 13:21 |
Dyrcona |
Think I need to add copies and/or target the urls for opac testing, though. |
| 13:21 |
|
frank__ joined #evergreen |
| 13:22 |
kmlussier |
Calling 1024 and 1025 |
| 13:22 |
* Dyrcona |
thinks Prague in the Spring would make a nice setting for a Evergreen conference. |
| 15:22 |
kmlussier |
jeffdavis: Should that bug have a pullrequest tag? |
| 15:25 |
jeffdavis |
I'm not sure. There are a couple of minor issues I'm aware of and working on. |
| 15:25 |
jeffdavis |
1. Better CSS on detailed checkout/hold view in My Account, (2) occasional duplicate entries in the same place. |
| 15:28 |
kmlussier |
jeffdavis: OK, if I get it working, I'll see how polished it looks from my perspective. :) |
| 15:28 |
* kmlussier |
needs to steal some test records from NOBLE first. |
| 15:42 |
* Dyrcona |
counts backwards with Throwing Muses. |
| 15:46 |
Dyrcona |
I should have squashed those two commits into one... |
| 15:46 |
Dyrcona |
oh well. |
| 16:35 |
jeffdavis |
one sec |
| 16:35 |
jeffdavis |
overdrive has a ton of different values that you need, it's very overcomplicated |
| 16:36 |
kmlussier |
jeffdavis: Circulation API, Discovery API, Granted Authorization Redirect - are those things I need to enter now with the current functionality we have? |
| 16:38 |
jeffdavis |
Circulation API and Discovery API base URIs will default to OverDrive's production API. If you're using that API you don't need to touch those settings. If you want to use their test ("integration") API instead, you would need to add values for those settings. |
| 16:39 |
jeffdavis |
(There's probably a better way to handle that but I was trying to avoid hardcoding URIs that might change with little notice.) |
| 16:39 |
jeffdavis |
the Granted Auth one is not required for right now, that piece is not functional yet |
| 16:39 |
kmlussier |
sure |
| 16:39 |
jeffdavis |
as for the other settings... |
| 16:40 |
jeffdavis |
OverDrive will provide you with a client key and secret. You combine those and base-64 encode the result (following the instructions they provided) to get the value for the "basic token" setting. |
| 16:56 |
jeffdavis |
which would imply the need for authorization names for individual libraries |
| 16:58 |
|
Christineb joined #evergreen |
| 16:58 |
kmlussier |
Yeah, I don't think we're doing Advantage titles. |
| 17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:01 |
* kmlussier |
has to finish up for the day. I'll take another look at this over the weekend. |
| 17:01 |
kmlussier |
Oh good! The only test failure is the one rhamby and I have a plan for. |
| 17:02 |
kmlussier |
Thanks to everyone for their help with the release today! Have a nice weekend! |
| 17:02 |
jeffdavis |
kmlussier++ |
| 17:02 |
bshum |
kmlussier++ |
| 17:07 |
|
jvwoolf left #evergreen |
