| 03:52 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:20 |
|
tsadok joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:12 |
|
agoben joined #evergreen |
| 09:25 |
|
Dyrcona joined #evergreen |
| 09:25 |
|
jvwoolf1 joined #evergreen |
| 09:33 |
|
yboston joined #evergreen |
| 09:46 |
pinesol_green |
[evergreen|Cesar Velez] LP#1669534 - OPAC hold request should not default to first SMS carrier - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f7deb92> |
| 10:11 |
|
bos20k joined #evergreen |
| 10:33 |
gmcharlt |
csharp: I've made an updated branch for bug 1098685 if you'd care to test again |
| 10:33 |
pinesol_green |
Launchpad bug 1098685 in Evergreen "User can select SMS notify without providing a valid address" [Medium,Confirmed] https://launchpad.net/bugs/1098685 |
| 10:47 |
|
gsams joined #evergreen |
| 10:51 |
csharp |
gmcharlt: trying to test - I think I'm fighting cache but it's still not working for me |
| 10:52 |
csharp |
I copied the files from your last commit into place and started testing - if there's something else I need, let me know |
| 10:52 |
gmcharlt |
csharp: does view source show holds-validation.js being linked? |
| 10:53 |
csharp |
hmm - no |
| 10:53 |
csharp |
lemme verify that the files are actually there |
| 11:50 |
|
khuckins joined #evergreen |
| 12:27 |
miker |
berick: are you handy? |
| 12:27 |
berick |
miker: i am |
| 12:27 |
miker |
and have time to maybe look at why some karma tests hate me? |
| 12:27 |
miker |
:) |
| 12:29 |
kmlussier |
Gee, I wonder what prompted that question. :) |
| 12:29 |
berick |
heh |
| 12:29 |
berick |
miker: point me at it |
| 12:33 |
miker |
ok, np |
| 12:37 |
|
jihpringle joined #evergreen |
| 12:57 |
pastebot |
"berick" at 64.57.241.14 pasted "for miker -- karma config update for lovefield" (12 lines) at http://paste.evergreen-ils.org/596 |
| 12:57 |
berick |
that fixes the tests for me |
| 12:58 |
berick |
fyi, the services have to be loaded in a certain order, that's why it's not a simple services/*.js import |
| 13:09 |
miker |
berick: bah ... thanks... I fixed a different test problem a week or so ago with that same thing. I should'a known |
| 13:13 |
miker |
kmlussier: so, berick's fix is pushed to the offline branch |
| 13:13 |
kmlussier |
miker: OK, I'll take a look when I have a moment. |
| 13:19 |
kmlussier |
It would be nice if there were a way to identify words that should never be stemmed. Like 'kissinger.' |
| 13:26 |
|
rlefaive joined #evergreen |
| 14:59 |
Dyrcona |
sure |
| 14:59 |
remingtron |
what value should I put in the "institution" variable? |
| 14:59 |
Dyrcona |
Whatever you want. It isn't really used, IIRC. |
| 15:00 |
remingtron |
I have two successful tests from 00sc_status.t, but test 3 fails with "Unable to connect to ILS..." |
| 15:00 |
Dyrcona |
I never run those tests... |
| 15:00 |
remingtron |
ha |
| 15:00 |
Dyrcona |
And, I'm not sure that they work with a real ILS, just the dummy one that comes with SIPServer. |
| 15:01 |
Dyrcona |
These are the SIPServer tests, right? |
| 15:01 |
remingtron |
yes |
| 15:01 |
remingtron |
so basically, a failure of those tests shouldn't concern me? |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:03 |
Dyrcona |
Not in the least if you're talking to a real ILS. |
| 15:03 |
Dyrcona |
The test that's failing uses a username of sip_01. |
| 15:04 |
remingtron |
cool, thanks for calming my fears. |
| 15:06 |
Dyrcona |
heh. it might even fail with the ILS.pm supposed to be used for testing. |
| 15:09 |
Dyrcona |
Yeah, looks like it will just plain fail. |
| 15:12 |
JBoyer |
remingtron, While you can use just about anything for an institution, it is (can be?) used to select different options for some SIPServer backend options in oils_sip.conf. We have one institution that needs that msg_64_barcode_something_something turned off and another where it's turned on. |
| 15:13 |
Dyrcona |
Yeah. It will match up in the configs. I guess I sort of assumed..... |
| 00:16 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:06 |
|
JBoyer joined #evergreen |
| 07:19 |
|
rjackson_isl joined #evergreen |
| 09:25 |
|
jvwoolf left #evergreen |
| 09:28 |
|
jvwoolf joined #evergreen |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:04 |
pinesol_green |
[opensrf|Graham Billiau] LP#1704090: ensure make install respects DESTDIR - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=e88891b> |
| 10:51 |
pastebot |
"gmcharlt" at 64.57.241.14 pasted "for feedback - is this in fact easier to understand?" (12 lines) at http://paste.evergreen-ils.org/579 |
| 10:51 |
bshum |
gmcharlt: were not or may not? |
| 10:51 |
gmcharlt |
bshum: in this context, definitely were not |
| 15:32 |
* JBoyer |
feels a dufus because he forgot to disable transparent_hugepages on the db, explaining all manner of "random" slowdowns in otherwise simple Qs. |
| 15:32 |
JBoyer |
Looked at an email csharp sent to the lists ages ago and was reminded. |
| 16:09 |
csharp |
JBoyer: glad it was helpful :-) |
| 16:24 |
Dyrcona |
jeff: Thought you might like to know that after I installed my branches for Lp 1542495 and Lp 1463943 my phpsip2 test script runs great. It was apparently a UTF-8 character causing it to crash. |
| 16:24 |
pinesol_green |
Launchpad bug 1542495 in SIPServer "OpenILS::SIP::clean_text() can crash" [Undecided,Confirmed] https://launchpad.net/bugs/1542495 |
| 16:24 |
pinesol_green |
Launchpad bug 1463943 in SIPServer "Non-ascii Unicode characters in messages cause SIP client problems" [Undecided,Confirmed] https://launchpad.net/bugs/1463943 |
| 16:25 |
gmcharlt |
Dyrcona: coordinates of that test script? |
| 16:26 |
Dyrcona |
gmcharlt: It's not a test script that one could integrate into Evergreen, but I put it on pastebin. Let me check my logs. |
| 16:26 |
gmcharlt |
Dyrcona: thanks! |
| 16:27 |
Dyrcona |
gmcharlt: https://pastebin.com/5jm9m2h3 |
| 16:28 |
* gmcharlt |
claims 1049 in the name of the too few journal publishers who never, ever, ever change their titles everywhere! |
| 16:29 |
Dyrcona |
It was written to test some SIP2 fine item details changes, but incidentally tests those branches as well. :) |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:32 |
gmcharlt |
*cough* |
| 16:32 |
gmcharlt |
I'll deal with that test failure |
| 16:33 |
Dyrcona |
:) |
| 16:33 |
Dyrcona |
It doesn't look too bad. |
| 16:33 |
gmcharlt |
yeah, easy-peasy |
| 01:12 |
|
ericar joined #evergreen |
| 03:41 |
|
StomproJ joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 14:35 |
ohiojoe |
and it looks like Jane and I will follow on the in-progress then? |
| 14:37 |
ohiojoe |
#action sandbergja and ohiojoe will follow-up with assigned "in-progress" users to try to preserve any progress made but not submitted |
| 14:38 |
ohiojoe |
#topic Progress on Docs Reorganization project |
| 14:38 |
sandbergja |
I would love some guidance here! |
| 14:39 |
sandbergja |
I'd like to gather some feedback on the reorganized manuals on the test server |
| 14:39 |
sandbergja |
What's the best way of going about the feedback gathering, do you think? |
| 14:42 |
kmlussier |
sandbergja: Have you sent out anything to one of the lists (docs or general) showing the changes you've made? |
| 14:42 |
kmlussier |
I feel like you have, but I'm not finding it. |
| 14:43 |
sandbergja |
kmlussier: I thought so too, but it looks like I haven't |
| 14:43 |
sandbergja |
ohiojoe: could you put that down as an action item for me, please? |
| 14:44 |
ohiojoe |
#action sandbergja will email one or more lists seeking feedback on reorganized manuals on the test server |
| 14:44 |
kmlussier |
sandbergja: If you don't get much feedback via the list, it might be worth scheduling another meeting focused on the reorg project. |
| 14:44 |
kmlussier |
But it would be good to see if you can get good discussion on the list first. |
| 14:45 |
sandbergja |
sounds like a plan |
| 14:45 |
kmlussier |
For reference: |
| 14:45 |
kmlussier |
#link http://docs-testing.evergreen-ils.org/ |
| 14:45 |
ohiojoe |
any other thoughts here before we move on? |
| 14:46 |
ohiojoe |
#topic Progress on documentation launchpad bugs |
| 14:48 |
kmlussier |
#link https://bugs.launchpad.net/evergreen/+bugs?field.tag=documentation |
| 16:06 |
jeffdavis |
Dyrcona: do you mean having generic (rather than Sitka specific) access to that environment for EG devs? |
| 16:06 |
jeffdavis |
Or just in general? |
| 16:13 |
Dyrcona |
I'm not sure. I requested Patron Authentication API and they responded about using their integration envoronment. |
| 16:14 |
Dyrcona |
They said, "We are currently speaking with an Evergreen contributor and have not been able to set up a test environment." |
| 16:14 |
Dyrcona |
Among other things. |
| 16:30 |
jeffdavis |
They must mean me. I requested access to their integration environment for Sitka (not for the broader EG community) - looks like they didn't receive part of my request and followed up while I was on vacation. |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:40 |
|
jvwoolf joined #evergreen |
| 16:47 |
jeffdavis |
Dyrcona: I sent them a follow up attempting to explain that my access to their API doesn't preclude others'. |
| 16:55 |
Dyrcona |
jeffdavis: OK. I'm going to discuss it with others here to see where our priorities are. I don't think i really have time for it right now. |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:20 |
|
JBoyer joined #evergreen |
| 10:18 |
Dyrcona |
berick: How do you top it after the duration without losing the transaction? I should probably look that up, instead.... ;) |
| 10:19 |
berick |
Dyrcona: each chunk of months is its own transaction. the sql runs to completion each time, then the calling script checks to see if it should start another one. |
| 10:19 |
Dyrcona |
Oh. I see. Thanks. |
| 10:20 |
Dyrcona |
I should test this on my new hardware, but we're putting it in production on the 20th, so it may not finish by then. |
| 10:20 |
|
bwicksall joined #evergreen |
| 10:23 |
berick |
hm, so we have a custom circ purge script. it has less (unused locally) logic. it's diverged enough from stock I don't have a functional diff to share. but the gist is only work on circs whose xact_finish value falls between start_time and end_time, those being new function params. |
| 10:25 |
|
terran joined #evergreen |
| 15:49 |
jeffdavis |
I'm a bit hesitant about that change. |
| 15:49 |
miker |
gmcharlt: how about, "a NEW security issue" |
| 15:49 |
JBoyer |
It would also allow some older bugs to age out with an official WontFix status rather than a defacto one. |
| 15:50 |
jeffdavis |
Just because we've been testing the web client and finding things that are showstoppers for us in 2.12ish. So making 3.0 the cutoff seems a bit short. |
| 15:50 |
berick |
miker: heh, good point, "xul is old, needs update" ;) |
| 15:50 |
Dyrcona |
"Xul's dead." |
| 15:50 |
gmcharlt |
jeffdavis: yeah, those are things that need to be addressed, hopefully in time for 3.0.0 |
| 16:07 |
JBoyer |
How far is less close? |
| 16:07 |
miker |
(pros: better support, more consistent UIs; cons: more JS to download) |
| 16:07 |
JBoyer |
(for those of us only now seeing it) |
| 16:07 |
Dyrcona |
No. I assume you're also looking for willing victims...er test subjects. |
| 16:07 |
miker |
JBoyer: zero-padding differences |
| 16:08 |
miker |
mainly |
| 16:08 |
JBoyer |
Hmm. |
| 16:13 |
berick |
this should be simple, do we want to wait until after 3.0 to update from angular 1.5 to 1.6 (bug #1680140) ? |
| 16:13 |
pinesol_green |
Launchpad bug 1680140 in Evergreen "Update staff JS dependencies for Angular 1.6" [Wishlist,Confirmed] https://launchpad.net/bugs/1680140 |
| 16:14 |
gmcharlt |
berick: I'm inclined to defer that decision to the week of 28 August |
| 16:14 |
berick |
i ask becuase any time we muck about in the js, espeically the deps it means re-testing, rebasing, etc. |
| 16:14 |
Dyrcona |
Given your comments from today, I'd say wait. |
| 16:14 |
gmcharlt |
i.e., give a try before the beta gets cut |
| 16:15 |
gmcharlt |
not that I'm particuarly opposed to waiting until after 3.0... but given our experience with Dojo, I think there's a strong argument to be made that we should get used to biting the version treadmill bullet |
| 16:16 |
berick |
i'll add a note to the bug about revisiting |
| 16:16 |
gmcharlt |
ok |
| 16:16 |
gmcharlt |
so then, finally, back to miker about offline |
| 16:17 |
miker |
Really, I just want to get input on the serviceworker setup in use, and ask for testing |
| 16:17 |
csharp |
@band add The Version Treadmill Bullet |
| 16:17 |
pinesol_green |
csharp: Band 'The Version Treadmill Bullet' added to list |
| 16:17 |
miker |
we're using UpUp currently |
| 16:19 |
miker |
the branch is at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1706107-offline-mode |
| 16:19 |
miker |
LP at https://bugs.launchpad.net/evergreen/+bug/1706107 |
| 16:19 |
pinesol_green |
Launchpad bug 1706107 in Evergreen "Offline mode for the Web Client" [Undecided,New] |
| 16:20 |
kmlussier |
I've already done a fair amount of testing and could probably add a signoff sometime soon. I probably would want to load it on a local test server just to make sure it still works as I remember. |
| 16:20 |
JBoyer |
I'm +1 to using the simplest thing that will work, though I've not been able to test that branch yet. |
| 16:20 |
kmlussier |
miker: Are we losing anything by not using the whole serviceworker framework? |
| 16:20 |
miker |
kmlussier: complication? ;) |
| 16:21 |
miker |
seriously, not that I can see |
| 16:21 |
miker |
that is /all/ upup tries to do |
| 16:21 |
miker |
and, now that it's all set up, it seems to do well |
| 16:22 |
berick |
ditto JBoyer |
| 16:22 |
miker |
kmlussier: when testing the new separate branch (was embedded in serials before) we'll need to watch for new 404s during offline mode |
| 16:23 |
miker |
one key thing is that upup has to know about (and cache) every single resource that the offline interface references, either directly or indirectily, via css include or xhr also |
| 16:24 |
miker |
for instance, I had to install the woff2 version of the bootstrap font because, even though we don't use it, it's requested by the css |
| 16:24 |
miker |
and causes a load failure in the offline UI if it can't be cached by the service worker |
| 16:26 |
miker |
to sum up: this is a call for testing, and secondarily, a call for critique of the implementation |
| 16:26 |
kmlussier |
ok, I'll try to carve time out for testing it. I think I know what to look for and how to break it if there are issues. :) |
| 16:26 |
gmcharlt |
ok, and with that, we've reached the end |
| 16:26 |
miker |
kmlussier: if anyone does ... ;) |
| 16:26 |
miker |
thanks all |
| 16:30 |
|
DPearl left #evergreen |
| 16:32 |
berick |
miker: k, yeah, that's another one that would benefit from a quick merge once it's updated. |
| 17:00 |
|
https_GK1wmSU joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
|
https_GK1wmSU left #evergreen |
| 17:05 |
|
mmorgan1 left #evergreen |
| 17:37 |
Bmagic |
gmcharlt++ |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:00 |
|
Jillianne joined #evergreen |
| 06:41 |
|
rlefaive joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 11:15 |
bshum |
Yes |
| 11:16 |
bshum |
I'll check Debian docs to see if something's changed in this area... |
| 11:16 |
Dyrcona |
I certainly hope not. |
| 11:18 |
berick |
wonder if it would work after a reboot. could also test by manually exporting LD_LIBRARY_PATH to see what happens. |
| 11:19 |
Dyrcona |
I've been meaning to build a Debian 9 vm to kick the tires. |
| 11:19 |
Dyrcona |
I may do that sooner rather than later. |
| 11:20 |
bshum |
I'll try a reboot now |
| 13:35 |
francisco_ |
Hi all, I have a question, Does the receipt template aditor are saved in an especific table in EG? or are saved locally on each machine? This because I upgraded from 2.8.4 to 2.12.3 and the templates looks like they were set to the default ones |
| 13:36 |
Dyrcona |
francisco_: Receipts are stored in the staff client preferences. If you have the old staff client hanging around, you can export them. It has to be the staff client where they were created or imported, though. |
| 13:39 |
|
collum joined #evergreen |
| 13:46 |
* bshum |
grumbles something about systemd ruining our lives |
| 13:46 |
bshum |
systemctl start apache2 websockets.service |
| 13:47 |
bshum |
(more notes to self) |
| 13:48 |
bshum |
miker++ # your fix for perl 5.24 works for me on Debian 9 ; I'll let Graham eyeball it too, but I'll go pick it on later once I get to re-test it on lower versions |
| 13:51 |
Dyrcona |
bshum: You see where sytemd won the pwnie award for "worst vendor?" Mainly 'cause Lennaert. |
| 13:52 |
|
mmorgan joined #evergreen |
| 13:54 |
|
sergio_ joined #evergreen |
| 15:57 |
|
jvwoolf joined #evergreen |
| 15:59 |
|
pgardella joined #evergreen |
| 16:17 |
|
pgardella joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:33 |
gsams_ |
A little while back I had an issue regarding not being able to pull up the patron editor properly for a handful of patrons, which was fixed by removing some incorrect information in those patrons' sms notify fields. |
| 16:33 |
gsams_ |
I'm having a slightly different issue with the same set of patrons, in which we can't seem to place holds for them. |
| 16:34 |
gsams_ |
It doesn't fill in their information when attempting to place a hold through the staff client, and the box that should contain their barcode is empty. |
| 02:03 |
|
_GK1wmSU joined #evergreen |
| 02:06 |
|
_GK1wmSU left #evergreen |
| 03:20 |
|
rlefaive joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:20 |
|
rlefaive joined #evergreen |
| 05:28 |
|
umarzuki joined #evergreen |
| 05:34 |
umarzuki |
after docker container running, how do I access demo page? |
| 12:48 |
|
Dyrcona joined #evergreen |
| 12:50 |
miker |
arg |
| 12:50 |
gmcharlt |
parameter! |
| 12:51 |
miker |
so, dbwells, looks like I'll need to roll back at least the opensrf side of the interval_to_seconds change. after adding 2 unit tests covering month addition across DST boundary, we have a problem |
| 12:52 |
miker |
it's not matching the PG calculation for interval math |
| 12:52 |
miker |
it's better than "1 yr/12", but it's not giving the expected results... |
| 12:56 |
pinesol_green |
[opensrf|Mike Rylander] LP#1635737: Unit tests for DST and date math - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=316f583> |
| 13:04 |
egbuilder |
build #64 of osrf-master-debian-6.00-x86_64 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/osrf-master-debian-6.00-x86_64/builds/64 blamelist: Mike Rylander <mrylandergmail.com> |
| 13:12 |
|
mmorgan joined #evergreen |
| 14:06 |
dbwells |
miker: Thanks for testing and agressively pushing! Unfortunately, I think you hit a limitation of the date parser, or more accurately, ISO dates in general. Bare offsets don't have DST rules, as areas with the same offset may or may not participate in DST. To get the right DST math, you have to specify an actual region. Let me cook up an example, one moment... |
| 14:07 |
|
Dyrcona joined #evergreen |
| 14:07 |
dbwells |
miker: So, I think a test like this will return the expected number: interval_to_seconds("1 month", DateTime::Format::ISO8601->new->parse_datetime("2017-02-14T23:59:59-04")->set_time_zone("America/New_York")) |
| 14:13 |
Dyrcona |
@blame tlp |
| 14:13 |
pinesol_green |
Dyrcona: tlp stole bshum's tux doll! |
| 14:16 |
dbwells |
I haven't thought through exactly how this plays out in practice, other than some annoying degree of vigilance. For example, turns out my branch's current casual use of "DateTime-now()" isn't sufficient; it ends up as UTC :( |
| 14:45 |
kmlussier |
Yes, I agree |
| 14:46 |
miker |
dbwells: right. and, specifically, that branch sets the timezone for $due_date to the circulating org's TZ, rather than "local" |
| 14:46 |
miker |
(well, when specified) |
| 14:46 |
dbwells |
miker: Do you think it makes sense to push a change to the test, or do you still think it needs to be rolled back? |
| 14:48 |
miker |
let me try your suggested test change... |
| 14:49 |
miker |
yeah ... that does fix the test, actually |
| 14:52 |
miker |
hrm... fake news. it does not do that at due-date calc time. instead it uses "local" which, with opensrf 2.5 is the client TZ ... it does set the tz properly when generating billings, which is what I was confused with |
| 14:52 |
gmcharlt |
miker: wanting to double-check something - opensrf.persist is not actually used by Evergreen, correct? |
| 14:53 |
gmcharlt |
(asking because it appears to be the only user within OpenSRF itself of of the interval-handing stuff in OpenSRF::Utils |
| 14:53 |
miker |
however... just setting the tz to "local" in the test (which we should not do, because it's server-dependent) does let the tests pass. meaning it's pulling from the env, wihich is correct, short of looking up the circ lib tz |
| 14:53 |
miker |
gmcharlt: correct, it's not in active use |
| 14:54 |
miker |
so, to recap, I think the test was at fault, not the app code or the interval code. here's why: |
| 14:54 |
gmcharlt |
in that case, sort out the one use within opensrf.persist... and the time-handing stuff might be reasonably movable into Evergreen |
| 14:56 |
miker |
the app code, in the the rule needs to be "set the timezone of the context date to a dst-aware value, lest the math not be dst aware" |
| 14:57 |
miker |
we're doing that in the common case of apply_modified_due_date (no $start_time) |
| 14:58 |
miker |
if we follow that rule, even using 'local' (aka, client TZ or server TZ if not sent) then the math works |
| 14:58 |
miker |
ok... I'm feeling better about it now |
| 15:00 |
miker |
gmcharlt: my pref, for the moment would be to leave the code where it is and address the functional issues. once addressed (if proven addressable, that is) then maybe move |
| 15:02 |
gmcharlt |
"where it is" meaning reseting to the status quo ante by reverting, then allowing a bit more time for considered testing? we've got time prior to the next 2.12.x release |
| 15:03 |
miker |
"where it is" meaning which project holds the interval_to_seconds code ;) |
| 15:03 |
miker |
sorry |
| 15:03 |
miker |
that wasn't clear |
| 15:03 |
gmcharlt |
miker: right, I think we're talking about orthogonal things |
| 15:04 |
miker |
anyway, there are 4 scenarios we need to test. with and without DST crossing, and for each, with and without DST-aware TZ |
| 15:04 |
gmcharlt |
moving the time utility functions to Evergreen is something I have a mild preference for, but it's not a showstopper for anythign whatsoever |
| 15:04 |
gmcharlt |
resetting things to the status quo ante is something I feel more strongly about |
| 15:04 |
miker |
(btw, I was looking at the in-PG version also ... the reason it "works" there is that there's a hidden variable: the DB's (effective) timezone setting) |
| 15:06 |
miker |
well, I have passing tests on the opensrf side now. how about we revert the EG side |
| 15:09 |
gmcharlt |
I'd really prefer that the whole thing be tested as a unit, just in case we run into other issues |
| 15:10 |
dbwells |
While I was a little surprised to see it pushed quickly, I guess I am not sure why we would revert code without any known problems. |
| 15:10 |
miker |
dbwells: well, it didn't have tests (which I should have added) |
| 15:11 |
miker |
and my first tests showed the EG side lacking (no tz set in 2 of 3 cases)... though, that's only now explicitly diagnosed |
| 15:11 |
miker |
IOW, I should have known the rule we need (and made it so) before pushing |
| 15:12 |
miker |
anyway, I'll go look up git-revert and do that, then push updated branches |
| 15:12 |
gmcharlt |
miker: thanks |
| 15:13 |
gmcharlt |
and generally speaking, I don't expect that there will be any problem getting this buttoned up prior to the next maintenance release |
| 15:14 |
gmcharlt |
but code that involves time is an area where the more test coverage, the better |
| 15:16 |
dbwells |
definitely agree |
| 15:17 |
pinesol_green |
[evergreen|Mike Rylander] Revert "LP#1635737 Use new OpenSRF interval_to_seconds() context" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a54b18e> |
| 15:17 |
pinesol_green |
[opensrf|Mike Rylander] Revert "LP#1635737: Unit tests for DST and date math" - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=0484c67> |
| 15:17 |
pinesol_green |
[opensrf|Mike Rylander] Revert "LP#1635737 Add optional context to interval_to_seconds" - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=716b674> |
| 15:24 |
egbuilder |
build #65 of osrf-master-debian-6.00-x86_64 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/osrf-master-debian-6.00-x86_64/builds/65 |
| 15:45 |
miker |
dbwells: hrm... is there a reason you removed the hh:mm:ss interval parsing from the evergreen-side patch? |
| 15:45 |
miker |
fwiw, I'm tempted to /add/ that to the opensrf side |
| 15:50 |
dbwells |
miker: It was already in the OpenSRF side. |
| 15:50 |
miker |
dbwells: it sure was :) |
| 15:50 |
* miker |
looked right past it |
| 16:04 |
miker |
dbwells / gmcharlt: branches added |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
|
jvwoolf left #evergreen |
| 16:52 |
gmcharlt |
the branch for patron search from the place holds form is now available for review - bug 1701001 |
| 16:52 |
pinesol_green |
Launchpad bug 1701001 in Evergreen "Allow searching for a patron from place holds page in embedded OPAC" [Wishlist,New] https://launchpad.net/bugs/1701001 |
| 02:15 |
|
ahelten joined #evergreen |
| 02:52 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:27 |
|
rlefaive joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 08:02 |
|
Dyrcona joined #evergreen |
| 09:55 |
Dyrcona |
Well, it gets complicated when you start dealing with money. |
| 09:55 |
Dyrcona |
You might think "it's only math," but you'd be mistaken. :) |
| 09:56 |
Dyrcona |
It's easy to mess up, and boy, don't people get mad when you do. :) |
| 09:56 |
rjackson_isl |
test plans and reviews are your friend in this case |
| 09:57 |
berick |
rjackson_isl: there are 2 parts, the collection agency tracker (money.collections_tracker IIRC) and penalty. the penalty can be locally cleared when the threshold goes back down, but the agency has to clear the collection_tracker entry |
| 09:58 |
rjackson_isl |
berick: in the instance currently being reviewed there is a note on the account showing it going into collections and then back out when I did the oops |
| 09:58 |
rjackson_isl |
it doesn't show going back into collections in the note when I corrected (or partially corrected) |
| 10:20 |
miker |
rjackson_isl: yeah ... there are a ton of things that could be stopping patrons from falling back into collections, if that's the goal. if it's UMS you're working with, they'll be as helpful with diagnostics as they can be, I'm sure |
| 10:20 |
rjackson_isl |
mikre: I think the library is in direct contact on their side so I am going to stay out of this fight unless forced to join! |
| 10:20 |
rjackson_isl |
miker: that is... |
| 10:20 |
* Dyrcona |
shuts up and goes back to checking if his test db server has finished rebooting. |
| 10:30 |
Dyrcona |
On a somewhat related note, I've been having trouble finding patrons that return fine item details with SIP2. |
| 10:30 |
jeff |
Oh? |
| 10:30 |
Dyrcona |
I'll have to look into because apparently the code isn't doing what I think it does. |
| 10:32 |
Dyrcona |
Having a million other things to do and a vacation in between doesn't help. |
| 10:35 |
Dyrcona |
It supposedly works with contrived examples in the Concerto data, i.e. after adding a fine to a patron. |
| 10:35 |
|
jvwoolf joined #evergreen |
| 10:37 |
jeff |
there have been issues in the past with regard to some SIP code using a different mat view (old money owed summaries, iirc), and there were gotchas with auth tokens and/or multiplex personality, but i think most of the ones that would affect this have been addressed. |
| 10:38 |
jeff |
Dyrcona: i'm interested in what you find and might be able to help troubleshoot, but nothing immediately comes to mind for you to try. |
| 10:38 |
jeff |
Dyrcona: what client are you testing with, and have you checked the raw sip message either over the wire or in the server logs to verify that the client isn't obscuring / mis-parsing the fixed field in question? |
| 10:39 |
Dyrcona |
I'm using branches based on Evergreen 2.12.3 and SIPServer master with a copy of production data. |
| 10:39 |
Dyrcona |
jeff: PHPSIP2, and yes, I've dumped the raw messages. I'm not getting the results that I expect. |
| 10:40 |
Dyrcona |
If I ask for 10 fine item details, I get 10 empty fields on every patron. |
| 10:43 |
Dyrcona |
I get 0 for every patron. |
| 10:43 |
jeff |
and at that point, they were all 0? ah. |
| 10:43 |
Dyrcona |
Even after running the fine generator. |
| 10:44 |
Dyrcona |
Since I haven't tested with unmodified code, I don't know what's broke. :) |
| 10:44 |
jeff |
if you reduce it to one patron with bills that is showing a count of 0 fine items via SIP2, if you open the patron in the staff client and Refresh them, does that then change the fine items count in SIP2? |
| 10:45 |
Dyrcona |
I haven't tried that. |
| 10:48 |
jeff |
Does the Evergreen user that the SIPServer is authenticating as have VIEW_USER_TRANSACTIONS permission at the proper ou/depth? |
| 10:53 |
jeff |
...even if you get the facts such so that the patrons will match the criteria to be submitted, starting the submission / collections process fresh is likely a Bad Idea. There isn't a way to put them "back where they were" in the collections process without involving your collections vendor and having careful coordination. |
| 10:54 |
rjackson_isl |
messing with money is a bad idea - but I was out-voted! |
| 10:54 |
jeff |
rjackson_isl: you're welcome :-) |
| 10:55 |
Dyrcona |
jeff thanks for the suggestions, I'm going to rebuild my test vm and give i another whirl. |
| 10:55 |
Dyrcona |
s/i/it/ |
| 10:56 |
jeff |
Dyrcona: it could be as simple as that, then. |
| 10:56 |
* jeff |
finds things he wants to change |
| 16:20 |
mmorgan |
jeff: this happens a lot in our consortium. |
| 16:20 |
mmorgan |
Similarly, if all copies become long overdue when there are still holds to be filled. |
| 16:22 |
mmorgan |
We generate and post a "Hopeless Holds" report daily. |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:44 |
abneiman |
jeff: when I was at KCPL we did a weekly "Hopeless Holds" report -- based on a version that NC Cardinal did. It let us know when the amount of targetable copies dropped to 0 (lost, missing, claimed returned, etc) on titles with holds. Interacted a little wonkily with metarecord holds, IIRC, but it got the job done. |
| 16:46 |
mmorgan |
Ours only looks at title holds, so, not perfect, but also gets the job done (mostly). |
| 16:46 |
abneiman |
jeff: see slide 22 of this presentation: https://evergreen-ils.org/wp-content/uploads/2015/11/eg16-Oops-I-accidentally-deleted-something-and-other-small-problems-bite-sized-reports-to-help-you-find-and-fix-problems-in-your-ILS.compressed.pdf |
| 00:39 |
|
Jillianne joined #evergreen |
| 00:55 |
|
Jillianne2 joined #evergreen |
| 03:24 |
|
Jillianne joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:15 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Release notes for 2.11.7 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c4d9cb3> |
| 06:15 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.12.4 Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d83dc5e> |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 08:15 |
|
collum joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 13:47 |
kmlussier |
One reason we started to link the two problems (if they are indeed linked) is because mmorgan was also noticing in the logs for the one-hit problems that it seemed to be running through mr routines even though they weren't mr searches. |
| 13:48 |
miker |
yeah, that's strange ... looking for the one-hit entry now |
| 13:48 |
* kmlussier |
runs out for a bit to grab lunch. |
| 13:57 |
miker |
hrm ... the timelog on the LP ticket does not seem to match what's actually in the rel_2_12 codebase... the strings are different |
| 14:10 |
miker |
scratch that... the log is from the record loading page, not the search loading page |
| 14:11 |
miker |
slowdown seems to happen in open-ils.search.multi_home.bib_ids.by_barcode |
| 14:12 |
miker |
which, in this case, makes to cstore calls: one to look up the copy by barcode, and a followup to retrieve the peer bibs for the copy |
| 14:18 |
miker |
if, for some reason, there was an error in the first cstore call (say, no barcode passed because of a failure in a preceding call, returning an error or "0" instead of a list of copies) I could see something like this happening |
| 14:18 |
* miker |
looks at mk_copy_query |
| 14:34 |
|
Jillianne joined #evergreen |
| 14:37 |
miker |
kmlussier: btw, the reason the bottom of the timelog on the test has the unapi.mmr stuff is for linking to other constituent records |
| 14:42 |
kmlussier |
miker: That makes sense. I'm beginning the think they may be different issues after all. |
| 14:43 |
miker |
well... we don't have a log for the metarecord 1-hit issue, but I bet it's essentially the same. and all signs in that timelog point to open-ils.search.multi_home.bib_ids.by_barcode |
| 14:47 |
* kmlussier |
could easily supply a log for that issue if it's helpful. |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:04 |
miker |
happy to :) |
| 16:42 |
|
mmorgan joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:18 |
|
jvwoolf left #evergreen |
| 17:23 |
pinesol_green |
[evergreen|Dan Wells] Forward port 2.11.7 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df5b68d> |
| 18:40 |
|
sallyf joined #evergreen |
| 18:40 |
|
drigney joined #evergreen |
| 18:40 |
|
abneiman_ joined #evergreen |
| 00:52 |
|
deep-book-gk_ joined #evergreen |
| 00:54 |
|
deep-book-gk_ left #evergreen |
| 01:02 |
|
JBoyer joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:22 |
|
dbwells joined #evergreen |
| 06:51 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 09:24 |
|
maryj joined #evergreen |
| 09:42 |
|
jvwoolf joined #evergreen |
| 10:04 |
|
Freddy_Enrique joined #evergreen |
| 10:05 |
Dyrcona |
Results of my testing are so far mixed. Read only seems to be highly connection-dependent. |
| 10:05 |
Dyrcona |
Oddly, at 40 connections, the read only test performed 0.9% worse with ht on, but at 80 connections the results were 7.5% better with ht on. |
| 10:08 |
* Dyrcona |
has no idea what the margin of error would be..... |
| 10:08 |
miker |
Dyrcona: HT with PG is pretty dependent on both PG version and the on-die caches, fwiw |
| 10:08 |
miker |
size of the caches, obv |
| 10:08 |
Dyrcona |
miker: Yep, I'm aware of that. |
| 10:09 |
miker |
and the shape of the workload, of course. I'm interested in the deets, btw :) |
| 10:09 |
Dyrcona |
It's the same machine so same hardware and pg version between tests. |
| 10:09 |
miker |
I figured it was the same machine, more just curious about the details |
| 10:10 |
Dyrcona |
I also rebooted before starting each test run, initalized the pg bench tables each time, and haven't messed with cache deliberately. |
| 10:10 |
Dyrcona |
I'll share the details later. |
| 10:10 |
Dyrcona |
The hardware is kind of insane. :) |
| 10:11 |
Dyrcona |
It will be a couple of hours, maybe tomorrow, before I can share. |
| 10:12 |
Dyrcona |
I'm just starting the read/write tests with ht off. |
| 10:12 |
Freddy_Enrique |
@coffee anyone |
| 10:12 |
* pinesol_green |
brews and pours a cup of Ethiopia Yirga Cheffe Koke Espresso, and sends it sliding down the bar to anyone |
| 10:13 |
Dyrcona |
Also, I'm using ZFS just because. :) |
| 10:27 |
miker |
Dyrcona++ # TIA |
| 11:11 |
jonadab |
I have heard good things about zfs. |
| 11:12 |
Dyrcona |
miker: My simple testing shows a boost with HT on with Pg 9.5: https://docs.google.com/spreadsheets/d/1dU8iwKVBHtPrOjULBe3oFnFxaB1tqT9T7Gxu740t6kM/edit?usp=sharing |
| 11:13 |
Dyrcona |
I'll write something up about what I did and the hardware specs in a bit. |
| 11:13 |
Dyrcona |
jonadab: Yeah, ZFS has been great so far. Very simple to set up on the NVMe drives. :) |
| 11:26 |
|
maryj_ joined #evergreen |
| 16:56 |
berick |
not seeing anything, but I've not-seen things before |
| 16:57 |
Bmagic |
not that I have seen |
| 16:58 |
Bmagic |
The basic bucket interface has a tab where you can search.... but it's not the same |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
|
mmorgan left #evergreen |
| 17:02 |
|
kmlussier joined #evergreen |
| 17:03 |
kmlussier |
@hate comcast |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 08:17 |
|
collum joined #evergreen |
| 09:41 |
|
mnsri_away joined #evergreen |
| 09:42 |
|
sandbergja joined #evergreen |
| 09:56 |
|
jvwoolf1 joined #evergreen |
| 10:17 |
pinesol_green |
[evergreen|Christine Morgan] LP1670448 - Move View/Place Orders to Record Summary - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ae0e16a> |
| 10:17 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1670448: Rearrange space for bib record action buttons - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb05739> |
| 11:37 |
|
_adb joined #evergreen |
| 11:59 |
|
Christineb joined #evergreen |
| 12:12 |
|
yboston joined #evergreen |
| 12:57 |
bshum |
Good luck bos20k |
| 12:57 |
bos20k |
Thanks! |
| 12:58 |
|
jihpringle joined #evergreen |
| 13:03 |
mmorgan |
bos20k: Here's what made the "Email checkout receipts by default?" disappear from the patron editor on a test system: |
| 13:04 |
mmorgan |
In the "Email Checkout Receipt" Action trigger... |
| 13:04 |
mmorgan |
Blank the Opt-In Setting Type field. |
| 13:04 |
mmorgan |
and save the trigger. |
| 13:05 |
csharp |
mmorgan++ |
| 13:05 |
bos20k |
That makes sense based on the code I'm looking at in register.js |
| 13:05 |
bos20k |
mmorgan++ |
| 13:14 |
kmlussier |
abneiman: Thanks! |
| 13:27 |
bos20k |
Hmmm, it didn't work. I set the opt_in_setting to NULL in the database for the Email Checkout Receipt action trigger and also disabled it. Still shows in the patron edit/reg screens. |
| 13:31 |
Dyrcona |
bos20k: You quit the client and sign in again after? |
| 13:31 |
bos20k |
Dyrcona: yup. restarted EG on the test system too. |
| 13:31 |
bos20k |
Cleared the cache as well. |
| 13:33 |
mmorgan |
bos20k: Hmm. Close out and login again? I made the change in the client and no logout or cache clearing was necessary. |
| 13:33 |
Dyrcona |
Well, the trigger would have nothing to do with the client view. I'm not sure if the opt-in setting does either. I'd have to check. |
| 13:35 |
* mmorgan |
is working on 2.12 FWIW. |
| 13:40 |
kmlussier |
I just followed mmorgan's steps on the 2.12.3 MassLNC demo server and was able to remove the setting from the patron registration form. |
| 13:41 |
bos20k |
Are you editing the action trigger in the database directly or somewhere else? When I was looking at the action trigger in the staff client I didn't see where to remove the Opt-In Setting Type |
| 13:42 |
bos20k |
So I did what I thought was correct in the database directly. |
| 13:42 |
* mmorgan |
just tested on a couple of other opt in triggers. It looks like Enabled needs to be unchecked and the opt-in setting type needs to be NULL. |
| 13:43 |
mmorgan |
I edited the action trigger under Admin - Local - Notifications/Action triggers. |
| 13:44 |
mmorgan |
the Opt-In Setting Type dropdown is 3 fields above the template. I selected and deleted the text in the Opt-In Setting Type field and saved. |
| 13:45 |
mmorgan |
When I next loaded a clean patron registration form, the preference did not display. |
| 13:46 |
kmlussier |
I was editing in the staff client too. |
| 13:47 |
bos20k |
I had forgotten about the need to double click on the action trigger instead of the link... I hate that. |
| 13:48 |
mmorgan |
Oh, yes, been there, done that, too :) |
| 16:21 |
mmorgan |
So if my patron places a hold on Friday night, targeting my library's copy, and my library is closed on Saturday and Sunday, is it likely, or possible that when my patron's hold is retargeted on Sunday evening, that it will choose my library's copy again? |
| 16:22 |
mmorgan |
And yeah, yay holds! |
| 16:23 |
mmorgan |
We're targeting when closed if the copy and pickup lib match. |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:37 |
kmlussier |
abneiman++ |
| 16:51 |
|
Jillianne joined #evergreen |
| 16:57 |
|
jvwoolf joined #evergreen |
