| 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 |
| 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 |
| 00:18 |
|
remingtron_ joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:45 |
|
jvwoolf1 joined #evergreen |
| 07:49 |
|
jvwoolf2 joined #evergreen |
| 08:24 |
|
mdriscoll joined #evergreen |
| 13:26 |
mmorgan |
I'm looking at the views in the money schema, but not sure if that's the best way. |
| 13:26 |
|
rgagnon joined #evergreen |
| 13:30 |
kmlussier |
mmorgan: I think Dyrcona asked a similar question in here over the past 2 or 3 weeks. But I think he was looking for a random user, not working with a list of users, so the answer to his question may or may not be helpful. |
| 13:31 |
mmorgan |
Yes, I remember that discussion. He was just looking for a random patron that owed fines to test with. I'm not sure there was a definitive answer. |
| 13:47 |
|
tspindler joined #evergreen |
| 13:49 |
tspindler |
Evergreen Oversight Board meeting will start in 10 minutes |
| 13:56 |
|
sherbertbc joined #evergreen |
| 16:27 |
terran |
To be fair, I only hate it because I'm so bad at it. |
| 16:29 |
kmlussier |
terran: I hear ya |
| 16:29 |
kmlussier |
It's easy to be bad at git |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:33 |
Freddy_Enrique |
*Freddy suddenly remembers Dyrcona's words, and starts watching git tutorials |
| 16:44 |
|
Ryan_M joined #evergreen |
| 16:45 |
Ryan_M |
Hi! Can somebody help me refresh my catalog display to display the correct book cover? |
| 16:59 |
* Freddy_Enrique |
calls it a night too |
| 17:10 |
|
mmorgan left #evergreen |
| 17:32 |
|
jvwoolf1 left #evergreen |
| 18:12 |
pinesol_green |
[evergreen|Dan Wells] LP#1689656 Add test for manual adjustment of negative balance - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=702b196> |
| 18:12 |
pinesol_green |
[evergreen|Jeff Davis] LP#1689656: Adjust to zero on negative balance - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=40f820c> |
| 00:45 |
|
eady joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
JBoyer joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 08:48 |
|
mmorgan joined #evergreen |
| 09:04 |
JBoyer |
Doesn't look like it was backported to 2.11, but I imagine you shouldn't have too much trouble. Good luck! |
| 09:04 |
JBoyer |
mmorgan++ # Coaxing LP Search to work, heh |
| 09:06 |
mmorgan |
csharp: FWIW, in the past I have found that the action trigger produced the csv for large histories, but it never made it to the browser for download. So potentially you could find it in trigger output. |
| 09:06 |
csharp |
we just turned on circ history like last year or the year before, so that's probably why we'd be just now hitting it |
| 09:06 |
csharp |
mmorgan: I'll look - thanks for the leads! |
| 09:19 |
|
terran joined #evergreen |
| 09:21 |
|
yboston joined #evergreen |
| 09:28 |
|
mdriscoll joined #evergreen |
| 09:37 |
* csharp |
blows the dust off his xenial test server for bug squashin' |
| 09:55 |
|
maryj joined #evergreen |
| 09:58 |
|
Christineb joined #evergreen |
| 10:05 |
|
mmorgan1 joined #evergreen |
| 10:41 |
|
mmorgan joined #evergreen |
| 10:47 |
dbs |
hey miker super-naive question here, but in the absence of that UNIQUE CONSTRAINT should I ever have two rows in metabib.browse_entry where sort_value & value are identical? |
| 10:48 |
pinesol_green |
[evergreen|Jason Boyer] LP1704463: Item Status Fields Correction - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a15dc23> |
| 10:49 |
dbs |
(because of course my attempt to add a unique index using substring() is failing due to duplicates; example 1 being https://laurentian.concat.ca/eg/opac/results?query=a+compleat+history+of+europe+or+a+view+of+the+affairs+thereof+civil+and+military+for+the+year+1705+containing+all+the+publick+and+secret+transactions+therein+the+several+steps+taken+by+france+for+an+universal+monarchy+and+to+enslave+her+neighb |
| 10:49 |
dbs |
ours+the+wars+in+italy+poland+germany+netherlands&qtype=title&fi%3Asearch_format=&locg=105 |
| 10:50 |
dbs |
was trying with a simplistic: CREATE UNIQUE INDEX CONCURRENTLY browse_entry_sort_value_value_key ON metabib.browse_entry (SUBSTRING(sort_value FROM 0 FOR 2048), SUBSTRING(value FROM 0 FOR 512)); |
| 10:52 |
* dbs |
has never dealt with browse stuff before, yay 2.12 upgrade tests :) |
| 10:53 |
* dbs |
ponders throwing the ID field into the mix to guarantee uniqueness, heh |
| 10:59 |
|
Jillianne joined #evergreen |
| 11:04 |
pinesol_green |
[evergreen|Martha Driscoll] LP#1692106: Z39.50 server includes prefix and suffix in 852 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e8a19ad> |
| 11:06 |
pinesol_green |
[evergreen|Galen Charlton] LP#1691560: start open-ils.qstore service by default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=95aa127> |
| 14:15 |
|
kmlussier joined #evergreen |
| 14:39 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1486451: Remove rdetails_status nowrap style - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e2c70de> |
| 16:25 |
* phasefx |
just got bit by a launchpad timeout error.. going to rewrite the ticket in vim first :D |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:50 |
|
Jillianne joined #evergreen |
| 16:57 |
phasefx |
berick: dbs: kmlussier: https://bugs.launchpad.net/evergreen/+bug/1704873 |
| 16:57 |
pinesol_green |
Launchpad bug 1704873 in Evergreen "webstaff item print labels" [Undecided,New] |
| 01:42 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:19 |
|
agoben joined #evergreen |
| 07:24 |
|
rjackson_isl joined #evergreen |
| 10:05 |
Dyrcona |
Yes, on 2.12.3 plus customizations. |
| 10:06 |
Dyrcona |
I've seen issues with ISBN searches before, but it seemed randomish and I never tracked it down. |
| 10:08 |
kmlussier |
Dyrcona: Yeah, the one I replicated was with the metarecord searches. Those are a little easier to make happen. Were the ISBN issues you saw prior to 2.12? |
| 10:09 |
Dyrcona |
kmlussier: I'm not certain. It may have been on test servers. I'm not sure I've seen it in production on 2.10, still. |
| 10:20 |
Dyrcona |
So, when are we moving search out of the database and using a real search engine? |
| 10:20 |
* Dyrcona |
ducks the flying duck decoys. :) |
| 10:25 |
dbs |
Also on nginx proxying maybe we rely on nginx to do all of the TLS work and just proxy Apache on port 80? |
| 13:27 |
Dyrcona |
jeffdavis++ |
| 13:29 |
Dyrcona |
What does the ebook_api.ebook_test.enabled setting do? |
| 13:29 |
Dyrcona |
Oh never mind. I think I see what it does. |
| 13:29 |
Dyrcona |
It enables a test provider. |
| 13:30 |
jeffdavis |
Yeah, same one the live tests use. |
| 13:32 |
jeffdavis |
If you load the concerto dataset and do an OPAC search for "tolkien" with the test provider enabled, you should see it at work. |
| 13:32 |
Dyrcona |
Well, we've got it mostly working, so far. Are the users check outs and holds supposed to be showing up? |
| 13:33 |
jeffdavis |
Yeah, transactions should be displayed in separate "E-Items Checked Out" / "E-Items on Hold" tabs in My Account |
| 13:33 |
jeffdavis |
actually performing checkouts and holds from the OPAC should be possible in 3.0, I have a working branch for that to be pushed today actually |
| 13:56 |
|
Jillianne joined #evergreen |
| 14:08 |
stompro |
dbs++, thanks for pointing out the other nowrap fix. |
| 14:37 |
|
jvwoolf joined #evergreen |
| 15:23 |
jeffdavis |
I've shared a working branch for bug 1673870. I'll be away for the next couple of weeks, but if anyone wants to test what's there, please feel free. |
| 15:23 |
pinesol_green |
Launchpad bug 1673870 in Evergreen "Add support for ebook API transactions in OPAC (OverDrive/OneClickdigital)" [Undecided,New] https://launchpad.net/bugs/1673870 - Assigned to Jeff Davis (jdavis-sitka) |
| 15:24 |
kmlussier |
jeffdavis++ |
| 15:24 |
kmlussier |
That's exciting! |
| 15:45 |
jeffdavis |
I don't recall if you need to request discovery/circ access separately - I think you get them both when you have patron auth. |
| 15:59 |
JBoyer |
jeffdavis++ |
| 15:59 |
JBoyer |
Something to look into in a couple weeks when I have time again. |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:09 |
|
jvwoolf left #evergreen |
| 18:53 |
|
Bmagic joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:54 |
|
rlefaive joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:33 |
|
agoben joined #evergreen |
| 11:54 |
Dyrcona |
:) |
| 11:55 |
jeff |
hrm. that's weird. the Sitka manual for 2.10 includes things like "new in evergreen version 2.12": http://docs.sitka.bclibraries.ca/Sitka/sitka_2_10/html/ |
| 11:55 |
Dyrcona |
I was gonna try his patches later, but you beat me to it. |
| 11:56 |
* Dyrcona |
has been writing a php script to test some SIP code. |
| 11:56 |
jeff |
oh, hah-- the sections say 2.12 but appear to describe 2.10 features. |
| 11:57 |
jeff |
Dyrcona: using tsbere's lib or something else / from scratch? |
| 11:57 |
csharp |
@who foresaw 2.12 features? |
| 11:57 |
pinesol_green |
sard foresaw 2.12 features. |
| 11:57 |
Dyrcona |
jeff: Using tsbere's lib, and I think I'm going to add a debug option to log the messages that are sent and received. |
| 11:58 |
Dyrcona |
I also used PDO to retrieve a list of patron bacordes from the database likely to test the new feature. |
| 12:00 |
jeff |
which new feature? |
| 12:00 |
Dyrcona |
It's an improvement to fine item details. I'm not sure we've made a Lp bug, yet. |
| 12:00 |
jeff |
i've found interesting bugs in the past by fetching all users and / or all items, etc. :-) |
| 12:01 |
Dyrcona |
if FineItems is > 0, then I look them up again, requesting the fine item details. |
| 12:02 |
|
rlefaive joined #evergreen |
| 12:02 |
Dyrcona |
So far, nothing has turned up. :( |
| 12:07 |
Dyrcona |
jeff: I think I may turn up something broken, whether that's the new code, old code, or my test environment, I'm not sure, yet. |
| 12:13 |
Dyrcona |
This might be something to do with th PHP library: Unsupported field 'AY' in Patron Info message |
| 12:13 |
Dyrcona |
It doesn't seem to prevent the message from being processed. I'll look into it later. |
| 12:17 |
|
jihpringle joined #evergreen |
| 16:23 |
phasefx |
bshum: roger that |
| 16:24 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1686832 |
| 16:24 |
pinesol_green |
Launchpad bug 1686832 in Evergreen "fieldmapper changes break with translations" [Medium,Triaged] |
| 16:24 |
bshum |
But I *think* that if one were to not use the ansible installer with the i18n options, it should just install clean and happy |
| 16:25 |
* bshum |
hasn't tested that theory lately |
| 16:25 |
* bshum |
usually builds with i18n and then runs his own magic POT sync to fix things |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:36 |
phasefx |
yay, it's all working, even the webstaff client |
| 16:38 |
|
mmorgan1 joined #evergreen |
| 16:38 |
phasefx |
though settings-tester.pl warns that libdbi PostgreSQL driver not found in shared library path |
| 10:57 |
JBoyer |
I did turn it off on my machines eventually. |
| 10:57 |
JBoyer |
But Proper Testing (tm) sounds interesting, I'm curious to see what you find. |
| 10:58 |
|
rlefaive joined #evergreen |
| 10:58 |
Dyrcona |
I've never used pg_bench before, so it might take me a few weeks to do proper testing. |
| 11:01 |
Dyrcona |
So, I'll try -j 40 just for kicks. :) |
| 11:31 |
dbs |
Am I wrong in thinking that each of the records linked to a conjoined item should show the call number / copy info? |
| 11:33 |
dbs |
For example, https://laurentian.concat.ca/eg/opac/record/3111007 shows it is linked to "Douglas-fir" but the corresponding record https://laurentian.concat.ca/eg/opac/record/3111012 doesn't show a call number, making it hard / impossible to find on the shelf |
| 15:53 |
rjackson_isl |
Dyrcona++ mystery solved then? ;) |
| 15:54 |
kmlussier |
Dyrcona: Yeah, now that you mention it, I think I knew that. I spent a bit of time looking closely at those screens a month or two ago. |
| 15:54 |
kmlussier |
dbs++ |
| 15:54 |
dbs |
(because of course our test Concerto records all have additional copies on them) |
| 15:58 |
kmlussier |
dbs: Yes, even the records for electronic resources have copies on them, which isn't ideal. I've been meaning to submit a patch to add e-resource records with just URIs. |
| 16:01 |
* dbs |
has only himself to blame for that |
| 16:03 |
kmlussier |
dbs: Blame for giving us a set of test records we can work with? |
| 16:15 |
|
jvwoolf joined #evergreen |
| 16:17 |
Dyrcona |
About email payment receipts: It appears also that is the only way to trigger the event at the moment. |
| 16:18 |
* Dyrcona |
smells an enhancement request coming in the near future. |
| 16:23 |
Dyrcona |
And, it looks like we missed a release note for 2.10 regarding that event. I'll have to do an update on the event defs' template fields. |
| 16:27 |
dbs |
Might be as simple as adding "IF ctx.foreign_copies; has_copies = 'true'; END;" to copy_table.tt2 |
| 16:30 |
pastebot |
"dbwells" at 64.57.241.14 pasted "foreign copies local change (dbs)" (13 lines) at http://paste.evergreen-ils.org/181 |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
dbwells |
dbs: Just checking in for the first time today, ^^ is a patch we have locally. |
| 16:32 |
dbwells |
dbs: really the same idea as you state |
| 16:35 |
dbs |
thanks dbwells - also there's some jankiness in the trigger to update asset.opac_visible_copies (freaks out if there's already an entry when you try to add a conjoined item and makes it fail) |
| 16:41 |
* dbwells |
should make a branch for the other as well while it has his attention. |
| 16:46 |
kmlussier |
dbwells++ dbs++ |
| 16:46 |
dbs |
also fixing up the use of "copy_info.location" where we actually need bib.target_copy.location.name and the like |
| 16:55 |
dbwells |
dbs++ sounds good. We apparently didn't get that far. By the time we got things to show up, the librarian testing it out had moved on to something else, and it hasn't come around again for us. We have something like 100-200 bound volumes, so it naturally doesn't get much priority :( |
| 16:58 |
|
jvwoolf joined #evergreen |
| 16:58 |
dbs |
dbwells: bug 1703678 for your enjoyment |
| 16:58 |
pinesol_green |
Launchpad bug 1703678 in Evergreen "Conjoined items do not display without an extra copy attached to the record" [Undecided,New] https://launchpad.net/bugs/1703678 |
| 16:59 |
dbwells |
dbs: off-topic question, but something eating my time lately, do you guys do anything in the ilk of "institutional repository"? We've run a few test instances of various products over the years, but our only production collections are homegrown. We're getting ready to try out Invenio. Just curious. |
| 16:59 |
dbs |
have to go pick up a kid but will be back in a while -- and yes we have run DSpace in production since 2007 and it's a Java monster :) |
| 17:00 |
dbwells |
dbs: cool, I will maybe pick your brain about it sometime in the future. |
| 17:02 |
|
jvwoolf1 joined #evergreen |
