| Time |
Nick |
Message |
| 00:39 |
|
artunit_ joined #evergreen |
| 02:15 |
|
eby_ joined #evergreen |
| 02:38 |
|
rangi` joined #evergreen |
| 04:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:35 |
|
eeevil joined #evergreen |
| 06:48 |
|
wsmoak joined #evergreen |
| 07:39 |
|
sarabee joined #evergreen |
| 08:09 |
|
collum joined #evergreen |
| 08:18 |
|
ericar joined #evergreen |
| 08:28 |
|
mrpeters joined #evergreen |
| 08:48 |
|
Shae joined #evergreen |
| 08:55 |
csharp |
I'm getting this error now when running a script that generates files for Unique Management Services: http://pastie.org/9711725 - anyone know why that is? Is opensrf timing out or something? |
| 08:55 |
csharp |
yes |
| 08:56 |
csharp |
oops - "yes" was meant for another window ;-) |
| 09:02 |
|
ericar_ joined #evergreen |
| 09:13 |
remingtron |
super old bug 921142 (heat 44!) ready for testing/pushing |
| 09:13 |
pinesol_green |
Launchpad bug 921142 in Evergreen 2.4 "Fixed fields are required to have all positions entered. " (affected: 6, heat: 44) [Medium,Confirmed] https://launchpad.net/bugs/921142 |
| 09:22 |
|
mrpeters joined #evergreen |
| 09:23 |
jeff |
next time, on "this old bug" |
| 09:25 |
remingtron |
jeff: justice will finally be served |
| 09:42 |
|
BigRig joined #evergreen |
| 09:52 |
|
phasefx joined #evergreen |
| 09:52 |
|
Callender joined #evergreen |
| 09:54 |
|
eeevil joined #evergreen |
| 09:56 |
|
mtate joined #evergreen |
| 10:44 |
|
sarabee joined #evergreen |
| 10:56 |
|
graced joined #evergreen |
| 10:59 |
|
ericar joined #evergreen |
| 11:02 |
|
maryj joined #evergreen |
| 12:41 |
|
nhilton joined #evergreen |
| 12:43 |
|
mrpeters joined #evergreen |
| 13:13 |
csharp |
did anyone ever mirror the old SVN repo site? I'm wondering if some old PINES development is still recoverable |
| 13:15 |
csharp |
specifically, I'm looking for the bad debt interface that was briefly alive on our test server c. 2009 |
| 13:28 |
bshum |
csharp: Yeah I think MVLC has a mirror of the SVN |
| 13:28 |
bshum |
Or a converted git copy anyways |
| 13:28 |
bshum |
But I'm not sure |
| 13:29 |
bshum |
http://git.mvlcstaff.org/?p=Evergreen/ILS-Contrib.git;a=summary |
| 13:29 |
csharp |
well, right now I'm trying to see if I can just add a /baddebt location to eg_vhost.conf |
| 13:29 |
bshum |
csharp: Maybe in there? |
| 13:30 |
csharp |
bshum++ # that's what I was looking for, but I don't think it's there |
| 13:30 |
bshum |
Doesn't seem to be :( |
| 13:31 |
csharp |
I'm pretty sure I just need to somehow access OpenILS::WWW::BadDebt from eg_vhost.conf |
| 13:32 |
csharp |
I'm getting a 403 though when I try to access it |
| 13:34 |
* bshum |
had never even heard of "BadDebt" before |
| 13:34 |
csharp |
yeah - long story |
| 13:34 |
csharp |
it's a PINES request from many a long year ago |
| 13:35 |
csharp |
the director who requested it is long gone, but there are several libraries that still want something to mark their unrecovered debt via Evergreen |
| 13:35 |
csharp |
and if I can do some necromancy, I'd like to let the libraries who want to use that rather than have me do it |
| 13:38 |
eeevil |
csharp: you just need the web proxy in front of that location. a la notices or reports. it checks the ses cookie |
| 13:38 |
bshum |
Sounds... like an adventure. |
| 13:38 |
csharp |
eeevil: ok cool - thanks for the hint |
| 13:39 |
eeevil |
csharp: you're getting a 403 because there's no cookie (or param) for it to look at |
| 13:39 |
csharp |
ah - gotcha |
| 13:40 |
eeevil |
and the user that goes there needs the "MARK_BAD_DEBT" permission |
| 13:43 |
csharp |
thanks |
| 13:44 |
csharp |
hmm - login worked, but I'm not getting a 404 :-/ |
| 13:44 |
csharp |
eeevil: would you mind glancing at this?: http://pastie.org/9712384 |
| 13:45 |
csharp |
I'm sure I just have a simple config option wrong |
| 13:45 |
csharp |
and I'm doing copy paste coding right now without really knowing the knobs and switches for apache/mod_perl |
| 13:52 |
eeevil |
csharp: that looks fine |
| 13:52 |
csharp |
ok thanks |
| 13:56 |
|
Stompro_home joined #evergreen |
| 14:13 |
csharp |
ah - that's interesting - no interface loads, but if I add anything to the url (e.g. https://test-brick01-head/baddebt/test), I get a downloaded CSV file that says Upload Failure |
| 14:14 |
csharp |
I don't understand enough about perl/CGI to know how to get the show_template subroutine to work |
| 14:21 |
csharp |
okay, so I can see that it at least is running the handler subroutine, but I don't see where show_template is invoked in that |
| 14:23 |
eeevil |
csharp: it seems it's not. http://pastie.org/9712488 should do it. I'll look at the git history right quick |
| 14:25 |
csharp |
eeevil++ # that did it |
| 14:25 |
eeevil |
cool. if you bug it I'll toss up a branch, eh? |
| 14:27 |
csharp |
sure thing |
| 14:28 |
csharp |
well, after I figure out why my test.csv file resulted in "Upload Failure" ;-) |
| 14:28 |
csharp |
ah - yeah, we're suffering bitrot here: Method [open-ils.cstore.direct.money.billable_xact.retrieve] not found for service open-ils.cstore |
| 14:29 |
csharp |
I'll look into it, now that I've got the scent ;-) |
| 14:31 |
jeff |
downtrodden and bitrotten |
| 14:32 |
eeevil |
ah, well, that'd be ungood to continue using in any case. it needs to be moved to pcrud re "no more private services in mod_perl" (but that's a broader project which will likely include IDL changes) |
| 14:32 |
csharp |
oh - ok |
| 14:32 |
csharp |
well, I'm happy to help do it the Right Way™ too |
| 14:33 |
eeevil |
:) |
| 14:48 |
* bshum |
wishes he had kept quiet now instead of opening his big mouth |
| 14:48 |
* csharp |
would be curious if Jennifer Walz's admin user actually has the superuser flag |
| 14:49 |
|
remingtron joined #evergreen |
| 14:49 |
csharp |
well, the last guy has muddied the water with w3 validation... valid (ha!) point, but not the cause of the current problem |
| 14:50 |
bshum |
Indeed. |
| 14:50 |
* csharp |
assumes that Asbury is self-administered |
| 14:50 |
* graced |
assumes the same |
| 14:52 |
bshum |
Indeed. |
| 14:56 |
bshum |
@praise 2 csharp |
| 14:56 |
* pinesol_green |
csharp is kind and patient to newbies |
| 14:58 |
|
wsmoak joined #evergreen |
| 14:59 |
csharp |
heh |
| 15:00 |
bshum |
Well, the only permission from the listed fieldmapper entries that seems to matter is "VIEW_USER" |
| 15:00 |
bshum |
There's stuff for stat cat and surveys too |
| 15:01 |
bshum |
Anywho |
| 15:01 |
bshum |
dojo-- |
| 15:02 |
bshum |
Just 'cause it's rusty and annoying |
| 15:02 |
csharp |
right - it might be something as simple as VIEW_SURVEY (or whatever) not being assigned to the users that need it |
| 15:02 |
csharp |
and from her tone, they're in panic mode |
| 15:02 |
csharp |
@karma dojo |
| 15:02 |
pinesol_green |
csharp: Karma for "dojo" has been increased 3 times and decreased 8 times for a total karma of -5. |
| 15:02 |
bshum |
Well, who wouldn't be in panic if you couldn't edit any of your users or view them :) |
| 15:03 |
csharp |
right |
| 15:03 |
bshum |
But yeah, it could be a peripheral permission |
| 15:03 |
bshum |
Checking the superuser is a good step though |
| 15:03 |
bshum |
Just to be sure it's not actual page breakage |
| 15:03 |
csharp |
well, the panic is from "holy sh*t! I don't have any idea how to do this and I'm the only one who can help" |
| 15:03 |
bshum |
Maybe they didn't install from a tarball and don't have dojo installed |
| 15:04 |
* csharp |
has been there many times, so knows that there's light at the end of the tunnel |
| 15:04 |
bshum |
Though I think it manifests more unhappily when that occurs |
| 15:04 |
csharp |
that occurred to me to (no dojo), but I don't think you can even register a workstation without it |
| 15:04 |
bshum |
I think you're right |
| 15:04 |
dbs |
Maybe it's not our specially tweaked version of dojo? |
| 15:05 |
bshum |
Hmmm |
| 15:07 |
pinesol_green |
[evergreen|Mike Rylander] LP#1198465 Allow fine generator to respect a stop_fines filter - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e1fdcd3> |
| 15:07 |
pinesol_green |
[evergreen|Bill Erickson] LP#1198465 lost overdues generated in main xact - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2a521c> |
| 15:07 |
* csharp |
tried to run the staff client with xulrunner 32 yesterday - got nowhere, but it sure looked purty |
| 15:08 |
bshum |
csharp: I really liked xulrunner 17 or 18 (one of those) when I toyed with it during the memory leak crisis. It blew up after a bit of use though... |
| 15:08 |
bshum |
Sometimes I still think xulrunner 15 might not have been a bad idea |
| 15:08 |
hopkinsju |
I feel like we've seen the exact thing Jennifer posted to the discussion list, but can't for the life of me remember what it was. |
| 15:08 |
bshum |
Since the hump between Firefox 14 and 15 contained memory adjustments. |
| 15:09 |
csharp |
bshum: we should get really mad and fork Evergreen (ala MATE and KDE Trinity) just to keep using the staff client |
| 15:09 |
* bshum |
does NOT love XUL that much. |
| 15:09 |
csharp |
I keed, I keed |
| 15:10 |
csharp |
Evergreen Classic™ |
| 15:10 |
dbs |
hopkinsju: autogen.sh ? |
| 15:11 |
* dbs |
grasping at straws. |
| 15:12 |
bshum |
Maybe it's the permission levels. Like they have VIEW_USER but it's set for Library and the user belongs to a different org unit? |
| 15:12 |
dbs |
Hmm, possible |
| 15:12 |
hopkinsju |
dbs: haha. Might have been. I'm currently searching our help desk system. |
| 15:12 |
bshum |
And it ought to be VIEW_USER for consortium level? |
| 15:12 |
bshum |
Or system, at least |
| 15:12 |
csharp |
perms are such a mystery unless you can grep source code and properly interpret the output |
| 15:12 |
collum |
hopkinsju: ditto. I want to say it was permissions, but it was a couple of years ago. |
| 15:13 |
* csharp |
's money is still on permissions |
| 15:13 |
* dbs |
thinks csharp is probably a smart gambler |
| 15:14 |
dbs |
boy howdy our error handling could be better in that situation though. Maybe somebody could pay a vendor to fix that. For however long the dojo crud continues to exist. |
| 15:15 |
csharp |
+1 |
| 15:15 |
csharp |
@who will pay a vendor to do that? |
| 15:15 |
pinesol_green |
berick will pay a vendor to do that. |
| 15:15 |
csharp |
heh |
| 15:15 |
hopkinsju |
w00t. I like this new way of seeking funding. |
| 15:15 |
csharp |
@dice 6d |
| 15:15 |
pinesol_green |
csharp: Error: Dice must be of the form <dice>d<sides> |
| 15:15 |
csharp |
@dice d6 |
| 15:15 |
pinesol_green |
csharp: Error: Dice must be of the form <dice>d<sides> |
| 15:16 |
csharp |
@dice 2d6 |
| 15:16 |
pinesol_green |
csharp: 6 and 5 |
| 15:16 |
bshum |
@dice 1d20 |
| 15:16 |
pinesol_green |
bshum: 5 |
| 15:16 |
bshum |
Swing and a miss :( |
| 15:16 |
csharp |
dbs: not a great gambler - can't even throw @dice properly! |
| 15:16 |
hopkinsju |
So fancy, is it better to roll a d100 or 2d10? |
| 15:16 |
csharp |
I think there's a limit |
| 15:16 |
hopkinsju |
@dice 2d10 |
| 15:16 |
pinesol_green |
hopkinsju: 10 and 7 |
| 15:16 |
csharp |
@dice 1d100 |
| 15:16 |
bshum |
@dice 1d2000 |
| 15:16 |
pinesol_green |
csharp: 34 |
| 15:16 |
pinesol_green |
bshum: Error: Dice can't have more than 100 sides. |
| 15:17 |
bshum |
:) |
| 15:17 |
bshum |
There's your limit |
| 15:17 |
csharp |
ah - there's the limit |
| 15:19 |
bshum |
Speaking of memory, did we ever figure out how to limit the spread of plugins so that they weren't shared/enabled/turned-on between Firefox and Evergreen staff client? |
| 15:19 |
* bshum |
can't remember now and it's going to drive me nuts |
| 15:19 |
hopkinsju |
As in launching evergreen loads up the flash plugin? |
| 15:19 |
bshum |
hopkinsju: Correct |
| 15:19 |
bshum |
It did at some point |
| 15:19 |
* hopkinsju |
lols |
| 15:19 |
bshum |
I just don't remember if it still does |
| 15:20 |
bshum |
It's especially bad if you have a lot of plugins |
| 15:20 |
bshum |
For memory reasons |
| 15:20 |
hopkinsju |
Yeah, no kidding |
| 15:20 |
dbs |
Everyone needs a little Zotero in their staff client |
| 15:21 |
bshum |
Yeah I guess it's still doing some of that cross share |
| 15:21 |
csharp |
huh - I wonder if that's a factor in some of our "some libraries are reporting memory issues when others never do" issue |
| 15:21 |
hopkinsju |
Pssh. More like Google Earth |
| 15:21 |
bshum |
If my client is any indication |
| 15:21 |
dbs |
csharp: mebbe! |
| 15:22 |
csharp |
I have a crazy ticket in from one of our libraries where the production client is auto-updating itself to the test client version |
| 15:22 |
bshum |
I think there are some fun color/font addons you can use from Firefox to make your staff client more interesting looking :) |
| 15:23 |
csharp |
they swear that they aren't caching anything, but it's happening now when the test server is completely down |
| 15:23 |
dbs |
"evergreen -ProfileManager" to create a new profile maybe |
| 15:23 |
bshum |
It could be a bad upgrade path |
| 15:23 |
bshum |
Or cross-shared hostname/versions between your test and production environments. |
| 15:23 |
csharp |
I've tried to recreate the issue with no success |
| 15:23 |
bshum |
Like go to the test server to get your updates |
| 15:23 |
hopkinsju |
Do you have the test client build on the production server by mistake? |
| 15:23 |
csharp |
autoupdate host on the production clients is next.gapines.org... oh |
| 15:23 |
bshum |
Or like the test server client was installed with the same path as production |
| 15:24 |
csharp |
s/production clients/test clients/g |
| 15:24 |
csharp |
I wonder if they've been using test clients from last year's upgrade with the next.gapines.org path this whole time |
| 15:25 |
bshum |
Could be |
| 15:25 |
csharp |
huh - that's a distinct possibility |
| 15:25 |
csharp |
I only have random screenshots |
| 15:25 |
* bshum |
loves the time that a library was using the test server hostname as production for a few days before we noticed things seemed... wrong. |
| 15:26 |
csharp |
OMG, that's happened to us too |
| 15:26 |
bshum |
That's why I have completely different stamping now for our test group and production groups. |
| 15:26 |
csharp |
I thought about that, but I didn't want to create a stumbling block for testing |
| 15:26 |
* bshum |
wants more Evergreen staff client logo colors. |
| 15:26 |
bshum |
Red and orange/yellow aren't enough! |
| 15:27 |
bshum |
But yeah |
| 15:27 |
bshum |
I use rigbeta for my test server clients |
| 15:27 |
bshum |
And rigrelease for my regular production ones |
| 15:28 |
bshum |
So any red icon'd staff client for us is a test one |
| 15:28 |
bshum |
And orange/yellow = production |
| 15:28 |
bshum |
But as you say, we don't have nearly as much end-user library testing as we'd perhaps wish for. |
| 15:29 |
csharp |
we use the red icon for testing too |
| 15:30 |
jeff |
one of our "test before upgrade" setups had a garish yellow background in many staff (especially circ-related) interfaces to avoid the "oops, did production work in test env" situation. |
| 15:30 |
jeff |
but it would be nice to have support for that baked in, maybe as a new feature in the web client. |
| 15:31 |
jeff |
pre-login/post-login message / banner / popup, banner across the entire top of the page, or some combination of those things. |
| 15:33 |
bshum |
Hmm |
| 15:33 |
bshum |
I don't see why not |
| 15:35 |
csharp |
we used to use the "reddish" opac theme on our test server, but that didn't help from the client |
| 15:35 |
bshum |
Oh that's a throwback to the old days :) |
| 15:35 |
bshum |
I guess those files still exist. We need to finish ripping all that out sometime... |
| 15:36 |
csharp |
so theoretically, if the client has next.gapines.org in its autoupdate.js file, it might grab those update files even if it's logging into gapines.org? |
| 15:36 |
csharp |
bshum: yeah, that was back in 2009 |
| 15:36 |
bshum |
csharp: I would think it would check that server every time it hiccupped and couldn't verify its version from gapines.org |
| 15:37 |
bshum |
Or it'll just randomly suggest from time to time, hey upgrade me |
| 15:37 |
csharp |
well, the next server hasn't been updated since last year |
| 15:37 |
bshum |
Since that's where it'd check towards |
| 15:37 |
bshum |
Not the hostname you enter |
| 15:37 |
csharp |
right |
| 15:37 |
csharp |
okay - this is making more sense now |
| 15:39 |
csharp |
it never occurred to me that staff would be using test clients in production without realizing it |
| 15:39 |
csharp |
but we've never disallowed them in production either (via symlink) |
| 15:40 |
bshum |
Indeed. |
| 16:33 |
* jeff |
laughs at himself |
| 16:37 |
|
kmlussier joined #evergreen |
| 16:38 |
kmlussier |
dbwells++ |
| 16:39 |
kmlussier |
I'll try to fit in testing the new Negative Balance branch as soon as I can. |
| 16:39 |
* kmlussier |
disappears again. |
| 16:43 |
jeff |
mumble mumble billing mumble mumble |
| 16:43 |
jeff |
mous and mus can differ when there are closed xacts with non-zero balance_owed. |
| 16:44 |
jeff |
and the number of users where SUM(mmbxs.balance_owed) <> mous.balance_owed is different from the number of distinct users where mmbxs.xact_finish IS NOT NULL AND mmbxs.balance_owed <> 0 |
| 16:45 |
jeff |
i'm sure there's a perfectly logical reason for that, and it probably involves xacts that even themselves out. |
| 16:59 |
jeff |
...or it's because one of the two operands in the comparison is null. |
| 17:04 |
jeff |
right. user with zero open xacts == mous.balance_owed is null. |
| 17:14 |
tsbere |
jeff: Gotta watch out for those nulls. |
| 17:15 |
jeff |
yup. |
| 17:16 |
jeff |
they'll get you every time. |
| 17:18 |
tsbere |
I find myself using IS (NOT) DISTINCT FROM when I suspect nulls may be involved. Especially when both sides may be null and I want to count that as "equal". That and to keep it in my head, if I don't use it for a while I forget about it. <_< |
| 17:19 |
jeff |
my query evolved from some clumsy-looking HAVING clauses to a pair of COALESCE calls. i like the IS DISTINCT FROM option. |
| 17:21 |
jeff |
hrm. of course, IS DISTINCT FROM doesn't help me in this specific case (i really just need to use COALESCE) |
| 17:21 |
jeff |
still adding that to my toolbox for future use. |
| 17:21 |
jeff |
tsbere++ |
| 17:31 |
|
dbwells_ joined #evergreen |
| 18:28 |
Stompro_home |
Anyone have experience using the Debian postgresql builds from https://wiki.postgresql.org/wiki/Apt? |
| 18:42 |
bshum |
Stompro_home: Yes, I use them regularly. |
| 18:43 |
bshum |
For Evergreen and other projects that require PostgreSQL. |
| 18:43 |
bshum |
Well, not Debian I guess... ubuntu. |
| 18:43 |
bshum |
But same difference. |
| 18:46 |
bshum |
What's up? |
| 18:55 |
|
mrpeters joined #evergreen |
| 19:38 |
|
sarabee joined #evergreen |
| 21:30 |
|
nhilton joined #evergreen |
| 22:01 |
Stompro_home |
bshum: Sorry, left for suppertime and then bedtime. I'm just curious if we should take out the bit from the install docs about using debian backports and just use the Postgrest repo so everyone can use 9.3, vs Wheezy users running the 9.1 backport. |
