| 10:16 |
Dyrcona |
Is it a "real" problem, i.e. the bill doesn't actually show as paid, or is it just an cosmetic problem because staff don't like the payment predating the bill? |
| 10:18 |
Dyrcona |
jeff: BTW, I pushed some updated billing branches last night and fixed its issues with the fine generator. So, I'm a bit sensitive about changes that would require me to make more changes to my code. :) |
| 10:19 |
Dyrcona |
Ah, I see how it could be a real problem if you're looking at it on that day.. billing_ts < now() might pose an issue, eh? |
| 10:21 |
phasefx |
incidentally, a qa test involving fines failed the past two nights. I'm poking |
| 10:24 |
|
yboston joined #evergreen |
| 10:25 |
jeff |
Dyrcona: it's an issue when i'm working on bug 1174498 / mmpbbt |
| 10:25 |
pinesol_green |
Launchpad bug 1174498 in Evergreen "Payment by billing type breakdown" (affected: 3, heat: 14) [Wishlist,In progress] https://launchpad.net/bugs/1174498 - Assigned to Jeff Godin (jgodin) |
| 10:35 |
berick |
yeah |
| 10:36 |
RoganH |
I just sat down with three of our full time circ staff and had them play with Bill's web based staff client. They wanted to know how soon it could be finished and they could use it up front. |
| 10:39 |
jeff |
Dyrcona: got to the end of the comment on that function with a "these words sound vaguely familiar" feeling, then read the last statement on the comment, laughed |
| 10:41 |
berick |
RoganH++ # field testing |
| 10:41 |
berick |
very cool |
| 10:43 |
Dyrcona |
jeff: The comments in the function are meant to be helpful, too. :) |
| 10:43 |
Dyrcona |
But, yeah, your code was the inspiration even if it looks very different now. |
| 10:44 |
Dyrcona |
RoganH++ # Being braver than I. |
| 10:59 |
Dyrcona |
jeff: The reason for going by payment/bill amount was that it would likely match lost payments up with lost billings more accurately than a simple date-based approach. |
| 11:00 |
Dyrcona |
tsbere: That's probably true in any setting when humans are involved. :) |
| 11:13 |
|
rfrasur joined #evergreen |
| 11:35 |
bshum |
phasefx: Were those failed tests new to the testing suite? Or was it something that we've changed in master since the new year began? |
| 11:35 |
jeff |
one solution to future-billings and mmpbbt: treat overdue billings with 23:59 timestamp as -1 day :-) |
| 11:36 |
bshum |
phasefx: The only thing that's changed in master was altering the stock org unit data, so maybe that's something. Otherwise, the rest are catalog changes so far as I can tell. |
| 11:38 |
* Dyrcona |
wouldn't be surprised if something in the test environment changed. |
| 11:38 |
phasefx |
bshum: I'm suspecting environment (date, timezone, external package) and not recent code changes |
| 11:38 |
Dyrcona |
jinx! |
| 11:38 |
phasefx |
I've been pulled away from poking though |
| 11:38 |
Dyrcona |
test == more code == more bugs. :p |
| 11:42 |
bshum |
Heh |
| 11:43 |
eeevil |
jeff: re "one solution to future-billings and mmpbbt", how about just billing_ts::date::timestamptz if billing_ts::time = '23:59:59'; -- adjust spelling of time as required |
| 11:43 |
jeff |
eeevil: better, i think. |
| 11:54 |
jeff |
eeevil: i got what you meant, but thanks for making sure. :-) |
| 11:56 |
eeevil |
jeff: probs, yes, re quirks |
| 11:57 |
* jeff |
looks at live_t/05-pay_bills.t |
| 12:01 |
phasefx |
jeff: those tests depend on preceding tests, so 03-overdue-circ is where I would look first; if you're looking because of the failure |
| 12:02 |
jeff |
phasefx: sorry, i was looking because i wanted to add some billing / overdue / checkin / backdate / etc related tests, and wanted to see what was already there |
| 12:02 |
phasefx |
gotcha |
| 12:03 |
jeff |
phasefx: thanks, though -- at least one comment or the commit message made that part clear also (that the tests relied on each other) |
| 12:04 |
jeff |
oh, the text of the test itself clued me in: Two billable xacts for admin user from previous tests |
| 12:33 |
|
snowball_ joined #evergreen |
| 12:33 |
|
snowball_ left #evergreen |
| 12:36 |
phasefx |
so 03-overdue-circ, I think the test assumptions are flawed. Fines didn't get created for the 28th and 29th of December.. those are on a weekend, and hours of operation with the stock test data have those days as closed for BR4. So no fines? |
| 11:39 |
Dyrcona |
All it appears to do is cause the code to skip voided fines when looking for the most recent billing to print information to the logs. |
| 11:54 |
jeff |
eeevil: how's your memory of $overbill in commit 2bf6f120 ? :-) |
| 11:54 |
pinesol_green |
[evergreen|miker] auto-billing fixes and hold processing bug - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2bf6f12> |
| 11:54 |
jeff |
i don't see any signs of it being currently used. i wonder if it was used for test/debug. |
| 11:56 |
eeevil |
jeff: I'll look. it was certainly used in the olden days, from the first over-night fine generator script |
| 11:59 |
eeevil |
jeff: or, rather, was something one could specify |
| 12:00 |
jeff |
yeah, i guess "not specified by default" was what i was seeing in my quick look through history. |
| 15:26 |
|
ktomita_ joined #evergreen |
| 15:26 |
|
sseng joined #evergreen |
| 15:26 |
|
fparks joined #evergreen |
| 15:30 |
kmlussier |
In my previous testing, "contains phrase" means contains exact phrase and "matches exactly" meant an exact match. |
| 15:32 |
|
librarian joined #evergreen |
| 15:33 |
kmlussier |
bshum: Everyone should come to Boston. :) |
| 15:50 |
csharp |
RoganH: thanks for the info re: VMs |
| 15:50 |
csharp |
bshum: I was going to build it on Ubuntu 12.04 |
| 15:51 |
RoganH |
csharp: No problem. |
| 16:22 |
bshum |
Isn't that a 2.3 system? |
| 16:22 |
bshum |
Or you working with their 2.5? |
| 16:22 |
bshum |
(new QP and all that jazz, who knows, am I right?) |
| 16:22 |
kmlussier |
Oh, wait. That's right. You're on a test system. Sorry. |
| 16:23 |
bshum |
I'd be curious to see some of the data that's being stored on the system side for the records in question. Like grabbing all the title values from metabib.title_record_entry for a given set of bibs |
| 16:23 |
bshum |
Just to see what's been indexed and how |
| 16:24 |
kmlussier |
In 2.3, "matches exactly" didn't work at all. It retrieved the same results as a simple contains search. |
| 17:11 |
pinesol_green |
Dyrcona: Zoia knows how to make fusilli. |
| 17:12 |
bshum |
Hmm, csharp, do you remember offhand where https://bugs.launchpad.net/evergreen/+bug/1255561 is doing the barcode lookup? |
| 17:12 |
pinesol_green |
Launchpad bug 1255561 in Evergreen "OPAC: username that starts with a number is treated like a barcode" (affected: 1, heat: 6) [Undecided,New] |
| 17:12 |
Dyrcona |
kmlussier: I should have a fix for my fine generator issues tonight, so you can resume testing tomorrow. |
| 17:12 |
bshum |
I have a library who's actually broken by this. Cause apparently their active directory usernames start with numbers... |
| 17:12 |
kmlussier |
Dyrcona++ |
| 17:13 |
tsbere |
bshum: The barcode regex OU setting, at the top level of the tree, may help? |
| 17:32 |
|
dcook joined #evergreen |
| 18:43 |
|
ktomita joined #evergreen |
| 18:43 |
|
ktomita_ joined #evergreen |
| 18:53 |
jeff |
test |
| 18:53 |
jeff |
hah |
| 18:53 |
jeff |
oops. :-) |
| 19:35 |
|
j_scott joined #evergreen |
| 20:23 |
|
stevenyvr2 left #evergreen |
| 21:54 |
|
dcook joined #evergreen |
| 11:04 |
dbs |
Just copy the file(s) that you want to tweak and add the new template directory to your list of template overrides |
| 11:05 |
dbs |
Or if this is purely for local dev purposes, you could just use git and "cp -r Open-ILS/src/templates/* /openils/var/templates/." from time to time :) |
| 11:05 |
dbs |
(also assuming /openils/ prefix) |
| 11:05 |
mrpeters |
yeah, im just hacking around with some customizations |
| 11:06 |
mrpeters |
but wanted them to be able to use their DB (no test server available) |
| 11:06 |
* dbs |
tends to use the latter method when developing |
| 11:06 |
roses |
csharp: I'm trying to set up this weeding report that you created http://libmail.georgialibraries.org/pipermail/open-ils-general/2012-September/007430.html and can't seem to get either the base or aggregate filters to both stay not grayed out. I did some other searching and found out you "hate" that - but didn't find out how to get around it. |
| 11:06 |
dbs |
mrpeters: ah, in that case, yes, a second vhost with an extra templates directory with just the files you want to override would be bestest |
| 11:25 |
|
BigRig joined #evergreen |
| 11:27 |
|
BigRig_ joined #evergreen |
| 11:36 |
dbs |
bshum: I'll give the Date module a go to see if I can do a better job formatting times according to chosen locales |
| 11:37 |
bshum |
dbs: Cool! I'll be happy to test further on my end. Still looking things over to see how it works. |
| 11:40 |
dbs |
"how" is a good step forward from "if" :) |
| 11:51 |
|
granitize joined #evergreen |
| 11:55 |
|
snowball_ joined #evergreen |
| 11:24 |
mrpeters |
and then you can examine the configuration to see what you might have missed (permissions, etc.) |
| 11:25 |
bshum |
saravanakumar: When you said Ubuntu 12.04 LTS earlier, was that desktop or server? Or some other flavoring |
| 11:25 |
mrpeters |
^^ good question bshum |
| 11:25 |
saravanakumar |
its a desktop bshum |
| 11:26 |
saravanakumar |
but we are using it as testing machine |
| 11:26 |
bshum |
Evergreen was only tested and supported with the server editions, so I don't know if there's quirks at play with others (though missing dependencies seems like bad install problems) |
| 11:26 |
saravanakumar |
hmm |
| 11:26 |
bshum |
I know there's been reported troubles by others in the past with desktop edition of ubuntu. |
| 11:26 |
saravanakumar |
but its 64bit machine |
| 11:26 |
bshum |
Since it's not supported for Evergreen, we've skipped most of it. |
| 11:29 |
bshum |
But basically, Evergreen is well tested (and running) with libraries on Ubuntu 12.04 LTS server, the 64-bit edition. |
| 11:29 |
bshum |
I don't think we test at all with 32-bit anymore. And not for desktop edition. |
| 11:30 |
mrpeters |
install ubuntu server 12.04 and add a desktop environment later if you need it |
| 11:35 |
bshum |
The missing deps above make me nervous that something went screwy with the Makefile.install ; which wouldn't surprise me if it blew up over the wrong edition of Ubuntu :( |
| 12:20 |
saravanakumar |
ubuntu has same kernel for server and desktop environment from 12.04. So that should work on desktop env too |
| 12:47 |
bshum |
:) |
| 12:52 |
phasefx_ |
anyone running a wheezy server? |
| 12:53 |
bshum |
Not presently. |
| 12:53 |
phasefx_ |
this is driving me nuts: http://paste.evergreen-ils.org/47 |
| 12:54 |
phasefx_ |
that Cannot determine local time zone is happening with the perl live tests in EG on this one server |
| 12:54 |
phasefx_ |
http://testing.evergreen-ils.org/~live/test.22.html |
| 13:01 |
* phasefx_ |
will try an earlier version of DateTime::Timezone |
| 13:03 |
bshum |
I was about to ask, what's the expected output supposed to be? |
| 13:03 |
bshum |
My Ubuntu test server listed 0.70 and 1.42 for versions, respectively. |
| 13:03 |
bshum |
But the output lines following were just the directory I was in, twice. |
| 13:04 |
phasefx_ |
on my squeeze system: DateTime->VERSION 0.61 / DateTime::TimeZone->VERSION 1.20 / /home/opensrf / /home/opensrf |
| 13:04 |
phasefx_ |
no errors |
| 13:04 |
bshum |
I see, so it's supposed to show nothing. Got it :) |
| 13:10 |
* phasefx_ |
tries updating |
| 13:11 |
bshum |
What's in /etc/timezone on your unhappy server? :) |
| 13:12 |
bshum |
(just curious) |
| 13:12 |
phasefx_ |
SystemV/EST5 |
| 13:12 |
phasefx_ |
alright, after an upgrade, that perl snippet reports the same versions but we get the error. The debian version of datetime::timezone did go up |
| 13:13 |
phasefx_ |
from 1:1.58-1+2013c to 1:1.58-1+2013h |
| 13:14 |
phasefx_ |
debian changelog shows updates to an "Olson database" |
| 13:15 |
phasefx_ |
I don't know if this affects anything other than the local server-side perl tests |
| 13:15 |
phasefx_ |
well, it does affect srfsh |
| 13:15 |
phasefx_ |
if doing a checkout.full through it |
| 13:17 |
phasefx_ |
is simply changing the conents of /etc/timezone a sane thing to try? <tries it anyway> |
| 13:17 |
phasefx_ |
ha, that worked |
| 13:17 |
phasefx_ |
changed it to America/New_York |
| 13:18 |
phasefx_ |
bshum++ |
| 13:18 |
bshum |
Oh cool |
| 13:18 |
bshum |
I was off googling SystemV/ESTS |
| 13:18 |
bshum |
I had no clue what that meant :) |
| 13:18 |
phasefx_ |
EST5 |
| 13:18 |
eeevil |
yeah, EST5 is not an olson format tz |
| 13:20 |
eeevil |
i guess debian got a bit more strict in their tz db update for dt::tz... |
| 13:21 |
phasefx_ |
probably worth adding a variation of that perl snippet to settings-tester |
| 13:21 |
phasefx_ |
or a perl live test |
| 13:27 |
|
mceraso joined #evergreen |
| 13:27 |
|
bshum joined #evergreen |
| 13:30 |
|
kmlussier joined #evergreen |
| 10:11 |
csharp |
Fedora's great if you can just stick to the official repos for everything |
| 10:11 |
dbs |
Bmagic: okay, i'm sure you're following some of the bugs that I've run into because Fedora tends to be ahead of most distros. Encode.pm comes to mind |
| 10:11 |
csharp |
3rd-party repos tend to lag a bit in my experience |
| 10:11 |
Bmagic |
csharp: We are running it on debain now, and would like to test the waters more seriously on Fedora due to the Hyper-V issue I mentioned |
| 10:11 |
dbs |
Bmagic: https://bugs.launchpad.net/evergreen/+bug/1242999 for example |
| 10:12 |
pinesol_green |
Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [High,Confirmed] |
| 10:12 |
Dyrcona |
csharp: While official Debian and Ubuntu repos tend to lag a lot, and often have bugs that go unfixed. |
| 10:12 |
Bmagic |
dbs: Thanks for the heads up. I've installed this a few times on Fedora and I seem to remember hitting the Encode issue once before |
| 10:12 |
csharp |
Bmagic: have you benchmarked KVM in your testing? that might be a better supported alternative |
| 10:12 |
dbs |
Bmagic: that also motivates me to update the MARC::Record + friend packages that I maintain to be the most current versions :) |
| 10:12 |
* Dyrcona |
uses Ubuntu for those who don't know. |
| 10:13 |
csharp |
Dyrcona: yeah - I'd rather have lingering bugs than zero-day(-ish) bugs if I'm running something in production |
| 10:18 |
dbs |
The good thing about Fedora in production is that its support cycle almost syncs up with Evergreen's |
| 10:18 |
dbs |
So you could just deploy fresh every 12 months :) |
| 10:19 |
Dyrcona |
Ooh, now you're talking about being a couple of releases behind. :) |
| 10:19 |
csharp |
Bmagic: I got OpenSRF master installed on CentOS 6 recently |
| 10:19 |
csharp |
(in a bare-bones test instance, I should add) |
| 10:19 |
Bmagic |
csharp: OpenSRF and Evergreen? |
| 10:19 |
* Dyrcona |
is seriously considering do Linux from Scratch on a laptop if he can find the time. |
| 10:20 |
Bmagic |
Gentoo? |
| 10:27 |
csharp |
s/Debian/packaging for Debian/ |
| 10:28 |
* csharp |
has hopes of cleaning up our deb-builder utility for more general use |
| 10:28 |
csharp |
but that will be after our MLK weekend upgrade |
| 10:28 |
dbs |
Bmagic: well, there's a fix for that in the bug I posted |
| 10:29 |
dbs |
But because nobody else is hitting it yet, nobody else is motivated to really work on testing the final results (understandably) |
| 10:30 |
csharp |
fedora++ |
| 10:30 |
Bmagic |
We really would like this to work on fedora and it seem so close fedora++ |
| 10:32 |
csharp |
Bmagic++ #trailblazing |
| 14:22 |
gmcharlt |
OK, thanks dbwells! |
| 14:22 |
gmcharlt |
moving on to the next item in the agenda |
| 14:22 |
gmcharlt |
#topic Finding volunteer to update the Evergreen map |
| 14:22 |
elfstrand |
We have a beta version but can't get to test with OCLC untill Late Jan might not make it in tiomne for 2.6 |
| 14:22 |
gmcharlt |
sborger: you have the floor |
| 14:23 |
sborger |
Okay, we had a conference program planning committee meeting which prompted us to discuss the State of Evergreen presentation. |
| 14:24 |
sborger |
The State of Evergreen program is traditionally presented at the beginning of the conference and has been accompanied by the Evergreen International map. |
| 14:35 |
|
dMiller___ joined #evergreen |
| 14:35 |
bshum |
Dyrcona: So I applied the other commit from bug 1243280 and so far no pointless warning errors anymore. |
| 14:35 |
pinesol_green |
Launchpad bug 1243280 in Evergreen 2.5 "'TypeError: obj.active_services is undefined' error when entering z39.50 MARC import UI" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1243280 |
| 14:35 |
bshum |
I'm testing the different parts of the client and so far, so good. |
| 14:35 |
bshum |
Might apply both commits |
| 14:36 |
Dyrcona |
OK. The other one just makes a useless console warning disappears. |
| 14:36 |
Dyrcona |
It checks if some field exists before using it. |
| 14:36 |
bshum |
Yeah, that's what I thought |
| 15:56 |
mrpeters |
ah, i remember this old friend |
| 15:56 |
mrpeters |
ERROR: cannot drop view metabib.full_rec because other objects depend on it |
| 15:56 |
mrpeters |
needs to be a drop cascade |
| 15:58 |
bshum |
mrpeters: What are the other dependent objects? MIght be non-stock stuff at play that wasn't shown during testing. |
| 15:58 |
bshum |
(there was lots of that and we noted a few with the reporter views) |
| 15:58 |
mrpeters |
hmm whats the easiest way to tell? |
| 15:59 |
mrpeters |
DETAIL: view reporter.steve_old_super_simple_record depends on view metabib.full_rec |
| 15:59 |
mrpeters |
heh, yeah thats probably not stock :P |
| 17:01 |
|
mmorgan left #evergreen |
| 17:03 |
|
pmurray_away joined #evergreen |
| 17:05 |
|
pmurray_away joined #evergreen |
| 17:09 |
dbs |
berick++ # thanks for giving the library sample data branch a test run |
| 17:10 |
|
pmurray left #evergreen |
| 17:10 |
* dbs |
scoots |
| 17:16 |
|
netadres joined #evergreen |
| 17:22 |
|
mceraso joined #evergreen |
| 17:22 |
|
bshum joined #evergreen |
| 11:21 |
|
paxed joined #evergreen |
| 11:21 |
|
tsbere joined #evergreen |
| 11:23 |
|
akilsdonk joined #evergreen |
| 11:24 |
pinesol_green |
[opensrf|Galen Charlton] LP#1180849: test case - ignoring subrequest responses after respond_complete() - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=59b4dd7> |
| 11:24 |
pinesol_green |
[opensrf|Mike Rylander] Protect subrequests from post-complete messages - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a0d5b05> |
| 11:26 |
|
jboyer-isl joined #evergreen |
| 11:26 |
|
jeffdavis joined #evergreen |
| 11:30 |
pinesol_green |
[opensrf|Bill Erickson] OpenSRF client disconnect robustification (Perl) - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b0a41d3> |
| 11:30 |
bshum |
I hate netsplits. |
| 11:30 |
rfrasur |
I hate socks that slide off when you're wearing snow boots. |
| 11:36 |
|
b_bonner_ joined #evergreen |
| 11:52 |
csharp |
dbwells: re: bug 1261355, my next step in troubleshooting was to begin commenting out each numbered script subsection in turn until I find the cause on our DB |
| 11:53 |
pinesol_green |
Launchpad bug 1261355 in Evergreen "2.4.3-2.5.0-upgrade-db.sql causing "could not find trigger" PostgreSQL error" (affected: 2, heat: 10) [Undecided,Confirmed] https://launchpad.net/bugs/1261355 |
| 11:55 |
dbwells |
csharp: sounds like a good approach. I was assuming the 'SET CONSTRAINTS' was part of the issue, but Robert's comment makes it sound like the same error can happen when skipping straight to 'COMMIT' |
| 11:55 |
bshum |
dbwells: fwiw, I also tried using a 2.4.3 DB with concerto yesterday when csharp first mentioned it in IRC and couldn't replicate the problems either. |
| 11:56 |
bshum |
I don't have a younger DB (not master) to test further with. |
| 12:02 |
csharp |
it's possible that it's something about older installs that have been upgraded through each release? |
| 12:02 |
* csharp |
shrugs |
| 12:03 |
bshum |
Or it's just a table that has stuff in it that concerto doesn't normally. |
| 12:20 |
bshum |
Fwiw, it's not unprecedented to split apart pieces of the major version upgrade scripts into separate BEGIN; COMMIT; blocks. It's just not good for safe rollbacks :( |
| 12:20 |
tsbere |
The big monolithic upgrade scripts should probably be rigged in "schema changes first, then data changes" order or something. But I don't use them so I dunno. |
| 12:20 |
bshum |
Yeah, there's alot of hand editing that goes into them. |
| 12:21 |
csharp |
well, there has been less hand editing this go-round for me, but yeah |
| 12:22 |
|
enrichtomsk joined #evergreen |
| 12:23 |
csharp |
for our 2.5.1 test server, running the numbered upgrade scripts to go from 2.4.3 to 2.5.1 was fine, so I may do 'for i in `cat list-of-numbered-scripts`; do PGUSER=evergreen psql -f $i evergreen; done' |
| 12:26 |
csharp |
the only issue with that is the partial reingests that get kicked off sometimes, but Ctrl-C is easy enough |
| 12:27 |
bshum |
See, csharp, you're only inches from just running master :) |
| 12:27 |
csharp |
well, on the DB, maybe ;-) |
| 12:27 |
* csharp |
resists the pull of the dark side |
| 10:05 |
* csharp |
decides to run VACUUM ANALYZE before running the script again |
| 11:07 |
|
RBecker joined #evergreen |
| 11:20 |
csharp |
nope - vacuum didn't help :-/ |
| 13:42 |
bshum |
Hmm, unrelated but the original 0827 doesn't have that in it. It's only in the upgrade script itself. So we probably never stumbled over that particular issue. |
| 13:43 |
bshum |
csharp: My vague googling is coming up with slony threads that include references to that error you mention about "could not find trigger" |
| 13:43 |
bshum |
Since we don't use slony, but you do, maybe that is related. |
| 13:43 |
|
stevenyvr2 joined #evergreen |
| 13:44 |
|
stevenyvr2 left #evergreen |
| 13:45 |
bshum |
Either way, I haven't run a version upgrade script in so long that I probably should stop now and let other folks think through it. |
| 13:45 |
bshum |
Good luck csharp, sorry I can't be more helpful right now. |
| 14:01 |
bshum |
Unrelated, it may be that we need both the --create-database and --create-schema flags for eg_db_config to create a remote database. The README only notes --create-database |
| 14:04 |
bshum |
And fwiw csharp, a clean 2.4.3 database with concerto running the 2.4.3-2.5.0 script went through just fine. Not that it's a good test, cause real production data is always better. But it doesn't seem to be an immediately broken script :( |
| 14:16 |
csharp |
bshum: thanks - I have another test db and I'm going to run the same script on it to see if it's a data corruption issue or something |
| 14:22 |
bshum |
@later tell dbs Curious if you think this article I was just reading about dojo.require and Firefox rendering makes sense. Maybe it could help with our autosuggest brokenness with Firefox lately? http://stackoverflow.com/questions/1943082/dojo-require-prevents-firefox-from-rendering-the-page |
| 14:22 |
pinesol_green |
bshum: The operation succeeded. |
| 14:24 |
bshum |
csharp: Cool deal, curious to see what happens :) |
| 14:27 |
bshum |
Eh, probably not it dbs, maybe nevermind |
| 14:36 |
bshum |
Hmm, so I turned on autosuggest on our test database. And then if I search in Chrome for something, it'll suggest it to me. |
| 14:36 |
bshum |
Interestingly, if I then search for the same term in Firefox, it suggests it to me. |
| 14:37 |
bshum |
It's probably cache or something |
| 14:45 |
bshum |
Oh well, off to shovel some snow and then get ready for the first Christmas party of this week. |
| 16:11 |
ldwhalen |
is anyone around who understands how pgTap tests are supposed to be used? |
| 16:14 |
jeff |
have you looked at the existing docs and the notes that dbs put in the Encode.pm bug? |
| 16:15 |
ldwhalen |
no, I looked at 1194246 |
| 16:17 |
jeff |
bug 1242999 |
| 16:17 |
ldwhalen |
thanks! |
| 16:17 |
jeff |
beyond that i don't have direct experience yet, but ask away! |
| 16:18 |
jeff |
(and soneone else with more direct experience may answer) |
| 16:19 |
ldwhalen |
I am modifying query_parser_fts, and I am not sure what type of tests I might run. I will look into this bug. |
| 16:28 |
ldwhalen |
From what I can see the pgTAP tests are testing the effects of data within the database. This modification is |
| 16:29 |
ldwhalen |
to a function. There are tests that could be run against it. But, I am not sure what the scope should be. |
| 16:29 |
ldwhalen |
It has 12 input parameters, so a complete test would be massive. |
| 16:30 |
ldwhalen |
I am going to add it to a workingg branch and put a pull request on the lp bug because that has been requested |
| 16:30 |
ldwhalen |
and these changes have been running live on Sitka for months. If a test is needed, I will write one. |
| 17:01 |
csharp |
interesting... if I 'grep block_check 2.4.3-2.5.0-upgrade-db.sql | cut -d"'" -f2' and apply those updates one at a time, I get no errors |
| 17:02 |
csharp |
so it must be something about the script + my data |
| 17:02 |
csharp |
or the script itself |
| 10:45 |
bshum |
I personally don't feel comfortable suggesting changing the name of the penalty without knowing whether anything depends on that vs. the IDs. |
| 10:46 |
Dyrcona |
"has reached" is probably better than "exceeds" |
| 10:46 |
Dyrcona |
Make a game of it: Achievement Unlocked: Checkout Limit! |
| 10:47 |
* bshum |
suggests roses tests and submit a patch to change the language if it does end up making the world a better place :) |
| 10:48 |
* Dyrcona |
better not let the reference crew see these logs. He'll be asked to add patron achievements as an enhancement. |
| 10:49 |
|
ericar joined #evergreen |
| 10:49 |
jeff |
called up our primary isp... "hi. just sitting here reading the article in the newspaper about the outage we're still experiencing, and wondered if you had any more information for us." |
| 11:54 |
RoganH |
hmmm... I just did a trivial skim, so it's not restricted to URI's but any bibs without copies? |
| 11:56 |
bshum |
RoganH: Yeah, that's how it works. We used to call that the "gray bibs problem" back in JSPAC, when empty bibs were styled with gray background. |
| 11:56 |
bshum |
*we being Bibliomation |
| 11:56 |
kmlussier |
It looks like ldwhalen has a branch that's ready to be tested. But it doesn't have a pullrequest tag. |
| 11:57 |
RoganH |
bshum: yeah, I know the gray bib problem, it just didn't occur to me that this was the same thing |
| 11:57 |
bshum |
They're white now :) |
| 11:57 |
csharp |
heh |
| 17:20 |
jeff |
(42 hours later) |
| 17:23 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Bmagic: an example might be helpful" (81 lines) at http://paste.evergreen-ils.org/43 |
| 17:24 |
Bmagic |
Dyrcona: that helps a lot!!! |
| 17:26 |
Dyrcona |
IIRC: It retrieves and pays all outstanding bills. I wrote it when we were getting complaints about payments via SIP to help test if the problem was the backend or what. |
| 17:27 |
Bmagic |
Dyrcona: that is the example that I needed. Thanks so much. I hope that forgive is similar |
| 17:27 |
Dyrcona |
Yeah, just set the payment_type to forgive. |
| 17:28 |
Dyrcona |
forgive_payment, actually. |
| 09:25 |
Dyrcona |
Looks like bug 1243280 slipped through the cracks because it was not targeted at 2.5. |
| 09:25 |
pinesol_green |
Launchpad bug 1243280 in Evergreen 2.5 "'TypeError: obj.active_services is undefined' error when entering z39.50 MARC import UI" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1243280 |
| 09:26 |
bshum |
Oops. |
| 09:32 |
Dyrcona |
kmlussier: If you find my development server to be slow, that is because I am running the inter authority link script on it, in parallel. I wanted to test if it could be run in parallel. |
| 09:33 |
kmlussier |
Dyrcona: Ok, thanks! Do you have the two depesz branches on there now? |
| 09:33 |
Dyrcona |
kmlussier: And, it may have other issues at the moment. I'm not sure if it is because of load or for some other reason, but I get a 500 error when testing the hostname. |
| 09:33 |
eeevil |
Dyrcona: it can be. there's no particular interlocking danger |
| 09:34 |
Dyrcona |
kmlussier: I have loaded both of them, yes. |
| 09:34 |
kmlussier |
Dyrcona: Thanks again. |
| 09:42 |
Dyrcona |
Or the disk. |
| 09:42 |
* Dyrcona |
waits. |
| 09:47 |
Dyrcona |
And autogen.sh fails with a similar message on a different line in a different file. |
| 09:47 |
* Dyrcona |
suspects what he is trying to test. |
| 09:52 |
Dyrcona |
And, bingo! Delete the database entry I added and everything works again. |
| 09:52 |
* Dyrcona |
does more research. |
| 09:55 |
|
yboston joined #evergreen |
| 14:55 |
pinesol_green |
[evergreen|Angela Kilsdonk] Documentation for Sorting Billing Columns - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=46768f1> |
| 15:03 |
|
kbeswick joined #evergreen |
| 15:05 |
|
mllewellyn joined #evergreen |
| 15:17 |
csharp |
okay here's something to test... do a catalog search for something in the staff client and click "Place Hold". The Submit button is greyed out (since it now cares whether a barcode is entered). Click Place this hold for me and the button remains greyed out, but if you switch the radio button back to Place hold for patron by barcode, then back to Place this hold for me, the Submit button is activated |
| 15:17 |
csharp |
this is on 2.5-rc1 actually (need to upgrade to 2.5.1 when we get a chance) |
| 15:17 |
bshum |
csharp: Yeah that bug is fixed in 2.5.1 |
| 15:17 |
csharp |
oh? |
| 15:18 |
bshum |
Or at least I think it is |
| 12:00 |
pinesol_green |
2.0.x: You are nothing but a gleeking tongueful of tottering urine. |
| 12:00 |
jcamins |
^^ 2.0.x has been deprecated |
| 12:01 |
Dyrcona |
2.0.x needs to be buried, not insulted. ;) |
| 12:02 |
jeff |
@decide real data or made up test cases |
| 12:02 |
pinesol_green |
jeff: Beyond here be dragons. |
| 12:03 |
jeff |
bah. |
| 12:05 |
Dyrcona |
@eightball real data or made up test cases? |
| 12:05 |
pinesol_green |
Dyrcona: _I_ don't know. |
| 12:06 |
berick |
@eightball does @eightball ever give an answer? |
| 12:06 |
pinesol_green |
berick: The outlook is good. |
| 12:51 |
bshum |
jeff: Could always submit a proposal for the next site selection committee :) |
| 13:14 |
bshum |
Dyrcona++ # for Marque.pm |
| 13:14 |
Dyrcona |
Shh! It isn't ready for prime time, yet. |
| 13:14 |
* csharp |
was about to ask |
| 13:15 |
csharp |
Dyrcona: I may have said before, but I'll be happy to test that when you're ready |
| 13:40 |
|
kmlussier joined #evergreen |
| 13:48 |
|
akilsdonk joined #evergreen |
| 13:53 |
kmlussier |
I briefly looked at bug 1234845 on Dyrcona's server a while back, but now I'm giving it closer scrutiny on another server. Could somebody give me some information on where the ranked_volumes function comes into play? Is it related to the way copies are retrieved on the search results page? |
| 14:15 |
pinesol_green |
Launchpad bug 1236979 in Evergreen "Speed up bibs-by-item-age" (affected: 1, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1236979 |
| 14:15 |
Dyrcona |
jeff: *Which* pickaxe? |
| 14:16 |
jeff |
Dyrcona: -S |
| 14:16 |
* kmlussier |
assumes so since the difference in performance between the production and test server is very noticeable indeed. |
| 14:16 |
Dyrcona |
The BitCoin miner, the MMORPG.... |
| 14:17 |
eeevil |
kmlussier: yes (that's the item-age freshmeat feed). the ranked_volumes change is only part of the fix, of course, the other is an entirely new stored proc that replaces a big query |
| 14:17 |
jeff |
this pickaxe: git log -SCHECKIN_BYPASS_HOLD_FULFILL --pretty=oneline --abbrev-commit |
| 15:09 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1207903 |
| 15:14 |
mmorgan |
dbwells++ |
| 15:15 |
mmorgan |
Back to the "cost" field for a moment. Is that not visible anywhere in the client? Just for reporting? |
| 15:19 |
jeff |
it is not visible in the client when viewing a copy. it may be visible somewhere in Acq. it can be reported on. |
| 15:19 |
jeff |
at our library, we intend to move item cost from a copy note to asset.copy.cost and use it for reporting collection value / depreciation |
| 15:31 |
jeff |
dbwells++ remingtron++ for bug 1207903. Looks good at a quick glance. Any reason I shouldn't give it a test and commit to master sometime this weekend? |
| 15:31 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 2, heat: 10) [Wishlist,Triaged] https://launchpad.net/bugs/1207903 |
| 16:18 |
|
dMiller__ joined #evergreen |
| 16:44 |
smyers_ |
I have a z39.50 problem and was wondering if someone would be willing to help find the issue |
| 17:00 |
smyers_ |
the odd thing is as soon as I point this at the production environment I get results |
| 17:00 |
Dyrcona |
Well, something is different. You also get different results from the two environments in the browser. |
| 17:01 |
smyers_ |
that would be expected to some degree as the databases are different |
| 17:01 |
Dyrcona |
Is the test environment a copy of production? If not, you should go over what makes it different. |
| 17:01 |
smyers_ |
the underlying data is older but that should be it |
| 17:02 |
|
mrpeters left #evergreen |
| 17:02 |
Dyrcona |
I've had lots of fun migrating Vietnamese records this year and pestered gmcharlt with sample files, that every time I see Vietnamese like that, I tend to blame charset issues. |
| 07:39 |
|
rjackson-isl joined #evergreen |
| 08:07 |
|
Dyrcona joined #evergreen |
| 08:10 |
|
jboyer-isl joined #evergreen |
| 08:24 |
csharp |
dbwells: I'm interested in 2.5.1... are you awaiting testing feedback that it works? I'm willing to do a test install if that helps |
| 08:25 |
csharp |
specifically, I'd like to branch off of rel_2_5_1 via git when that gets created |
| 08:26 |
|
akilsdonk joined #evergreen |
| 08:27 |
Dyrcona |
csharp: You could just branch off of rel_2_5 now and then change the upstream when 2_5_1 is created. Anything destined for 2_5_1 should go into 2_5. |
| 08:28 |
Dyrcona |
Which reminds me that we're doing a test upgrade on my development server today before this weekend's update. |
| 08:29 |
Dyrcona |
As a general recommendation, if you have local changes and you want to track the release branches, I'd suggest basing your local branch off of rel_X_Y and not rel_X_Y_Z anyway. |
| 08:30 |
csharp |
actually, that's a great idea |
| 08:30 |
csharp |
it won't matter as much once we lock in on our go-live version, but during this test phase that's better |
| 08:31 |
Dyrcona |
If you follow rel_X_Y you should pickup anything destined for rel_X_Y_Z, and you'll always be up to date as of your build. |
| 08:33 |
Dyrcona |
git++ |
| 08:34 |
* Dyrcona |
checks if yesterday's database reload was successful. |
| 14:05 |
rsoulliere |
I can go first. |
| 14:05 |
rsoulliere |
#topic Conversion Coordinator Report |
| 14:05 |
yboston |
go ahead rsoulliere |
| 14:06 |
rsoulliere |
#info EG 2.5 documentation is now being processed on the documentation web server. |
| 14:06 |
rsoulliere |
#info I shared some information and tools with yboston regarding processing documentation from the repositories. Here are some of the tools in a repository I set up a long time ago: |
| 14:06 |
rsoulliere |
#link https://github.com/rsoulliere/Evergreen_Documentation_Tools |
| 14:06 |
rsoulliere |
#info If anyone else is interested in setting up their own documentation site for testing or experimenting and needs some technical assistance to get started, let me know. |
| 14:06 |
rsoulliere |
That is all. |
| 14:07 |
yboston |
rsoulliere++ |
| 14:07 |
kmlussier |
I can go next. |
| 14:07 |
yboston |
rsoulliere: I have a comment for you |
| 14:09 |
yboston |
I don't want to cause the nightly builds to be broken for several days |
| 14:10 |
rsoulliere |
Typos etc... shouldn't bring the whole documentation site to a crash. |
| 14:10 |
yboston |
rsoulliere: I guess we can start with a few as see how it goes. So far I just waited until the next day to see if the one page was built successfully. |
| 14:11 |
rsoulliere |
I would test locally using the basic ascidoc command and upload if it passes the test. |
| 14:11 |
rsoulliere |
I probably would load a bit at a time as you suggest. |
| 14:11 |
yboston |
any particular combination of parameters? |
| 14:11 |
rsoulliere |
If you notice anything not appearing, let me know via email and I can troubleshoot on the server. |
| 14:12 |
yboston |
also, I had issues with the bash source highlighting on OS X, was not sure how to fix |
| 14:13 |
|
dMiller___ joined #evergreen |
| 14:13 |
rsoulliere |
yboston re: parameters: I think the basic html conversion should be a good test. That should catch most syntax issues. |
| 14:13 |
yboston |
rsoulliere: OK |
| 14:13 |
|
jboyer_isl joined #evergreen |
| 14:13 |
rsoulliere |
re OSX highlighting: do you mean display issues in safari? |
| 14:26 |
yboston |
Any comments or questions? |
| 14:27 |
yboston |
My elevator speech about the hack-a-way, it was great for getting new folks trained on DIG workflows and asciidoc. It was hard to find small taks for volunteers to work on |
| 14:28 |
kbutler |
yboston: Thank you for hosting. I thought it was productive. |
| 14:28 |
yboston |
we still have files that were worked on that need to be pushed to the repository |
| 14:28 |
yboston |
kbutler: thanks |
| 14:29 |
yboston |
I hope by January all of the work that was started (and finished) at the hack-a-way has been integrated to the docs. |
| 14:30 |
yboston |
I also hope that it iwllbe easier to find tasks to give to newcomers not that we have a video tutorial to get more people u to speed |
| 14:30 |
yboston |
(now that we have) |
| 14:32 |
yboston |
Also, at the next conference, we should have a whole day to work on docs. Hope that we can apply other lesson of this hack-a-way to that hackfest |
| 14:32 |
yboston |
BTW< thanks to ESI, that was the test server we ended up using the most |
| 14:33 |
yboston |
Any comments or questions? |
| 14:35 |
kmlussier |
Sounds like you all got a lot accomplished. Nice work! |
| 14:35 |
kmlussier |
yboston++ for pulling it together. |
| 14:36 |
yboston |
Next year I plan to again offer to host, but perhaps we can all decide meet somewhere else in Massachusetts |
| 15:44 |
|
dMiller___ joined #evergreen |
| 15:53 |
|
stevenyvr2 joined #evergreen |
| 16:07 |
Dyrcona |
At some point, you just have to stop typing/editing and hit the "Publish" button. :) |
| 16:13 |
remingtron |
yboston: when publishing docs, we could use the master branch as our test version. If it breaks, it's okay because it's only the dev version! Once it's fixed, pull it into 2.5 and 2.4. |
| 16:13 |
|
timlaptop joined #evergreen |
| 16:14 |
remingtron |
yboston: I'll send this idea to the DIG list for discussion |
| 16:14 |
Dyrcona |
If anyone is interested in what I was doing to use the asciidoc blogpost program to post to blogger: http://blog.sigio.com/2012/05/look-ma-no-hands_15.html |
| 16:14 |
yboston |
remingtron: that is a great idea |
| 16:14 |
Dyrcona |
If anyone cares about my other, more personal, blog: http://kissmysock.wordpress.com/ |
| 17:24 |
Dyrcona |
more like the first one, yes. |
| 17:25 |
ElliotFriend |
with all that said, what would be the best way to move towards a workflow like that, as opposed to the way I'm doing it? |
| 17:26 |
ElliotFriend |
Set it up like that on a new set of servers? |
| 17:26 |
Dyrcona |
Do you have a server that you use for testing or development? |
| 17:27 |
Dyrcona |
I'd try it out on a test server to start with. |
| 17:27 |
ElliotFriend |
Both are VMs. I have a test server that is a clone of the production one |
| 17:27 |
Dyrcona |
I'd set it up on the test vm first. |
| 17:27 |
ElliotFriend |
I only ever spin up the test one to run through an upgrade, before applying it to production |
| 17:27 |
ElliotFriend |
sounds good |
| 17:28 |
Dyrcona |
It is about time for me to head home. I can sign back in when I get there if you want to discuss the work flow some more. |
| 17:29 |
ElliotFriend |
I think I'm alright. Thanks again! I repeat, Evergreen people sure are swell! |
| 00:28 |
smyers_ |
boolean returns |
| 00:29 |
smyers_ |
OpenSRF/Utilies/JSON.pm |
| 00:31 |
smyers_ |
jeff: I need to go to bed, if you have more questions for me or if I can help anyway let me know |
| 00:32 |
jeff |
huh. i wonder what "boolean returns" means. guess i'll find out when i upgrade JSON::XS to 3.01 on my second test instance. |
| 02:01 |
|
senator joined #evergreen |
| 03:16 |
|
mjingle left #evergreen |
| 06:38 |
|
b_bonner joined #evergreen |
| 06:39 |
|
mtcarlson_away joined #evergreen |
| 06:53 |
jeff |
bug to follow, but user/jeff/fix_json_xs_booleans_option1 and user/jeff/fix_json_xs_booleans_option2 OpenSRF working branches have a fix for latest JSON::XS issues |
| 07:17 |
jeff |
bug 1257264 |
| 07:17 |
pinesol_green |
Launchpad bug 1257264 in OpenSRF "JSON::XS 3.0 changes the way booleans are represented" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1257264 |
| 07:31 |
eeevil |
jeff: I'm going to look at a third option in a bot using opensrf type registration |
| 07:41 |
|
rjackson-isl joined #evergreen |
| 09:46 |
dbs |
Projected medium + short running time + audience = preschool + type = motion picture + technique = animation = Cartoon! |
| 09:46 |
paxed |
isn't there an eg project that's going to do something like this? |
| 09:47 |
paxed |
add original country = japan => anime :P |
| 09:47 |
eeevil |
paxed: there's a proposed project, yes |
| 09:50 |
eeevil |
jeff: so, going back as far as JSON 2.23 (earliest CPAN-able JSON module, Sept 2010) there's a is_bool class function. it's also in both of the available JSON::XS modules. I think we should use that instead of testing the object directly, if it's a scalar ref. should do the right thing in any reasonable version |
| 09:51 |
dbs |
So right now we have one icon that means exactly what the string says: "Projected medium" - which could be a magic lantern show, a set of slides, a filmstrip, a vhs tape, a dvd, a bluray, a laserdisc... we don't even use the 007 currently in figuring out what icon to display, IIRC |
| 09:52 |
jeff |
urgh. i know i was up too late when AWS doesn't even want me to re-authenticate in the morning. |
| 09:52 |
dbs |
I guess if the bulk of your collection is DVD movies, then change the string to "Movies, etc" or something like that? |
| 09:53 |
bshum |
Our string is currently a generic "Video recording" which is slightly better sounding I guess. |
| 09:54 |
jeff |
is it unusual to hear this text in the voice of Dr. Strangelove? "Improve your instance's security. Your security group, eg-pub-test, is open to the world." |
| 09:54 |
dbs |
bshum: yeah, that sounds better to me :) |
| 09:54 |
jeff |
"Why didn't you tell the WORLD?!" |
| 09:57 |
dbs |
ah, the proposal eeevil mentions is http://list.georgialibraries.org/pipermail/open-ils-general/2013-September/008961.html - right |
| 12:46 |
tsbere |
ldwhalen: There is a hard limit of "whatever your network connection and server can handle" - Beyond that, not really. |
| 12:47 |
ldwhalen |
tsbere: thank you. |
| 12:50 |
Dyrcona |
ldwhalen: Is there a particular problem that you are trying to solve or are you asking for informational purposes? |
| 12:55 |
gmcharlt |
jeff: I've cobbled a branch together with eeevil's patch and a test case adjustment for lp1257264 that I think is ready for review, if you care to test |
| 12:55 |
ldwhalen |
Dyrcona: another programmer asked me, and I did not know the answer. |
| 12:56 |
Dyrcona |
ldwhalen: There are a lot of configurations for number of drones to run and how many requests a drone can process before it is recycled. While these don't lead to connection limits directly, if you set these too low, it will seem like you have a connection limit. |
| 13:00 |
eeevil |
gmcharlt++ |
| 13:07 |
Dyrcona |
tsbere once considered running more than one ejabberd instance here, but ran out of tuits. |
| 13:08 |
Dyrcona |
I think the last tuit is stuck to my desk via magnet. |
| 13:08 |
bshum |
We used to run separate ejabberd on the heads of every brick for head/drones. |
| 13:08 |
tsbere |
I didn't run out of tuits. My plans for test hardware fell through. ;) |
| 13:09 |
Dyrcona |
heh |
| 13:23 |
jeff |
gmcharlt: heh. your new branch and mine in-progress look very similar. this is probably good. :-) |
| 13:24 |
jeff |
who needs test hardware when you have spot instances? ;-) |
| 13:24 |
gmcharlt |
jeff: yeah, I think main difference is that my branch avoids any direct testing of JSON::{XS,PP}::Boolean |
| 13:25 |
jeff |
yeah, mine also. i'll append my additional tests and sign off on what's there and if the tests don't seem ridiculous, great! |
| 13:26 |
jeff |
also, if anyone hadn't seen it yet, google compute engine has gone General Availability, and supports neat things like freebsd: http://googlecloudplatform.blogspot.com/2013/12/google-compute-engine-is-now-generally-available.html |
| 13:28 |
jeff |
gmcharlt: is it good/bad form to have use strict / use warnings in tests? |
| 13:28 |
Dyrcona |
use Modern::Perl; |
| 13:29 |
gmcharlt |
jeff: use strict & use warnings is always good form -- positively elegant, in fact |
| 13:29 |
* Dyrcona |
should make hacker t-shirts and stickers. |
| 13:29 |
tsbere |
jeff: I wanted to actually have real networking equipment in the mix >_> |
| 13:30 |
Dyrcona |
tsbere: All those switches that we gave to the community college? |
| 13:30 |
tsbere |
Dyrcona: Meh, one cheap-ass netgear switch. Just needed several machines plugged into it. |
| 13:31 |
tsbere |
The "borrow several nearly identical machines to test with" aspect is what fell through on me |
| 13:32 |
Dyrcona |
Yeah, not much homogeneity in our closet of broken toys. |
| 13:57 |
|
kmlussier joined #evergreen |
| 14:14 |
|
jboyer-isl joined #evergreen |
| 14:37 |
|
sseng joined #evergreen |
| 14:41 |
jeff |
gmcharlt++ eeevil++ i think bug 1257264 is almost ready to die. |
| 14:41 |
pinesol_green |
Launchpad bug 1257264 in OpenSRF "JSON::XS 3.0 changes the way booleans are represented" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1257264 |
| 14:45 |
jeff |
and if my tests don't make sense, feel free to leave that commit behind. :-) |
| 14:48 |
|
kmlussier joined #evergreen |
| 14:51 |
gmcharlt |
jeff: looks fine to me; I will push |
| 14:51 |
jeff |
gmcharlt++ thanks! |
| 14:54 |
pinesol_green |
[opensrf|Galen Charlton] LP#1257264: make test cases for JSON::XS Boolean-ness more generic - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=ff472c0> |
| 14:54 |
pinesol_green |
[opensrf|Mike Rylander] LP#1257264: Use the built-in JSON-y test for bools - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a5be2f1> |
| 14:54 |
pinesol_green |
[opensrf|Jeff Godin] Add some additional boolean-related JSON tests - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b93e0ca> |
| 14:55 |
|
rfrasur joined #evergreen |
| 14:57 |
|
gsams joined #evergreen |
| 14:58 |
rfrasur |
berick: I have a question about a web-based staff client. Does that mean it would open in a browser? in other words, does that mean I could have the staff client in this or that tab and have email or whatever in another tab but only have one browser window open? |
| 11:49 |
bshum |
Oh, autocomplete... not autosuggest |
| 11:49 |
bshum |
Or is that what you meant? |
| 11:50 |
csharp |
ah sorry - I did mean autosuggest |
| 11:50 |
bshum |
My kneejerk reaction is to blame it on ancient dojo |
| 11:51 |
bshum |
But there could be more to it |
| 11:52 |
bshum |
Hmm, clean master tests fine with Firefox 25.0.1 for me. But I can see what you mean about that particular catalog having issues. |
| 11:52 |
csharp |
https://catalogue.libraries.coop/eg/opac/home?physical_loc=1&locg= too |
| 11:53 |
csharp |
looks like it's off in Indiana |
| 11:53 |
bshum |
So it sounds like autosuggest is having some struggles with the latest Firefox |
| 11:56 |
csharp |
dayum |
| 11:56 |
csharp |
rfrasur++ |
| 12:02 |
jeff |
bshum: can you explain what you mean by "wish we could more accurately predict the outcome of reingest work"? |
| 12:03 |
bshum |
jeff: In our case, I'm thinking I need to apply some more testing methods to look for potential issues. |
| 12:03 |
bshum |
Or rather, learn how to do better testing |
| 12:04 |
bshum |
We have the servers presently to test full scale reingests of all our bibs, but this last round we made a huge glaring mistake by not noticing that an entire field was lost in the reingest process. |
| 12:04 |
bshum |
I'm referring to the alternate titles bug |
| 12:04 |
bshum |
But it didn't get noticed in our manual testing, and nobody saw it till a few days or weeks post upgrade / reingest |
| 12:05 |
bshum |
I guess it's hard to predict everything though |
| 12:05 |
bshum |
Given that we all have little tweaks to our metabib tables |
| 12:10 |
|
hopkinsju joined #evergreen |
| 12:15 |
|
kitteh_ joined #evergreen |
| 12:26 |
eeevil |
bshum: tangentially related: I'd like to see/do more work on ingest logic splitting. made some good progress in 2.5, but there's more to do, like splitting off record attrs as search/facet/browse are now |
| 14:35 |
bshum |
My head hurts |
| 14:37 |
bshum |
ldwhalen: If/when you get some free time, I'm curious to know how your changes turned out for https://bugs.launchpad.net/evergreen/+bug/925776 |
| 14:37 |
pinesol_green |
Launchpad bug 925776 in Evergreen 2.4 "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 4, heat: 22) [Medium,Confirmed] |
| 14:37 |
bshum |
I'd like to get all of them together into a working branch so that we can test it out as well down the road. |
| 14:38 |
mmorgan |
bshum: So "people" meaning staff still want to see the Lost items on patron accounts after they're paid? |
| 14:38 |
bshum |
mmorgan: Right, staff :P |
| 14:39 |
bshum |
I think that's just so that until the lost item is actually dealt with, they want to know who had it last and quickly see that when they pull up the record. |
| 15:01 |
dbs |
Or perhaps with default settings |
| 15:01 |
bshum |
Hmm, perhaps |
| 15:02 |
dbs |
It doesn't make sense to me that firefox would care about how long it takes for a request to return, vs. chrome |
| 15:02 |
jeffdavis |
mjingle just tested IE and it works, fwiw |
| 15:03 |
dbs |
watching the network requests in firefox suggest that it never actually sends a request |
| 15:09 |
bshum |
Autosuggest doesn't seem very happy with IE11 fwiw |
| 15:09 |
bshum |
Not sure which IE mjingle was poking with |
| 15:46 |
pinesol_green |
jboyer-isl: The operation succeeded. |
| 15:47 |
jeff |
jboyer-isl: thanks for checking. :-) |
| 15:47 |
jboyer-isl |
No problem. |
| 15:48 |
jeff |
jboyer-isl: i'm in the process of testing things here. i'm able to let a patron who could not otherwise circ but can perform renewals to get in and do a renewal, and they're still rejected at checkout time, but the message is a tad too generic, so i'm going to improve that. |
| 15:55 |
|
stevenyvr joined #evergreen |
| 16:20 |
|
gmcharlt joined #evergreen |
| 16:31 |
|
mmorgan1 joined #evergreen |
| 11:11 |
mmorgan |
Does shelf browse search/sort by asset.call_number.label, or asset.call_number.label_sortkey? |
| 11:12 |
senator |
csharp: to see what bib call number searches exactly on your system, (it's not the 092 by default) see: select format, xpath from config.metabib_field where field_class = 'identifier' and name = 'bibcn'; |
| 11:12 |
csharp |
aha |
| 11:12 |
eeevil |
dbwells: thougts on my final comment on our funtime QP bug? (also, did you see Liam's note about sitka testing?) |
| 11:13 |
dbwells |
krvmga: mmorgan: the shelf browse can be tricky. It uses the non-normalized value to find the "pivot" (that is, the closest match to what the user typed in), then uses the sortkey to sort the surrounding results. |
| 11:14 |
csharp |
ours is set to 099 - however, we disable bib cn searching because all of our call numbers are free text and locally set, so we could have many variants on a single bib record |
| 11:14 |
csharp |
and none of those variants gets entered into the 099 |
| 12:29 |
jeff |
That opac spelling suggestion on search is the only thing I'm aware of. |
| 12:30 |
* berick |
uploads updated 2.3.12 tarball to previews |
| 12:30 |
JennB |
ok! thats for reconfirming what I knew/was aware of |
| 12:30 |
jeff |
Now, there is support for verifying authority controlled fields in the MARC editor -- which isn't strictly "spell check", but can bring to light typos and such. |
| 12:30 |
jeff |
berick++ |
| 12:30 |
jeff |
and dbs++ for testing hardcoded paths |
| 12:31 |
JennB |
OK, thanks! |
| 12:32 |
dbs |
from what I can see, the install instructions will get simpler if we can avoid the /openils prefix |
| 12:33 |
jeff |
ouch: SIPServer.pm: OILS: SIP Checkin request took 6.386 seconds |
| 14:50 |
|
stevenyvr joined #evergreen |
| 15:21 |
jeff |
interesting. circ block doesn't appear to block on a pre-cat. |
| 15:28 |
* eeevil |
taps fingers waiting for i18n build to complete for 2.4.4 wrapping |
| 15:30 |
jeff |
eeevil: in testing, a self checkout terminal from vendor 3 doesn't seem to care about the "renewal privileges denied" flag. if charge privs are denied, the patron can't use the terminal. |
| 15:32 |
eeevil |
jeff: so even if we did the "right" thing with the renew flag and block check, their thing would not act correctly... :( |
| 15:32 |
jeff |
eeevil: still worth adjusting our response there to be correct (now that we can), but i suspect i'm also going to add a config option to the sip server to skip over certain standing penalties. |
| 15:33 |
|
dMiller_ joined #evergreen |
| 15:35 |
jeff |
eeevil: right. i forced OpenILS::SIP::Patron to always return ok for renewal privs, and the terminal still rejected the patron before giving them a chance to renew things. |
| 15:36 |
|
janes joined #evergreen |
| 15:37 |
jeff |
eeevil: i don't think it would be good to "always ignore this circ-blocking penalty" in a hardcoded sense, since i can only test things on certain clients, but i suspect it'll be a "ignore this block for this penalty type" config option with a suggested default. |
| 15:40 |
jeff |
"ignore these penalties completely" might be simpler, at the expense of some expression/flexibility |
| 15:41 |
eeevil |
jeff: wonder if it's time to provide a config for each flag allowing "force-Y/force-N/what-ILS-says" |
| 15:41 |
eeevil |
in the sip config file |
| 15:41 |
eeevil |
that would allow per-client-device tuning |
| 15:42 |
jeff |
yes. i'd still like to do per-client config for some things, not all related to this. |
| 15:43 |
jeff |
though maybe per-sip-user isn't needed if we can do it now with multiple institutions without too much overhead. not sure i'd thought of that yet. |
| 15:44 |
eeevil |
<sip-flags><circ>auto</circ><renew>Y</renew></sip-flags> ... default for unconfigured flags being "auto" |
| 15:45 |
jeff |
off to test how well the client reacts to "sure this patron can check stuff out" followed by not allowing anything to be checked out. |
| 15:45 |
* jeff |
grabs some rfid tags |
| 15:46 |
sandbergja |
Acquisitions question for everyone: on eg 2.4.0, is there a trick to placing holds via Acquisitions > Patron Requests? I have double checked that "Place Hold" was checked, and I have gone through the whole Add to selection list, Activate PO, Receive PO process. |
| 16:03 |
|
dMiller joined #evergreen |
| 16:11 |
|
dMiller_ joined #evergreen |
| 17:18 |
jeff |
i remember. :-) |
| 17:18 |
Bmagic|2 |
jeff: so, from your understanding, would an appropriate row in actor.usr_standing_penalty be required to prevent the checkout? |
| 17:19 |
jeff |
this seems to be a bit of an inelegant workaround, though perhaps useful as a learning experiment. :-) |
| 17:20 |
Bmagic|2 |
jeff: I only ask, because the (Has overdues) comes up for this test patron even without the row in the table |
| 17:20 |
jeff |
Bmagic|2: yes, a row in actor.usr_standing_penalty corresponding to the user in question with the standing penalty type in question is what i'd expect to see for a user with that penalty |
| 17:20 |
jeff |
has overdues is something else. |
| 17:21 |
Bmagic|2 |
jeff: I think I need (max overdues) |
| 11:01 |
bshum |
csharp: Yeah it is |
| 11:01 |
bshum |
Now I'm suspecting screen resolution |
| 11:01 |
bshum |
The person complaining is running 800x600. Maybe the buttons are sliding off the screen ara |
| 11:01 |
csharp |
lemme rebuild my test vm and try to replicate |
| 11:01 |
bshum |
*area |
| 11:01 |
csharp |
oh |
| 11:02 |
dbs |
ooh, 800x600. fun. |
| 11:22 |
bshum |
But as the other user, they couldn't see it. |
| 11:22 |
bshum |
Weird...... |
| 11:22 |
csharp |
that would be a different openils profile, right? |
| 11:22 |
bshum |
Or... wait |
| 11:23 |
bshum |
That the user is a member of admin and debugger? |
| 11:23 |
bshum |
Must be groups or something |
| 11:24 |
* bshum |
throws his hands up in the air in disgust |
| 11:24 |
bshum |
windows-- |
| 12:00 |
|
dMiller joined #evergreen |
| 12:06 |
bshum |
Hmm |
| 12:07 |
bshum |
csharp: When placing a hold in the staff client, I'm seeing that if the staff member doesn't have an email address, it populates the email field with something like "no email address configured, check account" |
| 12:07 |
bshum |
And then it doesn't update the field with the actual user's email when you key in different barcodes. |
| 12:07 |
bshum |
If the staff member does have an email, it starts with their email, and then keying in different patrons updates the field accordingly |
| 12:08 |
bshum |
My thinking is a bug since 2.4's rewrite of the code in that area |
| 12:08 |
bshum |
And maybe it's just not initializing the email variable (or refreshing it if it starts as NULL) |
| 12:09 |
bshum |
csharp: If you get a chance to test that on a 2.4/2.5/master system, let me know :D |
| 12:09 |
bshum |
I'm going to eyeball some more code |
| 12:09 |
* bshum |
loves how "upgrades" shakes loose all the bugs nobody ever saw before |
| 12:13 |
|
rfrasur joined #evergreen |
| 12:14 |
phasefx |
bshum: I think someone here said that they announce upgrades that don't actually happen for just that reason :) |
| 12:15 |
bshum |
phasefx: I've done that before :) |
sitka.bclibraries.ca>