| 02:40 |
|
StomproJosh joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:14 |
JBoyer |
jeff, I think you're remembering a discussion because I also remember one but I don't remember any bugs about actually doing it. |
| 07:15 |
JBoyer |
I found myself saying "Why am I saying this?" as I explained to our most recent library that you can have any username you like, but you have to always remember to enter it the same way every time. |
| 07:43 |
|
kmlussier joined #evergreen |
| 08:13 |
|
agoben joined #evergreen |
| 08:30 |
|
ngf42 joined #evergreen |
| 08:33 |
jeff |
JBoyer: heh, it failed the absurdity test. :-) |
| 08:34 |
JBoyer |
Very much. |
| 08:42 |
|
tlittle joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 09:17 |
Dyrcona |
And, answered my own question by checking my local logs, and seeing that csharp did say "72" as I thought I remembered. :) |
| 09:18 |
Dyrcona |
IIRC, we have cstore set to 70, so I think I'll go with something in that area. |
| 09:18 |
|
yboston joined #evergreen |
| 09:19 |
Dyrcona |
Might be neat to configure all of my bricks to share routers. Really spread the load, but maybe I'll test that with a couple of vms, first. |
| 10:14 |
|
jvwoolf joined #evergreen |
| 10:16 |
|
mmorgan joined #evergreen |
| 10:26 |
kipd |
Is there a relatively simple way to test out small changes to various perlmods without having to do a complete make; make install cycle for all of Evergreen? For example, I want some additional information printed out with the email in ~/Evergreen-ILS-3.0.2/Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/HoldNotify.pm Can I do this just from the Makefile in src/perlmods? |
| 10:37 |
berick |
kipd: copy the Perl file into place and restart all (or affected) services |
| 10:37 |
berick |
no need to 'make', etc. |
| 10:38 |
berick |
on my ubuntu test vm for example they end up in /usr/local/share/perl/5.22.1/ |
| 10:39 |
kipd |
doh, I was looking in the wrong place. Thank you! |
| 10:44 |
Dyrcona |
kipd: If the file ends in .in, you will need to make it, first. There are very few modules like that, but many of the scripts do. |
| 10:45 |
* Dyrcona |
modifies marc_export quite a bit. :) |
| 11:06 |
Dyrcona |
So, you imagine retargeting frozen holds once per day or something like that? |
| 11:09 |
berick |
Dyrcona: we retarget once a day (at night) so I was thinking weekly for frozen. |
| 11:10 |
Dyrcona |
berick: OK. We retarget twice an hour. I thought it was something along those lines. |
| 11:10 |
Dyrcona |
berick++ # I'll be happy to test the changes. |
| 11:11 |
berick |
Dyrcona: cool. i'll have a patch shortly |
| 11:13 |
|
collum joined #evergreen |
| 11:23 |
csharp |
Dyrcona: I set fielder to 72 max_children, but didn't see any further spikes after that |
| 11:27 |
csharp |
*my* max_children is set to 2, but our prod servers are set to 128 at the moment (which I think could probably dial down to 72) |
| 11:28 |
Dyrcona |
Thanks. :) |
| 11:28 |
* csharp |
has a friend about the same age (early/mid 40s) with 7 children - wondering if that was a config file error |
| 11:28 |
Dyrcona |
I'm updating our test server to 3.0.3 and getting a branch ready for 3.0. |
| 11:28 |
Dyrcona |
heh. |
| 11:29 |
Dyrcona |
There's a family at my daughter's school with 9 kids. |
| 11:31 |
csharp |
ok - we just hit bug 1736243 - and from what I can tell, it's another datatype issue (string vs. number) |
| 16:17 |
|
khuckins joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:38 |
|
jvwoolf left #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 20:03 |
|
dbwells_ joined #evergreen |
| 21:04 |
|
StomproJ joined #evergreen |
| 03:06 |
|
yar joined #evergreen |
| 03:57 |
|
Jillianne joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
JBoyer joined #evergreen |
| 07:38 |
|
agoben joined #evergreen |
| 07:39 |
|
tlittle joined #evergreen |
| 09:14 |
|
jvwoolf joined #evergreen |
| 10:02 |
kmlussier |
Would anyone be willing to look at bug 1736267 on something other than ubuntu trusty before I merge it? I would like to include it in today's maintenance release since we're unable to build the web client in 2.12 without it. |
| 10:02 |
pinesol_green |
Launchpad bug 1736267 in Evergreen "Release 2.12 should install nodejs from source" [High,New] https://launchpad.net/bugs/1736267 |
| 10:02 |
* kmlussier |
is double checking it on ubuntu trusty since it's been a while since she first tested it. |
| 10:04 |
|
mmorgan1 joined #evergreen |
| 10:12 |
|
jvwoolf joined #evergreen |
| 10:18 |
|
jvwoolf1 joined #evergreen |
| 10:39 |
|
JBoyer joined #evergreen |
| 10:47 |
|
Dyrcona joined #evergreen |
| 10:53 |
kmlussier |
cesardv++ #Following up on bug 1738249. |
| 10:53 |
pinesol_green |
Launchpad bug 1738249 in Evergreen "Circulation Library in Item Status" [Low,Confirmed] https://launchpad.net/bugs/1738249 |
| 10:54 |
kmlussier |
I'm sorry to say I had those changes sitting in a branch for a couple of weeks. I forgot about it until I saw the duplicate bug filed yesterday. |
| 11:00 |
miker |
@weather 30101 |
| 11:06 |
pinesol_green |
Launchpad bug 1743650 in Evergreen "Records with Located URIs retrieved out of scope when org units are not OPAC visible" [High,Confirmed] https://launchpad.net/bugs/1743650 |
| 11:13 |
kmlussier |
OK, I'll look at it now. |
| 11:13 |
kmlussier |
gmcharlt / dbwells: Do we still have time to push fixes to 3.0 for today's release? |
| 11:46 |
csharp |
so kmlussier, bug 1736267 should be cherry-picked onto rel_2_12 for testing right? |
| 11:47 |
pinesol_green |
Launchpad bug 1736267 in Evergreen "Release 2.12 should install nodejs from source" [High,Fix committed] https://launchpad.net/bugs/1736267 |
| 11:47 |
* csharp |
has a xenial test vm raring to go |
| 11:48 |
kmlussier |
csharp: Yes, that would be great! I ended up merging it, but if it blows something up, it would be good to know before today's release. |
| 11:48 |
* kmlussier |
could probably practice some patience. |
| 12:08 |
|
gmcharlt joined #evergreen |
| 13:09 |
gmcharlt |
kmlussier: yeah, they're important enough |
| 13:09 |
kmlussier |
gmcharlt: Thanks! I'll merge right away. |
| 13:13 |
kmlussier |
Calling 1086 |
| 13:19 |
pinesol_green |
[evergreen|Mike Rylander] LP#1743639: opac_visible on acplg is not what it seems - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=02cfe27> |
| 13:19 |
pinesol_green |
[evergreen|Mike Rylander] LP#1743639: Test location as proxy for location group - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4827005> |
| 13:19 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1743639: Stamping upgrade script for copy location group visibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d0dacd7> |
| 13:22 |
kmlussier |
And now calling 1087 |
| 13:29 |
pinesol_green |
[evergreen|Mike Rylander] LP#1743650: Bib vis testing needs different handling - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d32b247> |
| 13:29 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1743650: Stamping upgrade script for special bib visibility handling - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b30ae37> |
| 13:32 |
kmlussier |
Done testing and merging now for today's release. |
| 13:58 |
sandbergja2 |
Just to confirm: the only changes to the 2.12 point release are the three nodejs ones from bshum? And I'm good to start working on the release notes? |
| 14:06 |
kmlussier |
sandbergja2: Yes, that's correct. As far as I can tell, most of the fixes that have gone in were either web client fixes that didn't backport cleanly or were fixes related to new 3.0 features. |
| 14:15 |
|
annagoben joined #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 17:12 |
Dyrcona |
sandbergja++ kmlussier++ |
| 17:15 |
|
yar joined #evergreen |
| 18:04 |
pinesol_green |
[evergreen|Dan Wells] Forward port 3.0.3 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a060e06> |
| 18:04 |
pinesol_green |
[evergreen|Dan Wells] Forward port 2.12.9 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4808f1a> |
| 18:11 |
|
rlefaive joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 03:19 |
|
yar joined #evergreen |
| 06:10 |
|
jeff joined #evergreen |
| 06:17 |
|
Guest94274 joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:05 |
|
rjackson_isl joined #evergreen |
| 07:06 |
|
rjackson_isl_ joined #evergreen |
| 08:05 |
|
rlefaive_ joined #evergreen |
| 10:03 |
|
rlefaive joined #evergreen |
| 10:04 |
Dyrcona |
Anyone else seeing not connected to the network errors that appear to be related to search.facets_for_record_set |
| 10:05 |
terran |
We're still getting reports of Hatch not working on 32-bit versions of Windows 7. Anyone else? |
| 10:07 |
csharp |
kmlussier: so far so good - the next couple of ours will be our true test |
| 10:07 |
csharp |
s/ours/hours/g |
| 10:08 |
csharp |
Dyrcona: we're not at this point |
| 10:09 |
Dyrcona |
csharp: OK. We get them infrequently, now. |
| 10:09 |
csharp |
we're seeing something that attempts to insert a new actor.card object with a null barcode |
| 10:09 |
Dyrcona |
And, it always seems to be related to a JSON query with that function. |
| 10:27 |
csharp |
in our case it runs for about 4 minutes and so far not causing pile-ups |
| 10:28 |
Bmagic |
csharp: they require that the staff browse to that section of the patron account |
| 10:28 |
Dyrcona |
csharp: Haven't seen that. Just the payments one. |
| 10:28 |
Dyrcona |
We're not using 3.0 in production, but we do have it on a test server with production data. |
| 10:28 |
Bmagic |
csharp: and it doesn't happen for ALL patrons. Just some. Probably those with more than X number of historic bills..... |
| 10:31 |
csharp |
yeah makes sense |
| 10:32 |
jeff |
reminds me of our 0.00 bills issue. :-) |
| 13:03 |
miker |
re fielder |
| 13:03 |
miker |
it's not a new services, IOW |
| 13:11 |
Dyrcona |
miker: OK. Thanks. Thought I'd heard of it, but I've never used it in my own work. |
| 13:15 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 13:16 |
Dyrcona |
Grr....Lp search is bad. I swear there was a bug to remove the permacrud service. |
| 13:16 |
* csharp |
at least remembers a discussion about that |
| 13:17 |
Dyrcona |
I tried advanced search and even filing a new bug but nothing turned up. |
| 14:35 |
Dyrcona |
Yeah, that looks like about right. |
| 14:36 |
Bmagic |
csharp ^^ |
| 14:54 |
csharp |
Bmagic: Dyrcona: cool - thanks |
| 14:58 |
jeffdavis |
This is kinda baffling. I've got a test server with the fix for bug 1736419 where search results include all matching records with located URIs, even when none of the luri's are in scope. |
| 14:58 |
pinesol_green |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Fix committed] https://launchpad.net/bugs/1736419 |
| 14:59 |
kmlussier |
jeffdavis: I'm about to submit a bug on this. I don't know if it's the same issue, but we've found that records are being retrieved that are outside of scope when org units are set to not opac visible. |
| 15:00 |
kmlussier |
jeffdavis: I'm still trying to nail down some kind of pattern before submitting the bug. |
| 15:01 |
|
mmorgan1 joined #evergreen |
| 15:10 |
jeffdavis |
kmlussier: Do you mean out-of-scope records are retrieved when they have luri's belonging to opac-invisible org units? |
| 15:12 |
kmlussier |
jeffdavis: Well, that's what I'm trying to nail down. In Concerto, if I made an org unit invisible, I'll start seeing out-of-scope records with luris, but I don't think it's just happening with ones owned by the invisible org unit. |
| 15:13 |
jeffdavis |
Huh, weird. That would be consistent with my test environment which has a number of invisible orgs. |
| 15:15 |
jeffdavis |
I know the bib-level visibility check involves asset.patron_default_visibility_mask() which adds an explicit list of opac-invisible org units to exclude from luri_org vis tests |
| 15:15 |
jeffdavis |
maybe a parenthesis is getting misplaced or something |
| 15:18 |
|
JBoyer joined #evergreen |
| 15:19 |
JBoyer |
csharp, were you the one looking for how to trigger inserts of null user barcodes recently? I was just watching someone renew a card and change barcode and it did it to them. |
| 15:19 |
kmlussier |
OK, when I set BR1 as OPAC invisible, the record with a BR2 luri is being retrieved out of scope. When I set BR2 as OPAC invisible, the record with a BR1 luri is retrieved out of scope. |
| 15:20 |
JBoyer |
What's most annoying is that there was 100% a barcode in the box. We initially gave her 1 card, then changed card numbers again before saving (but didn't save in between). |
| 15:20 |
kmlussier |
When I set SYS1 as OPAC invisible, they both were retrieved out of scope, I think. |
| 15:21 |
JBoyer |
I haven't tried to reproduce it yet (I'm at a new library go live and haven't had time to test much) but wanted to throw this out there in case people want to try to break things. |
| 15:23 |
|
tlittle joined #evergreen |
| 15:26 |
JBoyer |
We got the generic error in database query message (DATABASE_QUERY_ERROR or similar) because PostgreSQL was unhappy, so that's what users will see. |
| 15:27 |
JBoyer |
*poof* |
| 18:00 |
ejk |
Good stuff. I think I should be able to get a good guess from this. Thanks! |
| 18:00 |
ejk |
dbs++ |
| 18:02 |
dbs |
glad to be able to help |
| 18:32 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 19:14 |
jeff |
sounds like that's enough for your needs, but there's also the technique of using pcrud: |
| 19:14 |
jeff |
using srfsh, you could issue: request open-ils.pcrud open-ils.pcrud.id_list.bre "ANONYMOUS", {"id": {"!=": null}}, {"order_by": {"bre":"id desc"}, "limit":1} |
| 19:15 |
jeff |
or the gateway, a slightly ugly url encoded: |
| 06:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:46 |
|
rlefaive joined #evergreen |
| 08:58 |
|
bos20k joined #evergreen |
| 09:07 |
|
Dyrcona joined #evergreen |
| 10:50 |
pinesol_green |
Launchpad bug 1738488 in Evergreen 3.0 "Web client: patron billing history results in long running query" [Medium,Confirmed] https://launchpad.net/bugs/1738488 |
| 10:51 |
Bmagic |
If you don't have something to kill those off, your database could easily get clobbered once hundreds of staff are using the Web client. |
| 10:51 |
Bmagic |
of course, that's not the real* fix |
| 10:52 |
Dyrcona |
I've had to kill a number of those by hand in testing and training. |
| 10:52 |
Dyrcona |
I've noticed that they don't run for days with join_collapse_limit at 9 in production on 2.12. |
| 10:52 |
Dyrcona |
It's on the bug, but just throwing that out there. |
| 10:53 |
Dyrcona |
jeff: So, library A loaded in about 10 seconds, also. I'm not seeing a slow down today. |
| 11:06 |
* pinesol_green |
grabs some Moon Pie and some RC Cola for jeff |
| 11:08 |
Dyrcona |
Hm... One of these canceled holds is from 2013! |
| 11:08 |
Dyrcona |
No, I take that back, a lot of them are and some from 2012.... |
| 11:09 |
Dyrcona |
Yeah, I noticed relatively high load on training and testing until those queries were killed, too. |
| 11:10 |
Dyrcona |
Setting join_coallapse_limit may help some. I did that for other reasons on production, but I think it is helping with the payment history queries. |
| 11:10 |
jeff |
Dyrcona: also, if you get to a point where you're suspecting the base query, -- yeah, I think you mostly already got where I was going. |
| 11:11 |
Dyrcona |
jeff: That query does some ridiculous joins, but I won't repeat too much of what was discussed in IRC recently and linked from the bug, IIRC. |
| 16:54 |
kmlussier |
OK, I'm out. Have a nice weekend everyone! |
| 17:18 |
|
bshum joined #evergreen |
| 17:26 |
|
jvwoolf left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:59 |
|
alynn26_ joined #evergreen |
| 19:05 |
|
alynn26_ joined #evergreen |
| 00:18 |
|
Jillianne joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:29 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
sandbergja joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 10:12 |
|
rlefaive joined #evergreen |
| 10:23 |
Dyrcona |
jeffdavis: I tried your odapi-checker.pl this morning. |
| 10:23 |
Dyrcona |
jeffdavis: I get this error: Error on API request: 405 Method Not Allowed |
| 10:23 |
Dyrcona |
That's on the test server. |
| 10:23 |
Dyrcona |
Any idea what's wrong? |
| 10:24 |
pinesol_green |
[evergreen|Jason Boyer] LP1741072: Fix JS test for template conversion - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ce01eeb> |
| 10:24 |
pinesol_green |
[evergreen|Bill Erickson] LP#1741072 Volcopy editor deposit amount format repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2f7449a> |
| 10:25 |
JBoyer |
Yay! I was wondering when those would go in. |
| 10:26 |
JBoyer |
gmcharlt++ |
| 10:26 |
Dyrcona |
jeffdavis: If I try with production values, I get 400 bad request. |
| 10:32 |
berick |
gmcharlt_: *nod* let me know if/how I can help. i'd like to dig into that soon |
| 10:33 |
|
gmcharlt joined #evergreen |
| 10:38 |
Dyrcona |
jeffdavis: Just the basic check of the account works on the standard endpoint. I get 200 OK. |
| 10:39 |
Dyrcona |
jeffdavis: Trying the same on the integration endpoint with our test account id gives 403 Forbidden, so likely something wrong on their end or I need a different token for testing that no one told me about? |
| 10:40 |
pinesol_green |
[evergreen|Jason Boyer] LP1737052: Fix Typo in Permission Name - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f3bff3e> |
| 10:44 |
pinesol_green |
[evergreen|Jane Sandberg] LP1719943: fixing typo in credential testing interface - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ce4b51e> |
| 11:11 |
Bmagic |
Before I submit this on LP, has it already been reported that the acqusitions interface is bugged when adding a note/alert on an item. The dropdown UI shows up and immediately disappears? |
| 11:14 |
csharp |
berick: thanks - that jibes with everything we're saying |
| 11:14 |
csharp |
hooray! |
| 11:36 |
Dyrcona |
rsyslog is next to useless. |
| 11:46 |
|
rlefaive joined #evergreen |
| 11:49 |
|
kmlussier joined #evergreen |
| 11:52 |
kmlussier |
Has anyone noticed a problem in the web client where titles in the holds pull list disappear when you sort the list? |
| 11:53 |
kmlussier |
I hadn't noticed it on my test VMs, but I saw it today when looking at a system with production data on it. https://drive.google.com/file/d/1F8wTMwk9tcHKMvOUPj4UkFLs-67uFeiV/view |
| 11:53 |
jeff |
Dyrcona: rsyslog problems? |
| 11:53 |
kmlussier |
Oh, I guess that video isn't ready for prime time yet. |
| 11:53 |
Dyrcona |
jeff: Things are not making it to the server, and it's seemingly random. |
| 12:07 |
|
khuckins joined #evergreen |
| 12:08 |
|
dwgreen joined #evergreen |
| 12:09 |
|
khuckins_ joined #evergreen |
| 12:11 |
phasefx |
btw, it was a perl live test that failed this morning, not the browser build |
| 12:12 |
phasefx |
Failed test 'Hold 263 has 31 mapped potential copies' at live_t/20-hold-targeter.t line 100. got: '24' expected: '31' |
| 12:20 |
|
terran joined #evergreen |
| 12:34 |
|
rlefaive joined #evergreen |
| 12:49 |
jeffdavis |
Dyrcona: Overdrive client auth uses the same endpoint for both integration and production. IIRC you use the same token for both. |
| 12:55 |
jeffdavis |
What were you doing that gave the 400 Bad request error? |
| 12:57 |
Dyrcona |
Patron auth with our production account on the man server. |
| 12:57 |
Dyrcona |
s/man/main/ |
| 12:59 |
Dyrcona |
The testing account worked for a basic connection without specifying the testing endpoint. |
| 13:02 |
Dyrcona |
I get a 400 bad request trying patronauth with the testing credentials, too. I guess they didn't actually enable that for us. |
| 13:09 |
jeffdavis |
I'm getting 200 OK for patron auth with production data. I don't have testing access set up at the moment so can't test that. |
| 13:10 |
kipd |
Tuning question about the output from osrf_control --diagnostic: I assume this isn't good, but is changing max_children for some of these processes the way to go? |
| 13:10 |
Dyrcona |
Well, I'm supposed to have it for testing but not production, at least that's what I understood from the emails. |
| 13:10 |
kipd |
https://www.irccloud.com/pastebin/Xo4UJYH6/ |
| 13:11 |
Dyrcona |
kipd: Yes, if you need more. It depends, really. |
| 13:11 |
kipd |
Everything beyond max_children is waiting in queue right? |
| 13:22 |
Dyrcona |
yes, the first number includes the spares. |
| 13:22 |
jeff |
but in theory you should never see more than 100% for #drones and I'm not sure what conditions would lead to that display (orphaned drones, something else...) |
| 13:25 |
Dyrcona |
Yeah, I've never seen that output. |
| 13:37 |
Dyrcona |
jeffdavis: Should I be making the test patron-auth requests against the standard endpoint or should I specify a test endpoint? |
| 13:39 |
jeffdavis |
The standard one |
| 13:39 |
jeffdavis |
"All patron authentication POSTs use the same URL (https://oauth-patron.overdrive.com/patrontoken) in both the production and integration environments" (http://developer.overdrive.com/apis/patron-auth) |
| 13:40 |
Dyrcona |
Ah,ok. |
| 13:40 |
Dyrcona |
I hadn't gotten that far into the docs. |
| 13:41 |
Dyrcona |
I still get 400 bad request with testing parameters. |
| 13:48 |
jeffdavis |
The --verbose option should give you the full response, which might help narrow down the cause. If nothing else you can pass the info along to their support people. |
| 13:54 |
Dyrcona |
OK. I'll try that. |
| 13:54 |
Dyrcona |
I'm starting to think that they just failed to enable patron auth. |
| 14:05 |
Dyrcona |
Oh! I think I found something in an email from Overdrive that I overlooked. |
| 14:06 |
Dyrcona |
Details! But I think I have it fixed. |
| 14:06 |
Dyrcona |
I was using the wrong authorization name. |
| 14:09 |
Dyrcona |
So, they sent me two library names in the email, the one that I'm supposed to use for the authorization name and the one that we choose on the test site. I missed the first more or less, 'cause it was on the same line with the other. |
| 14:14 |
Dyrcona |
jeffdavis++ # Thanks for the help. I think I have it working, more or less. |
| 14:15 |
jeffdavis |
yay! |
| 14:17 |
pinesol_green |
[evergreen|Dan Wells] LP#1730470 Restore XUL serial receive compatibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d90f69f> |
| 14:56 |
Dyrcona |
The Download button doesn't work and there's nothing in the drop down next to ti. |
| 14:59 |
|
sandbergja joined #evergreen |
| 15:17 |
|
mmorgan1 joined #evergreen |
| 15:32 |
Dyrcona |
I think the null of null happens because the records don't exist on the api testing server. |
| 15:33 |
Dyrcona |
I found one that looks like it would be there that is in our catalog, but the ISBN numbers don't match. |
| 15:33 |
Dyrcona |
We also have a record for an e-book and e-audio from Overdrive, but the integration site only has an e-book with a different ISBN from our e-book. |
| 15:37 |
kmlussier |
Dyrcona: bug 1677813 |
| 17:17 |
|
jvwoolf joined #evergreen |
| 17:32 |
|
jvwoolf joined #evergreen |
| 17:51 |
|
book` joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:50 |
|
Jillianne joined #evergreen |
| 23:24 |
|
jonadab joined #evergreen |
| 00:27 |
pinesol_green |
[evergreen|Cesar Velez] LP#1710405 - remove Modify + Use Edits buttons in z3950 overlay - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bfd5b2f> |
| 02:12 |
|
gsams_ joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
JBoyer joined #evergreen |
| 07:27 |
|
rjackson_isl joined #evergreen |
| 08:11 |
|
kmlussier joined #evergreen |
| 10:07 |
|
terran joined #evergreen |
| 10:17 |
Bmagic |
berick: Is it possible that the new hold targeter is not respecting age based hold protection? We have many hold rules that look like are suddenly allowing patrons to get items that are age protected accross systems. |
| 10:18 |
Bmagic |
accross/across |
| 10:18 |
terran |
In the "not sure if it's just me" category - in our 3.0.2 test server, when I print a list of current bills, it's only printing circ bills and not grocery. Don't see this problem on our 3.0.0 test server. |
| 10:19 |
terran |
Does anyone have a moment to test this on their 3.0.2 server? |
| 10:19 |
Bmagic |
terran: sure |
| 10:19 |
Bmagic |
let me see if I can dig up a patron with both types |
| 10:19 |
terran |
Bmagic: Thanks! |
| 10:21 |
Bmagic |
it's easy - can you confirm that the patron hold notification preferences simply do not show up in Webby and clearly are there in XUL? |
| 10:21 |
Bmagic |
when editing a patron |
| 10:21 |
terran |
Bmagic: Sure, I'll check |
| 10:23 |
berick |
Bmagic: age protect is handled in the DB hold permit test. that stuff didn't change with the new targeter. |
| 10:25 |
terran |
Bmagic: The first account I checked has Email and SMS checked and it shows up in both My Account and the web client. I'll create a new test account and check it. |
| 10:25 |
Bmagic |
terran: interesting.... |
| 10:25 |
Bmagic |
berick: darn, I was hoping it would be explained easily.... |
| 10:26 |
Bmagic |
berick: I suppose it's possible that no one noticed this flaw in our hold rules until now... |
| 10:29 |
JBoyer |
Bmagic, I'm not sure what you're seeing, but I don't think the age protection value in the hold rules has anything to do with items actually having age protection. I thought that was checked in perl after a holds rule was chosen. |
| 10:30 |
terran |
Bmagic: I created a new account and left email and phone checked by default. Tested in OPAC and it was fine. Edited in web client and the settings still appeared. Made changes in OPAC. Changes showed up in web client. |
| 10:31 |
terran |
Bmagic: I recall seeing a lot of problems with this type of thing in 2.12. |
| 10:31 |
JBoyer |
You don't have a custom .tt2 for the patron editor do you? I think half (or more) of the fix for that was in the template. |
| 10:32 |
kmlussier |
Yes, what JBoyer sounds vaguely familiar. Age protection needs to be applied at the copy level. |
| 10:34 |
Bmagic |
terran: thanks for checking that, maybe it is just me. JBoyer: it sounds like this was a problem in the past? And perhaps I have some old tt2 files..... weird. I will have to investigate |
| 10:51 |
Bmagic |
I am referring to age_hold_protect_rule - the options correlate with the options that we have for age based hold protection |
| 10:51 |
kmlussier |
What exactly does that field do in the hold matrix? I don't think I ever figured out the answer to that question when we stumbled across this issue years ago. |
| 10:52 |
Bmagic |
I am not referring to item age, sorry I misunderstood. I am definitely not referring to item age |
| 10:52 |
* mmorgan |
thought that field in the hold matrix allowed for different circ rules for items with those values. Never have used or tested it, though. |
| 10:52 |
Dyrcona |
Basically, it prevents a given matrix matchpoint from applying to an item less than that age. |
| 10:52 |
JBoyer |
And the comments light the way. It's not for matching, it's for returning. There's a comment in 110.hold_matrix_matchpoint about not being sure someone wanting to remove it from acp. The intent (if not the result) is that a matching row with a non-null age_hold_protect_rule would apply that rule to the copies even if their age rule is null. |
| 10:53 |
Dyrcona |
Basically, it makes no sense. :) |
| 11:00 |
Bmagic |
mmorgan: yes, they are correct - value is 2 |
| 11:01 |
* mmorgan |
nods |
| 11:02 |
mmorgan |
And all the copies in question have an age_hold protection rule set, and that the rule has not expired based on the created date (or active date)? |
| 11:02 |
Bmagic |
when running the hold permit test, I find that it's matching a rule with a null value for age_hold_protect_rule - which means "copies with anything in this column" ? |
| 11:03 |
Dyrcona |
Bmagic: I've never filled in that field in the matrix and age hold protection has always worked as I expected it to. |
| 11:03 |
Dyrcona |
I honestly don't think the field in the matrix is used, but I need to do some archeology to be certain. |
| 11:03 |
Bmagic |
We have rules in place for each of our systems that explicitly permit holds from items anywhere in the consortium to patrons in each of the systems. One rule per system. |
| 11:18 |
Bmagic |
JBoyer: aha, refreshing caused those checkboxes to populate, perhaps we have another timeout issue? |
| 11:24 |
|
Christineb joined #evergreen |
| 11:41 |
Bmagic |
terran: it seems that those notification preferences randomly are not populated, if you ever see them non-checked when they should be, perform a browser refresh page and violla |
| 11:43 |
Bmagic |
JBoyer: just to be clear, when performing a hold permit test with the SQL funciton, it should pass and provide the matching rule even with age based hold protection on the copy because that logic happens in perl? |
| 11:45 |
JBoyer |
Yeah, that way you can see if the hold is even possible. Just finding a matching row doesn't mean you've targeted a copy. |
| 11:45 |
JBoyer |
(or that you've found a copy to target, rather.) |
| 11:51 |
|
khuckins joined #evergreen |
| 11:59 |
berick |
Bmagic: JBoyer: the copy age protect test happens in the in-db function too |
| 12:00 |
Bmagic |
berick: which function should I be testing with? |
| 12:00 |
berick |
action.hold_request_permit_test and action.hold_retarget_permit_test |
| 12:01 |
Bmagic |
the one that should be denying this copy with age protection to this patron |
| 12:01 |
terran |
Bmagic: Thanks for confirming the bill printing problem, bug reported at: https://bugs.launchpad.net/evergreen/+bug/1742194 |
| 12:04 |
terran |
Bmagic: re notification preferences: weird, I will keep my eyes open for that problem. |
| 12:05 |
miker |
kmlussier: was in a meeting ... I can look at the comment #10 thing quickly and see if it's trival |
| 12:05 |
Bmagic |
terran: along those same lines, we find that the transit slips print the wrong stuff until you print it a second time |
| 12:06 |
terran |
Bmagic: I saw your report on that, but we haven't seen that happen in testing yet either. It may be that we see both of these after we are in production next week. |
| 12:06 |
Bmagic |
terran: it's tough to find because it doesn't happen always |
| 12:06 |
krvmga |
we have an item in our catalog that includes both a CD and a DVD. is there any way for us to display both icons for this in the catalog? |
| 12:07 |
Bmagic |
I am finding a common theme, where refreshing the screen corrects the issue |
| 12:11 |
Bmagic |
terran: where the UI is ready to show but the data isn't. Like this one |
| 12:11 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1642036 |
| 12:11 |
pinesol_green |
Launchpad bug 1642036 in Evergreen "Web Staff Client - Group Members Don't Display" [Medium,Confirmed] |
| 12:14 |
terran |
Bmagic: FWIW, we have your patch on our test server and it's been working there, but we don't have it in production yet. |
| 12:15 |
Bmagic |
I think bug 1642036, bug 1740537, bug 1361258 might have some of the same underlying causes |
| 12:15 |
pinesol_green |
Launchpad bug 1642036 in Evergreen "Web Staff Client - Group Members Don't Display" [Medium,Confirmed] https://launchpad.net/bugs/1642036 |
| 12:15 |
pinesol_green |
Launchpad bug 1740537 in Evergreen "Web client: Transit slip printing with wrong information" [Undecided,New] https://launchpad.net/bugs/1740537 |
| 17:56 |
berick |
just guessing, but could be an issue with proximity adjusment configuration |
| 18:20 |
Bmagic |
That system does have an adjustment set... More on this when I get back to it Thursday. |
| 18:20 |
Bmagic |
berick++ |
| 18:30 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:40 |
|
rlefaive joined #evergreen |
| 18:43 |
miker |
autogen.sh -u should no longer be needed. a trigger should be handling that |
| 18:43 |
* miker |
disappears |
| 18:47 |
|
dbwells_ joined #evergreen |
| 19:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1736419: Located URIs vs QueryParser, round 2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=13d0596> |
| 19:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1736419: Located URIs vs QueryParser, round 2, part deux - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d63b81f> |
| 19:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1736419: Bib visibility tests get OR'd - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=979d0c2> |
| 02:13 |
|
troy__ joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
agoben joined #evergreen |
| 08:41 |
|
kmlussier joined #evergreen |
| 12:04 |
berick |
i hesitate to bring this up, because I have no explanation, but we had problems in the past with lost.auto. i eventually commented out that line of code since we weren't using it. |
| 12:07 |
mmorgan |
We don't use lost.auto either, FWIW |
| 12:07 |
berick |
every now and then the mark-lost events would get backed up, they couldn't finish. my theory is that creating events while firing events is causing problems. commenting out the line fixed the problem for us. |
| 12:12 |
Bmagic |
berick: ok, I believe I might have found an issue with the originating MarkItemLost trigger and not the lost.auto, testing my theory now |
| 12:12 |
berick |
*nod* |
| 12:14 |
berick |
ah, never thought 41° could feel this good |
| 12:15 |
berick |
web team gurus, i have updated Hatch: https://evergreen-ils.org/downloads/Hatch-Installer-0.1.4.exe |
| 14:24 |
kmlussier |
Bah! LP timeouts. |
| 15:08 |
|
rlefaive joined #evergreen |
| 15:09 |
kmlussier |
miker: Under what circumstances should biblio.record_entry.vis_attr_vector be populated? Is it just used for records with Located URIs? |
| 15:10 |
miker |
kmlussier: luris and if the bib has a source |
| 15:10 |
miker |
kmlussier: btw, I'm preparing a server for more in-depth testing |
| 15:10 |
kmlussier |
miker: Any source or just transcendent sources? |
| 15:10 |
miker |
I was piggybacking on another so want to eliminate any confusion |
| 15:11 |
miker |
any source |
| 16:01 |
berick |
in the 'canceled transit' status, i mean |
| 16:01 |
Dyrcona |
Does canceled transit keep it from the copy map? |
| 16:01 |
* Dyrcona |
has not looked, but it would appear so. |
| 16:02 |
berick |
in my test db, 'canceled transit' is marked as holdable |
| 16:03 |
Dyrcona |
ok |
| 16:04 |
Dyrcona |
It's holdable in my production database for the sake of the logs. |
| 16:06 |
Dyrcona |
Maybe copy_active being false is Bmagic's issue? |
| 17:45 |
Bmagic |
get your camera ready |
| 17:46 |
Bmagic |
I tacked it on bug 1361258 |
| 17:46 |
* csharp |
hopes to run into Sarah Huckabee Sanders at Target later :-) |
| 17:46 |
pinesol_green |
Launchpad bug 1361258 in Evergreen "Patron registration form does not set notification preferences" [Undecided,Confirmed] https://launchpad.net/bugs/1361258 |
| 18:30 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 19:27 |
troy__ |
i'm trying to pass a user object to an opensrf call, can anyone tell me if this is the right format? |
| 19:27 |
troy__ |
https://www.irccloud.com/pastebin/kRthpHfD/ |
| 19:29 |
troy__ |
for open-ils.circ.checkout.permit |
| 00:07 |
|
abowling joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 07:30 |
JBoyer |
csharp, re: yesterday's "how are whitescreen formed?" discussion, I've also seen it without hatch but caused by some kind of lovefield connection error. The fix for that is to blow away the web database, which hopefully doesn't have any transactions in it... |
| 11:11 |
|
mdriscoll joined #evergreen |
| 11:49 |
bshum |
berick: So the new commits that just got added are blowing up my attempts to run grunt all, etc. |
| 11:49 |
* bshum |
just so happened to be building a fresh VM |
| 11:50 |
berick |
arg, i of course didn't test that |
| 11:50 |
berick |
looking |
| 11:52 |
berick |
bshum: the itemSvc.convert_xul_templates errors? |
| 11:52 |
bshum |
berick: Yep, I think that's what I saw |
| 11:53 |
bshum |
"itemSvc.convert_xul_templates converts copy templates as expected" and then unhappiness |
| 12:08 |
|
Christineb joined #evergreen |
| 12:30 |
csharp |
probably a problem with the test and not the code |
| 12:31 |
|
jihpringle joined #evergreen |
| 12:31 |
berick |
yeah |
| 12:31 |
berick |
the service use to handle more of the data cleanup, no longer necessary w/ the template formatters |
| 12:36 |
Dyrcona |
tests+- |
| 12:45 |
|
book` joined #evergreen |
| 12:46 |
Dyrcona |
bshum: If it's just the tests failing you can bypass that with --force or doing grunt build |
| 12:46 |
Dyrcona |
I think it's grunt build. I've run into that sort of thing before. |
| 13:19 |
Dyrcona |
Bmgic: Did you ever get overdrive integration working with their test site? I think it was you who was going to try. |
| 13:19 |
Dyrcona |
Bleh.... Bmagic ^^ |
| 14:30 |
miker |
kmlussier / berick: just a head's up: https://bugs.launchpad.net/evergreen/+bug/1736419 has a branch |
| 14:30 |
pinesol_green |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Confirmed] |
| 14:30 |
kmlussier |
miker++ |
| 14:31 |
miker |
and the limit-to-avail-as-staff |
| 14:31 |
kmlussier |
I'm happy to have a reason to take a break from what I'm working on and test that branch. :) |
| 14:31 |
berick |
miker++ |
| 14:44 |
bshum |
Dyrcona: I'll give that a whirl too, just figured I'd mention since it'd probably be trouble for others down the road |
| 14:51 |
Dyrcona |
bshum: Yep. That's why I mentioned gunt build in channel. |
| 15:45 |
Dyrcona |
Bmagic: Doesn't seem to be working for me. I wonder if I have to alter URLs in 856s or something. |
| 15:45 |
Dyrcona |
Or, if I need to set library name or .... |
| 15:46 |
Bmagic |
Dyrcona: I had it working where it would lookup the availablility of a title but nothing about patron specific holds and checkouts |
| 15:48 |
Dyrcona |
Bmagic: All of that has supposedly been enabled for us on the test environment. |
| 15:49 |
Bmagic |
Dyrcona: so you don't have any of it working? |
| 15:49 |
Dyrcona |
TBH, I don't know. |
| 15:50 |
Dyrcona |
I checked something out to myself on the test site and it doesn't show up in Evergreen, but we may not have that record loaded.... |
| 15:51 |
Dyrcona |
I see some availability for ebooks in our test OPAC, but I don't know what it is supposed to look like. :/ |
| 15:51 |
Dyrcona |
Like it will say eaudio (1) or ebook (1), but I dunno if that's coming from Overdrive or not, though I suspect not. |
| 15:52 |
Dyrcona |
My test OPAC is our data upgraded to 3.0.2 with no customization. |
| 15:53 |
Dyrcona |
@eightball Is this The End? |
| 15:53 |
pinesol_green |
Dyrcona: NO! |
| 15:55 |
kmlussier |
Dyrcona: Is your test OPAC accessible to the outside world? |
| 15:56 |
Dyrcona |
kmlussier: I wanted it to be, but apparently it isn't. |
| 15:56 |
Dyrcona |
I had to use the VPN to connect. |
| 15:57 |
Dyrcona |
We had fun with the networking on this machine after a recent kernel update, too. |
| 16:09 |
Dyrcona |
Yes, it is. |
| 16:10 |
kmlussier |
Dyrcona: Yeah, that's something different. That just brings the user to another format if they want something different from the current record. |
| 16:11 |
Dyrcona |
OK. It's not working for us. |
| 16:12 |
* Dyrcona |
hates testing environments. |
| 16:12 |
jeffdavis |
Testing the API integration stuff is especially painful unfortunately. :( |
| 16:13 |
kmlussier |
jeffdavis: The grunt all error you encountered is something different. bshum discovered it earlier today. You can use grunt all --force to bypass it. |
| 16:13 |
Dyrcona |
I think just "grunt build" works. |
| 16:13 |
Dyrcona |
That'll build it and skip the testis, IIRC. |
| 16:17 |
kmlussier |
jeffdavis: I'm getting the same results as you at this point. :( |
| 16:21 |
Dyrcona |
jeffdavis: Do the records have to use "new style" Overdrive URLs to work properly? |
| 16:21 |
Dyrcona |
Actually, I'm not even sure that means anything. |
| 16:22 |
jeffdavis |
Dyrcona: IIRC old-style URLs should work as long as you've got pattern matching set up in config.tt2 but it's been awhile since I tested |
| 16:22 |
Dyrcona |
I kind of botched the pattern matching, but this record should match. We have multiple patterns. |
| 16:23 |
Bmagic |
So, I am finding that null values in config.hold_matrix_matchpoint -> age_hold_protect_rule is matching items that have age protection. Should that be the case? |
| 16:23 |
Dyrcona |
Bmagic: Yes, it would be the case if other things match. |
| 17:34 |
Bmagic |
it was a LIBRARY SETTING! "Disable Automatic Print Attempt Type List" |
| 17:35 |
Bmagic |
5 hours later, clicked "revert" to null and violla! It prompts a print slip |
| 17:41 |
Bmagic |
Never seen that library setting before. That setting is hilarious. |
| 18:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 21:19 |
|
ejk_ joined #evergreen |
| 21:20 |
|
gmcharlt_ joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 08:26 |
|
_adb joined #evergreen |
| 08:36 |
|
slink-lib joined #evergreen |
| 10:54 |
csharp |
might be a path issue (see bug 1714026) for an illustration of the problem I'm thinking of |
| 10:54 |
pinesol_green |
Launchpad bug 1714026 in Evergreen "Maintain Control Numbers function should be schema-qualified" [High,Fix released] https://launchpad.net/bugs/1714026 |
| 10:55 |
rjackson_isl |
csharp++ Bmagic++ |
| 10:55 |
berick |
Bmagic: have you tried clearing all settings and testing that way? |
| 10:55 |
Bmagic |
berick: It prints on any other printer |
| 10:59 |
berick |
Bmagic: my point being that if no margin is selected, it should use the printer default (which presumably would work). |
| 10:59 |
berick |
s/no margin/no settings at all/ |
| 11:00 |
Bmagic |
Bmagic: I see, yes, we tried that |
| 11:02 |
berick |
Bmagic: can you confirm when resetting (in the print test UI) that it passes autoMargins:true in the Hatch command? |
| 11:02 |
Bmagic |
berick: it will be a bit. I will need to get a screen share going with the branch |
| 11:03 |
berick |
Bmagic: *nod* be good to see the error msg too, of course |
| 11:03 |
dbs |
Dymos are ALWAYS such a pain to configure |
| 11:54 |
Bmagic |
berick: that is where I got |
| 12:06 |
pinesol_green |
[evergreen|Cesar Velez] LP#1691861 - make Item Status edit items in batch in volcopy - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5cbd3ed> |
| 12:11 |
Bmagic |
berick: shall I make a LP? |
| 12:12 |
berick |
Bmagic: yes, please. I may have (indirect) access to a Dymo for testing. i'll more in a bit. |
| 12:12 |
Bmagic |
berick: I considered buying one of those printers |
| 12:13 |
berick |
well, if you get your hands on one let me know |
| 12:13 |
* berick |
wonders how much they cost |
| 13:51 |
berick |
they should have called it Lil' Turbo |
| 13:52 |
dbs |
berick++ |
| 13:53 |
|
JBoyer-sick joined #evergreen |
| 13:55 |
JBoyer-sick |
Hello #evergreen. I come to request testing be thrown at bug 1741072 and bug 1712646 . The second depends on the first and both should be good to go for 3.0.3. |
| 13:55 |
pinesol_green |
Launchpad bug 1741072 in Evergreen "Fine level and loan duration aren't displayed when editing items" [Undecided,New] https://launchpad.net/bugs/1741072 |
| 13:55 |
pinesol_green |
Launchpad bug 1712646 in Evergreen "Web Client: Adding bill without billing type fails silently" [Low,Confirmed] https://launchpad.net/bugs/1712646 |
| 13:56 |
JBoyer-sick |
Catalogers will be happy about the first, and circ staff the second. Very kumbaya. |
| 17:21 |
Bmagic |
miker: it's basic vanilla EG setup. The ejabber users are router and opensrf |
| 17:21 |
miker |
Bmagic: kk, nevermind then |
| 18:06 |
|
abowling1 joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:01 |
|
jvwoolf joined #evergreen |
