| 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> |
| 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..." |
| 01:19 |
pinesol_green |
Showing latest 5 of 11 commits to Evergreen... |
| 01:19 |
pinesol_green |
[evergreen|Bill Erickson] LP#1596595 Targeter accepts a list of hold ID's - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dbcd6ec> |
| 01:19 |
pinesol_green |
[evergreen|Bill Erickson] LP#1596595 Targeter use child editor for settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=129a38b> |
| 01:19 |
pinesol_green |
[evergreen|Bill Erickson] LP#1596595 AOUS lookup batch by org id - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=85e73bc> |
| 01:19 |
pinesol_green |
[evergreen|Bill Erickson] LP#1596595 Targeter leverages batch AOUS lookups - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=895f8bd> |
| 01:19 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1596595: Stamping upgrade scripts for hold targeter refactoring - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eee584e> |
| 01:43 |
pinesol_green |
[evergreen|Jason Boyer] LP1517137: Add Permissions Missing From Stock Data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=06e1f29> |
| 01:43 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1517137: Release note entry for addition of missing permissions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7e590bd> |
| 01:43 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1517137: Stamping upgrade script for adding overlooked permissions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b3a6cba> |
| 01:59 |
pinesol_green |
[evergreen|Josh Stompro] LP#1494748 - Change pay fines link to a button & increase checkbox sizes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c222f68> |
| 01:59 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1494748: Decrease the input size on Firefox by a smidge - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ced1e6c> |
| 01:59 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1494748: Release notes entry for self check interface improvements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f9f830e> |
| 05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
kmlussier joined #evergreen |
| 07:24 |
kmlussier |
Good morning #evergreen! Happy DIG hackaway day! |
| 07:25 |
|
agoben joined #evergreen |
| 07:25 |
kmlussier |
And happy 2.12 feature freeze day! |
| 07:25 |
* kmlussier |
sees more test failures and wonders if she can break Evergreen even more today. |
| 07:33 |
kmlussier |
rhamby: Following up on our conversation last night, I have filed bug 1665626 |
| 07:33 |
pinesol_green |
Launchpad bug 1665626 in Evergreen "Need more metarecord groups in sample dataset" [Undecided,New] https://launchpad.net/bugs/1665626 |
| 07:38 |
phasefx |
kmlussier: one option may be to create the test data needed as part of the test. Some pros and cons to that, but I've tried it before with some things |
| 07:40 |
rhamby |
kmlussier: sounds good. It'll be something I can do tomorrow morning when the house is asleep :) |
| 07:41 |
kmlussier |
phasefx: Yeah, that would work too, but, either way, we should have so grouped records in the test dataset. It makes it easier to test metarecord things. |
| 07:41 |
phasefx |
kmlussier: yeah, you're right |
| 07:42 |
kmlussier |
Of course, the nice thing about making it part of the test is that you don't have to worry about the test data moving on you. On the other hand, the person who wrote the test is on vacation right now. :) |
| 08:02 |
kmlussier |
I just ran the hold targeter test that failed. It failed for me too, but I got different errors, all of which related to the metarecord hold. |
| 08:10 |
kmlussier |
I think I know what the problem is there. It's targeting metarecord 42, but with the change in parting, metarecord 42 probably is the master of a totally new record now. |
| 08:10 |
* kmlussier |
sees if she can trace it down. |
| 08:11 |
|
Stompro joined #evergreen |
| 08:12 |
|
Dyrcona joined #evergreen |
| 08:18 |
Dyrcona |
What was it Helmuth von Moltke said? "No plan survives first contact with the enemy." |
| 08:32 |
pinesol_green |
Dyrcona: Your current monologue is at least 9 lines long. |
| 08:34 |
kmlussier |
My suspicion was wrong. The metarecord is pointing to the same bib in concerto now. |
| 08:38 |
Dyrcona |
Evergreen 2.9 is past its security release date. Should it be removed from the downloads page? |
| 08:38 |
kmlussier |
berick: Do you think you might have time today to look at 20-hold-targeter.t? This morning's test failed for hold 1 - http://testing.evergreen-ils.org/~live/test.24. |
| 08:38 |
kmlussier |
When I ran it on my VM, I didn't have trouble with that particular test, but I had errors with the test for hold 263. |
| 08:38 |
* kmlussier |
will past the output in a second. |
| 08:38 |
Dyrcona |
Also, I think the release date for 2.11 is wrong on the downloads page. |
| 08:39 |
kmlussier |
Dyrcona: yes. I noticed that yesterday but forgot to say something. |
| 08:39 |
kmlussier |
That is, I noticed that 2.9 was past the security date. |
| 08:41 |
Dyrcona |
Oh, yeah. Duh. |
| 08:42 |
Dyrcona |
I just noticed it was the same as 2.10 and thought that was wrong. |
| 08:42 |
Dyrcona |
Silly brain.... :) |
| 08:42 |
kmlussier |
berick: The output when I run that test is http://pastebin.com/DJr1L6z2 |
| 08:44 |
kmlussier |
That just leaves the web client build test. I'm not sure what's going on there. |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:49 |
|
bos20k joined #evergreen |
| 09:15 |
|
afterl joined #evergreen |
| 09:15 |
kmlussier |
berick: Actually, ignore my output. Just realized I have the old hold targeter running in a cron job, which may have affected the test results? When I manually retargeted hold 263, I was left with 1 error. |
| 09:16 |
kmlussier |
It expected 22 mapped copies, but only got 21. 21 seems right to me since I only see 21 visible copies in the catalog. But I may be missing something. |
| 09:22 |
|
jvwoolf joined #evergreen |
| 09:23 |
gmcharlt |
oh, in case it wasn't obvious, I lift my hold on merging to rel_2_11 and rel_2_10 |
| 09:25 |
kmlussier |
:) |
| 09:28 |
kmlussier |
Starting my morning off right. Testing code that hasn't actually been loaded on the server I'm using. |
| 09:28 |
kmlussier |
@coffee |
| 09:28 |
* pinesol_green |
brews and pours a cup of La Esperanza Colombia Huila, and sends it sliding down the bar to kmlussier |
| 09:29 |
dbs |
kmlussier: that's your control group, right? :) |
| 09:29 |
gmcharlt |
@coffee kmlussier |
| 09:33 |
gmcharlt |
(I'm dealing with updating milestones in LP, hence my question) |
| 09:34 |
kmlussier |
Yes, looks like it. |
| 09:40 |
|
yboston joined #evergreen |
| 09:57 |
berick |
kmlussier: hey just to confirm, you are testing on a new concerto data set? |
| 09:58 |
berick |
kmlussier++ merging the midnight oil |
| 10:00 |
kmlussier |
berick: The only new thing I know of that has changed in the concerto data set is that some grouped records are no longer living in the same metarecord group. But it doesn't appear to affect the records in your tests. |
| 10:00 |
berick |
kmlussier: there's a concerto change in one of the hold targeter commits |
| 10:00 |
berick |
it adds a metarecord hold |
| 10:01 |
kmlussier |
berick: Yes, that's there. |
| 10:01 |
berick |
ok |
| 10:01 |
berick |
possible some parallel changes occurred that affect the test. kmlussier, I can revisit in a bit, after I deploy some security patches |
| 10:02 |
kmlussier |
berick: Great, thanks! Yes, secure your system first. :) |
| 10:02 |
kmlussier |
berick++ |
| 10:21 |
kmlussier |
Calling 1022 and 1023 |
| 10:38 |
kmlussier |
If somebody else doesn't beat me to it, that is. |
| 10:39 |
kmlussier |
Would anyone be willing to look at bug 1661747 for JBoyer today? |
| 10:39 |
pinesol_green |
Launchpad bug 1661747 in Evergreen "Add get_org_unit_ancestor_at_depth to action trigger reactor helpers" [Wishlist,New] https://launchpad.net/bugs/1661747 |
| 10:40 |
kmlussier |
Dyrcona: Did you ever get any sample ISBN's to test the czech added content module? |
| 10:41 |
Dyrcona |
kmlussier: Better than that. They sent me some MARC records, that I admittedly have not looked at, yet. |
| 10:41 |
Dyrcona |
I've been doing C/W MARS stuff this morning. |
| 10:41 |
kmlussier |
Dyrcona: Do you think you'll have a chance to look at it today? If not, maybe you can send them my way and I can give it a try. |
| 10:58 |
Dyrcona |
Your branch and 'origin/user/jkotrla/lp1624366-added_content_obalkyknih_2' have diverged, and have 102 and 2 different commits each, respectively |
| 10:58 |
Dyrcona |
I'm the king of typos. |
| 10:59 |
Dyrcona |
Maybe I meant an em dash? |
| 10:59 |
Dyrcona |
Working is my origin on my test vms for obvious reasons. |
| 10:59 |
Dyrcona |
So guess I'll install again. |
| 11:02 |
Dyrcona |
I just heard from Eva and it's OK to add the records that she sent to Concerto, so I'll add them with this branch when I push it later. |
| 11:03 |
* Dyrcona |
is confident the testing will be a success. |
| 11:03 |
Dyrcona |
Should I add the documentation as a release note, or will someone else take care of that? |
| 11:03 |
|
Christineb joined #evergreen |
| 11:05 |
kmlussier |
Dyrcona: Jane was going to take care of the documentation. |
| 11:34 |
kmlussier |
Ooh! Something isn't looking good in the web client patron interface. I don't know if it's in master or is one of the branches I loaded. |
| 11:35 |
kmlussier |
Dyrcona: Did you say you just built the web client? |
| 11:36 |
Dyrcona |
Yeah, after rebasing the obalky branch and installing. I build the web client and xul client. |
| 11:36 |
Dyrcona |
I've been using the web client in a lot of my testing on my vm lately. |
| 11:36 |
gmcharlt |
Dyrcona: the branch is a little dusty (*cough* *hack*), but is there anything you still have out there would would benefit from mergin 939535? |
| 11:37 |
kmlussier |
I think the problems I'm seeing are related to a branch I haven't merged yet. |
| 11:37 |
Dyrcona |
gmcharlt: Not at the moment, and I forgot that I even did that. |
| 11:41 |
kmlussier |
Webby looks fine too, so I'll just focus on making sure I don't merge whatever broke my checkout screen. |
| 11:41 |
Dyrcona |
Maybe I'll check it out and take it for a spin. I'm probably more amenable to berick's suggestion today. |
| 11:42 |
gmcharlt |
speaking of OpenSRF 2.5-beta - I'll realize that simultaneously with the EG 2.12-beta release |
| 11:43 |
berick |
kmlussier: fyi, looking at hold tests. data has changed in a variety of ways. unclear how, since it was OK a few days ago. metarecord 42 picked up a record. bib 45 only has 21 in holdable locations, before it has 22. also, if I run the fill test suite, patrons pick up penatles that aren't there when running in isolation. (also seeing neg. balance test failures, not sure if that has any effect). |
| 11:43 |
berick |
more to follow.. |
| 11:43 |
Dyrcona |
I'll have to see if I can find my client code that used it. I probably do not still have it hanging around. |
| 11:44 |
kmlussier |
OK, I haven't seen any of the negative balance test failures. I ran the full suite of pgtap tests yesterday. |
| 11:44 |
Dyrcona |
Unless it's a branch at mvlc. |
| 11:44 |
berick |
kmlussier: perl live tests |
| 11:44 |
Dyrcona |
pgtap tests should not be a problem, IIRC. |
| 11:44 |
Dyrcona |
perl live tests mostly can only run once, then you have to reload the db. |
| 11:44 |
|
mmorgan joined #evergreen |
| 11:45 |
Dyrcona |
been a while since I ran all of the pgtap tests, though. |
| 11:45 |
Dyrcona |
that may have changed. |
| 11:45 |
kmlussier |
berick: Ah, ok. For some reason, I was thinking they were pgtap. But I didn't see any hiccups with negative balance tests in this morning's test results. |
| 11:45 |
berick |
it occurs to me if we don't enforce a leave-it-like-you-found-it policy on perl live tests, writing new tests is going to be painstakingly slow process |
| 11:46 |
berick |
rebuild db, run all tests, new test fails, start over, ... |
| 11:46 |
gmcharlt |
agreed |
| 11:46 |
Dyrcona |
But, I had a test that worked, then started failing after some other data/code was changed. IIRC, someone else ended up fixing it. |
| 11:46 |
Dyrcona |
Anyway, back to what I was doing. |
| 11:49 |
berick |
kmlussier: it's possible (nay, likely) my fines test failure was a result of running the live tests multiple times |
| 11:50 |
berick |
kmlussier: will confirm shortly |
| 11:52 |
kmlussier |
berick: As far as the changes in the metarecords, I don't have a good handle on how the sample data is built, but I wonder if my code that broke up the existing metarecord groups somehow threw off how the holdings were applied to the records. |
| 11:53 |
dbwells |
berick: when we wrote the negative balance tests, we also included a neg_bal_testing_reset.sql which might do what you need. |
| 11:57 |
dbwells |
berick: I think the main reason that doesn't just happen is that its awfully helpful to actually see the resulting test-generated data when it fails. I agree we should think about a better system or convention for that. |
| 11:58 |
berick |
dbwells: thanks |
| 11:59 |
Dyrcona |
Well, I think it would be hard to leave it like you found it with Perl tests that are doing backend calls. There's no undo mechanism for that, and a lot of things can't be deleted or undone, really. |
| 11:59 |
Dyrcona |
Bills could be paid, etc., but don't think they can be removed without gymnastics. :) |
| 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 |
