| Time |
Nick |
Message |
| 01:39 |
|
Mark__T joined #evergreen |
| 03:03 |
|
gsams joined #evergreen |
| 05:21 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:33 |
|
TaraC joined #evergreen |
| 07:32 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
rlefaive joined #evergreen |
| 08:06 |
|
rjackson_isl joined #evergreen |
| 08:09 |
|
ericar joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:12 |
|
Mark__T joined #evergreen |
| 08:25 |
kmlussier |
Good morning #evergreen! |
| 08:29 |
|
mrpeters joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:44 |
|
Dyrcona joined #evergreen |
| 08:50 |
Dyrcona |
Anyone got any magic SQL to find a patron with a negative balance? |
| 08:50 |
jboyer-isl |
I got 99 problems and fixed fields are uu of them. |
| 08:50 |
Dyrcona |
heh |
| 08:52 |
jboyer-isl |
Dyrcona: do you mean a single bill with a negative balance, or a total balance? |
| 08:53 |
jboyer-isl |
I think we've got something usable somewhere. |
| 08:53 |
Dyrcona |
A single bill would be better, but I'll take what I can get. :) |
| 08:53 |
jboyer-isl |
select * from money.billable_xact_summary where balance_owed < 0; |
| 08:54 |
jboyer-isl |
Or select usr, rather. |
| 08:55 |
Dyrcona |
Ah, didn't think it would be that simple. |
| 08:57 |
jboyer-isl |
It's only as reliable as your money.materialized_billable_xact_summary, but I think those are pretty safe. |
| 08:57 |
Dyrcona |
jboyer-isl++ |
| 08:58 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "I did this" (8 lines) at http://paste.evergreen-ils.org/29 |
| 08:59 |
Dyrcona |
That way, I get barcodes. |
| 09:00 |
Dyrcona |
I'm looking into LP 1494427. |
| 09:00 |
pinesol_green |
Launchpad bug 1494427 in Evergreen "Staff client refund option generates an error" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1494427 |
| 09:00 |
Dyrcona |
It looks like something quick I can do before the rest of my day gets swallowed whole by meetings. |
| 09:01 |
Dyrcona |
And one barcode shows up at least three times, think I'll test with that patron. |
| 09:06 |
|
mmorgan left #evergreen |
| 09:08 |
|
yboston joined #evergreen |
| 09:16 |
pinesol_green |
[evergreen|Kathy Lussier] lp1494427: Fix refund error - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4efea97> |
| 09:21 |
|
maryj joined #evergreen |
| 09:33 |
* jeff |
looks to see if usr day_phone is exposed to hold slips |
| 09:34 |
Dyrcona |
I think it is, but I'm not certain. |
| 09:39 |
Stompro |
Good morning everyone, if I want to create a new "skin" for the self check, to customize the css files in their own dir "/openils/var/web/css/skin/default". In the tt2 template files the variable ctx.skin=default by default, where is ctx.skin set? Is that an apache directive? |
| 09:41 |
|
mmorgan joined #evergreen |
| 09:49 |
|
maryj joined #evergreen |
| 09:51 |
berick |
Stompro: see EGWeb.pm. appears to be modified via cookie only at the moment. |
| 09:51 |
bshum |
I imagine it could be added as a defined variable though elsewhere in the templates. |
| 09:51 |
berick |
bshum: yes, definitely |
| 09:51 |
jeff |
$ctx->{skin} = $cgi->cookie(OILS_HTTP_COOKIE_SKIN) || 'default'; |
| 09:51 |
jeff |
use constant OILS_HTTP_COOKIE_SKIN => 'eg_skin'; |
| 09:51 |
berick |
you could set ctx.skin = whatever directly in the template |
| 09:52 |
jeff |
(for the specific bits from EGWeb.pm) |
| 09:52 |
csharp |
@who has the best cookie skin? |
| 09:52 |
pinesol_green |
dbwells has the best cookie skin. |
| 09:52 |
berick |
more than 1 way to skin a cookie? |
| 09:52 |
csharp |
Cookie Skin sounds like a band name from Parks and Recreation |
| 09:52 |
jeff |
those are the only two lines that reference that cookie that i can see. |
| 09:52 |
bshum |
berick++ # I was looking in the wrong place in WWW perl bits. |
| 09:53 |
jeff |
so, nothing that currently sets/manipulates the cookie in Evergreen at present. |
| 09:53 |
Stompro |
berick, jeff, bshum thanks guys. |
| 10:15 |
berick |
i feel like i'm missing something obvious here.. i have a perm grp that's a child of Patrons. i want to prevent opac logins for the child group. |
| 10:15 |
berick |
assuming Patrons has the OPAC_LOGIN permission, the only way to do that is to move the group out of the Patrons group. |
| 10:16 |
* berick |
wonders if there's an alternative |
| 10:16 |
bshum |
berick: Given that perms are inherited, usually that's the quickest way to change it. Otherwise, you'd have to remove the perm at the top level and assign it only to each subgroup individually? |
| 10:17 |
jeff |
That matches my current understanding of permissions in Evergreen. |
| 10:18 |
berick |
yeah, ok. thanks for confirming. |
| 10:18 |
jeff |
implicit inheritence, no overrides. |
| 10:20 |
mmorgan |
It's a little counter-intuitive that the "Parent" group has the lower permission than the "Child". But once you get used to thinking that way, it makes sense. |
| 10:22 |
csharp |
ok - I just hit a snag when running 2.8.3-2.9-rc-upgrade-db.sql... when it hits line 22204 (ALTER TABLE config.record_attr_definition...), I get ERROR: cannot ALTER TABLE "record_attr_definition" because it has pending trigger events |
| 10:23 |
csharp |
research (http://stackoverflow.com/questions/12838111/south-cannot-alter-table-because-it-has-pending-trigger-events) indicates that this is because we change data in that table within the same transaction where we're trying to ALTER it |
| 10:25 |
bshum |
csharp: That sort of thing happens sometimes |
| 10:25 |
bshum |
When we touch the same table a couple times during the same major upgrade |
| 10:25 |
bshum |
Cause the minor upgrade scripts do stuff |
| 10:25 |
csharp |
well, it looks like we'll need to change the script so that it doesn't do that in the same transaction |
| 10:25 |
bshum |
Usually, only live testing reveals it, and then the RM can make necessary edits to the upgrade script |
| 10:26 |
csharp |
ok, so bug report? |
| 10:26 |
bshum |
And either combine necessary changes into one SQL update, or break it up into stuff inside and outside the main body transaction |
| 10:27 |
|
Christineb joined #evergreen |
| 10:42 |
csharp |
fe9777f4 |
| 10:42 |
pinesol_green |
[evergreen|Galen Charlton] LP#1427287: MARC tag-table service - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe9777f> |
| 10:42 |
|
pmurray_away joined #evergreen |
| 10:43 |
csharp |
bug 1427287 |
| 10:43 |
pinesol_green |
Launchpad bug 1427287 in Evergreen ""Tag table" service" (affected: 2, heat: 12) [Wishlist,Fix committed] https://launchpad.net/bugs/1427287 |
| 10:44 |
csharp |
73be52e6 |
| 10:44 |
pinesol_green |
[evergreen|Galen Charlton] LP#1442815: teach record attributes about SKOS - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73be52e> |
| 10:44 |
csharp |
bug 1442815 |
| 10:45 |
pinesol_green |
Launchpad bug 1442815 in Evergreen "Start teaching Evergreen about SKOS: coded values" (affected: 1, heat: 6) [Undecided,Fix committed] https://launchpad.net/bugs/1442815 |
| 10:46 |
csharp |
okay - so those two^^ are the conflicting DB upgrade scripts |
| 10:47 |
|
pmurray joined #evergreen |
| 10:47 |
csharp |
are there opinions about whether the fix should be two transactions in the same script? separate scripts? separating schema and data changes in general? |
| 10:47 |
* csharp |
notices that Dyrcona is not present |
| 10:48 |
bshum |
I don't like two transactions in the same major upgrade script. |
| 10:48 |
bshum |
Leads to, this part worked, and then this part failed, and now I have only half a working DB. |
| 10:49 |
csharp |
well, one of the answers to that stackoverflow post I linked to earlier suggested separating data and schema changes when upgrading things |
| 10:49 |
csharp |
seems like a smart approach on the face of it |
| 10:50 |
bshum |
I think there are examples in prevoius major upgrade scripts on approached undertaken. |
| 10:50 |
bshum |
But basically yes, usually we make the schema changes in the main upgrade script |
| 10:50 |
bshum |
And then apply data changes in the next block or something like that. |
| 10:50 |
bshum |
I think. |
| 10:50 |
bshum |
Or if it's a case of two schema changes conflicting, combining them into one statement. |
| 10:51 |
bshum |
I'd have to look more clearly at where the breakdown is happening in the combined script, rather than the individual ones |
| 10:51 |
bshum |
I'm not seeing it quite yet. |
| 10:51 |
* bshum |
hates version-upgrades btw |
| 10:53 |
* csharp |
resists letting this become another "run master" vs. "run releases" discussion |
| 10:54 |
* bshum |
just finds it ironic that he always inevitably gets tangled in fixing version-upgrade scripts he never uses :D |
| 10:56 |
csharp |
I'm happy to help (or even fix) fwiw |
| 10:57 |
csharp |
I would want some guidance about best practices |
| 10:58 |
csharp |
anyway - the problem seems clear, though, we're changing the table definition after creating a pending data change |
| 10:59 |
bshum |
csharp: Looking at the major upgrade script, I think it makes sense to move all the INSERTs for the tag table stuff outside the main transaction |
| 10:59 |
bshum |
Maybe |
| 10:59 |
bshum |
As you say, "best practices" can sometimes be in short supply here. |
| 11:03 |
miker |
to confirm the perm discussion circa 10:20, permissions are always additive -- you cannot subtract a permission provided by an ancestor group |
| 11:05 |
miker |
csharp: 2 transactions is how we've handle it in the past, so that you at least have logical chunks of "works" and "didn't work" if the second transaction fails. for things that are allowed to fail, put them outside any explicit transaction |
| 11:06 |
|
pgardella joined #evergreen |
| 11:12 |
Stompro |
mmorgan, does printing the list of holds work for you on your self checks(EG web based self check)? It doesn't work for me with a default setup. |
| 11:13 |
bshum |
Stompro: Do you have popups disabled? |
| 11:14 |
Stompro |
bshum, the other print lists work fine, printing list of items out and fines work. Popups are allowed. |
| 11:15 |
bshum |
Stompro: Do you have any sort of browser error logging? Maybe it could indicate if it's a specific failure somewhere in the execution |
| 11:15 |
* bshum |
hasn't tested hold printing lately |
| 11:15 |
Stompro |
bshum, thanks I'll enable the JS log and see what it says. |
| 11:17 |
bshum |
length of undefined |
| 11:17 |
bshum |
That's helpful... |
| 11:18 |
bshum |
So that might be a bug |
| 11:19 |
bshum |
Stompro: https://bugs.launchpad.net/evergreen/+bug/1370694 |
| 11:19 |
pinesol_green |
Launchpad bug 1370694 in Evergreen "Selfcheck "Print List" for Holds view does not work" (affected: 1, heat: 6) [Medium,Confirmed] |
| 11:19 |
bshum |
Already filed about a year ago, amusingly |
| 11:19 |
bshum |
mmorgan++ :) |
| 11:19 |
Stompro |
Thanks bshum, I always forget to search bugs, sorry. |
| 11:20 |
Stompro |
I'm not sure we want people to print out a list of their 45 holds at the self check.. So maybe I'm ok with this not working ;-) |
| 11:21 |
Stompro |
I won't list it as a feature on the self check docs update I'm working on. |
| 11:22 |
bshum |
Stompro: Heh, good point. |
| 11:30 |
|
jihpringle joined #evergreen |
| 12:19 |
|
pgardella1 joined #evergreen |
| 12:33 |
|
pmurray left #evergreen |
| 12:39 |
|
rlefaive joined #evergreen |
| 12:45 |
|
bmills joined #evergreen |
| 13:04 |
* mmorgan |
reads up. |
| 13:05 |
mmorgan |
Glad Stompro and bshum found the hold slip printing bug. It really hasn't been much of an issue for us for the reason Stompro mentioned. |
| 13:06 |
mmorgan |
Can anybody point me to some fairly concise guidelines for setting up credit card processing using paypal? |
| 13:08 |
mmorgan |
We have a training system set up with a paypal sandbox, but aren't having any success testing payments. |
| 13:14 |
kmlussier |
mmorgan: I thought there was a message on the mailing list that had a concise list of steps, but I don't see it now. |
| 13:14 |
kmlussier |
mmorgan: I once successfully used the paypal sandbox with Evergreen, but it was so long ago, I don't recall what I did. I remember I was a bit confused on the PayPal side of things. |
| 13:16 |
mmorgan |
kmlussier: Right now I'm a bit confused on both sides! ;-) |
| 13:18 |
mmorgan |
We've gotten a couple different messages when trying to process a payment. Invalid paypal credentials, missing billing agreement. Now I'm getting an internal server error. |
| 13:23 |
mmorgan |
Ok, the internal server error was because the patron I was using had no address. |
| 13:23 |
jeff |
picky picky. |
| 13:23 |
mmorgan |
I'm getting this error now that I have an address: The credit card processor has declined the transaction. 10501: This transaction cannot be processed due to an invalid merchant configuration. |
| 13:31 |
jeffdavis |
We're still seeing very slow load times on bookbags (EG 2.8.1 with customizations, PG 9.4). It's looking like a bad query plan or something similar. Changing how the bookbag query is constructed results in vastly improved load times: |
| 13:32 |
jeffdavis |
bookbag query #1 (>20s): http://pastebin.com/45UCS4yR | http://explain.depesz.com/s/23Y |
| 13:32 |
jeffdavis |
bookbag query #2 (0.1s): http://pastebin.com/spRUGhwR | http://explain.depesz.com/s/hhU |
| 13:33 |
jeffdavis |
In the latter, we manually force the join between acp and acn to be at the core of the query, to avoid a whole ton of loops over rows that are getting discarded anyway. |
| 13:33 |
jeffdavis |
I'm not sure if it's possible to force the query to be constructed that way, or if there's some PG tuning or other stuff that needs to be done instead. |
| 13:36 |
|
Dyrcona joined #evergreen |
| 13:36 |
jeffdavis |
^ Noted here so that it's in the logs. I haven't reproduced on a stock EG install yet, so no LP bug so far. |
| 13:43 |
jeff |
jeffdavis: on the system where you're seeing this, is it affecting most/all bookbags, or just some/one? |
| 13:43 |
jeffdavis |
All the ones I've tested so far, but my testing pool has been fairly small. |
| 13:44 |
jeff |
seq scan on asset.copy -- ouch. |
| 13:46 |
jeffdavis |
The filter there is on two boolean columns though, so it seems like the solution isn't an index but reducing the number of rows scanned. |
| 13:49 |
|
maryj joined #evergreen |
| 13:52 |
|
ericar_ joined #evergreen |
| 13:55 |
jeff |
Pokémon: gotta' encode 'em all! |
| 13:57 |
Dyrcona |
heh |
| 13:58 |
Dyrcona |
decode 'em, too. :) |
| 13:58 |
csharp |
jeffdavis: |
| 13:58 |
csharp |
Nested Loop Left Join (cost=119.51..174,661.69 rows=8,912 width=119) (actual time=7.109..21,080.741 rows=2,784,220 loops=1) looks like the planner stats are off |
| 13:58 |
csharp |
estimating 8,912 rows vs. actual 2,784,220 |
| 13:59 |
jeff |
Dyrcona: in this case, double-encoding seems to be the issue :-) |
| 14:01 |
csharp |
jeffdavis: I have/had a similar issue with the simplified holds list query (see bug 1469758) |
| 14:01 |
pinesol_green |
Launchpad bug 1469758 in Evergreen "Simplified Pull List Interface query is very slow" (affected: 1, heat: 6) [Undecided,Triaged] https://launchpad.net/bugs/1469758 |
| 14:03 |
jeffdavis |
csharp: Interesting! You folks are on PG 9.4, right? |
| 14:03 |
csharp |
9.3, currently |
| 14:03 |
jeffdavis |
ah nope, I see 9.3 in the bug :) |
| 14:03 |
csharp |
testing on 9.4 as we speak, though |
| 14:03 |
jeff |
jeffdavis: what are you guys on? |
| 14:04 |
jeffdavis |
we're 9.4 |
| 14:04 |
csharp |
jeffdavis: see the suggestions from miker in the last comment on the bug report - they didn't solve my issue, but may help yours |
| 14:04 |
jeffdavis |
csharp: I see miker suggested adjusting stats on one of the tables there, have you tried that? |
| 14:04 |
csharp |
heh - yep |
| 14:04 |
csharp |
they didn't solve the problem, so I let it go |
| 14:05 |
csharp |
actually, I haven't tested it since we purged most of our holds data |
| 14:05 |
csharp |
it's probably fixed |
| 14:07 |
csharp |
nope - stats are still borked for me on that query |
| 14:07 |
csharp |
it is faster, though |
| 14:07 |
miker |
jeffdavis: your modification looks like it's just joining call number before location. I wonder if the underlying json_query can just be adjusted to do that. where is the code for that query, if you know off hand? |
| 14:07 |
csharp |
in my case, it's vastly overestimating the number of rows |
| 14:09 |
jeffdavis |
miker: not sure yet - figuring that out is the next step on my todo list for that bug :) |
| 14:12 |
jeff |
jeffdavis: this is a bookbag search? |
| 14:14 |
|
yboston joined #evergreen |
| 14:14 |
jeffdavis |
jeff: yes |
| 14:14 |
jeff |
if so, QueryParser.pm -- around line 1130 in master. "container" filter of class bre. |
| 14:15 |
jeffdavis |
or more specifically it's retrieving (fleshing?) an item that's in a bookbag |
| 14:17 |
jeff |
this kind of search, right? https://catalog.tadl.org/eg/opac/results?bookbag=3108;page=0;locg=22;depth=0 |
| 14:18 |
jeffdavis |
precisely |
| 14:19 |
jeff |
OpenILS::WWW::EGCatLoader::Search::_prepare_biblio_search turns that into "container(bre,bookbag,3108)" |
| 14:19 |
miker |
it's coming from Open-ILS/src/perlmods/lib/OpenILS/Application/AppUtils.pm:1964 |
| 14:23 |
jeff |
miker: Is that called anywhere other than when displaying a record detail page? |
| 14:24 |
jeffdavis |
as I understand it, EGCatLoader::Account->load_myopac_bookbags gets a list of items using AppUtils->bib_container_items_via_search and then feeds the results to EGCatLoader::Util->get_records_and_facets |
| 14:24 |
jeffdavis |
get_records_and_facets is generating the actual SQL pasted above (I think) |
| 14:25 |
jeffdavis |
or, well, constructing the json_query object that gets turned into SQL |
| 14:28 |
jeff |
Ah. That's a different interface. :-) |
| 14:30 |
jeffdavis |
sorry no, it's not get_records_and_facets (at least not directly), the query is for holdings (and associated circ info) not records |
| 14:31 |
jeff |
I just meant that /eg/opac/myopac/lists <> /eg/opac/results?bookbag= |
| 14:31 |
miker |
the query in basic_opac_copy_query could certainly be reordered to touch acn first |
| 14:32 |
miker |
that should help generate a better plan |
| 14:33 |
|
sandbergja joined #evergreen |
| 14:34 |
jeffdavis |
miker: EGCatLoader::Record->mk_copy_query ? |
| 14:35 |
miker |
jeffdavis: no, in Open-ILS/src/perlmods/lib/OpenILS/Application/AppUtils.pm, basic_opac_copy_query |
| 14:35 |
miker |
though that may require touching callers of that sub |
| 14:48 |
pastebot |
"miker" at 64.57.241.14 pasted "jeffdavis: something like this" (114 lines) at http://paste.evergreen-ils.org/30 |
| 14:48 |
miker |
(entirely untested) |
| 14:48 |
miker |
but the point is to make acn the core class |
| 14:50 |
jeffdavis |
miker++ # I'll try variations on that and see how it goes, thanks! |
| 14:50 |
miker |
so that the WHERE clause restriction on acn.record is at the top of the join tree instead of after a bunch of left joins |
| 14:58 |
miker |
for the room, one can always order joins in json_query by nesting them; if one doesn't, join order at each level is at the mercy of JSON object property order (random, esp when coming from Perl) |
| 14:59 |
Dyrcona |
JSON queries are fun! :) |
| 15:27 |
|
pgardella joined #evergreen |
| 15:31 |
|
pgardella1 joined #evergreen |
| 15:55 |
|
pgardella joined #evergreen |
| 15:58 |
|
jlitrell joined #evergreen |
| 15:59 |
|
maryj joined #evergreen |
| 16:26 |
|
bmills joined #evergreen |
| 16:30 |
|
ericar joined #evergreen |
| 16:35 |
* kmlussier |
grabs the code from bug 1494544 to get a Sandbox set up for testing later this evening. |
| 16:35 |
pinesol_green |
Launchpad bug 1494544 in Evergreen "Void options in the billing UI allow negative balances to occur when they should be prohibited" (affected: 1, heat: 6) [Critical,Confirmed] https://launchpad.net/bugs/1494544 - Assigned to Dan Wells (dbw2) |
| 16:36 |
kmlussier |
dbwells++ |
| 16:37 |
|
Christineb joined #evergreen |
| 16:40 |
* kmlussier |
also grabs the code from bug 1340852 in the hopes of getting jlitrell's first contribution into Evergreen. :) |
| 16:40 |
pinesol_green |
Launchpad bug 1340852 in Evergreen "Copy Location Groups search not retaining original search params after searching" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1340852 |
| 16:53 |
jlitrell |
Huzzah! |
| 17:04 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:34 |
Bmagic |
Has anyone tackled sending automated emails to patrons on a regular basis showing how much to owe? I can't imagine an action trigger doing this. Any thoughts? |
| 17:35 |
Bmagic |
how much they* owe |
| 20:19 |
|
pinesol_green` joined #evergreen |
| 20:23 |
|
pastebot joined #evergreen |
| 20:24 |
|
rangi joined #evergreen |
| 20:24 |
|
rangi joined #evergreen |
| 20:28 |
|
Christineb_ joined #evergreen |
| 20:42 |
|
_bott_ joined #evergreen |
| 20:44 |
|
kmlussier joined #evergreen |
| 20:44 |
|
mceraso joined #evergreen |
| 20:44 |
|
bshum joined #evergreen |
| 20:44 |
pinesol_green` |
All hail the supreme potentate, bshum has arrived! |
| 22:05 |
|
book` joined #evergreen |
| 22:30 |
|
_bott_ joined #evergreen |
