| 00:36 |
|
mmorgan1 joined #evergreen |
| 03:39 |
|
mtcarlson joined #evergreen |
| 04:26 |
|
remingtron joined #evergreen |
| 05:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:49 |
|
b_bonner joined #evergreen |
| 05:52 |
|
mtcarlson_away joined #evergreen |
| 05:53 |
|
mnsri joined #evergreen |
| 14:11 |
|
RoganH joined #evergreen |
| 14:13 |
tspindler |
bshum: does Dan need to do something more with this https://bugs.launchpad.net/evergreen/+bug/1099979 |
| 14:13 |
pinesol_green |
Launchpad bug 1099979 in Evergreen "Merge Parts" (affected: 4, heat: 18) [Wishlist,Confirmed] |
| 14:16 |
bshum |
tspindler: I don't think so. The changes worked for me enough in my initial testing that I felt comfortable picking in the commit pretty soon |
| 14:16 |
bshum |
I was just getting all the t's crossed and i's dotted |
| 14:17 |
tspindler |
thank bshum, I just wasn't sure if you were looking for more testing from us |
| 14:18 |
tspindler |
i think we need to return the favor and do some testing of others code ;) |
| 14:18 |
RoganH |
bshum: you still need testing on the merge parts? |
| 14:19 |
bshum |
tspindler: There's always welcome room for further testing :) |
| 14:19 |
bshum |
RoganH: If you feel interested to take a look, that'd be great to have an extra pair of eyes look it over. My own light testing seemed fine, but I don't mind the extra checks. |
| 14:20 |
RoganH |
bshum: I've been meaning to dig around launchpad for another commit to test to help out if another signoff is needed. I just hadn't done so yet. |
| 14:20 |
RoganH |
bshum: Move from our old servers to Sequoia was last night so it's been busy. |
| 14:20 |
bshum |
I hear that |
| 14:32 |
Dyrcona |
tspindler: Keep an eye on your launchpad bug email this afternoon. |
| 14:49 |
|
muddles17 joined #evergreen |
| 14:51 |
|
muddles17 left #evergreen |
| 14:51 |
|
muddles17 joined #evergreen |
| 15:06 |
tspindler |
Dyrcona: okee dokee |
| 15:09 |
tspindler |
I had a question about testing, does everyone test with concerto data or do you also test with production (I think I know the answer for Dyrcona) but I was wondering about others? |
| 15:09 |
tspindler |
not on production but with production data that is |
| 15:11 |
RoganH |
tspindler: varies a bit, if it's a UI thing I will test on a VM with concerto data, but something like the 856 testing a while back I did on a test box with production data because I didn't feel test data would find issues |
| 15:11 |
csharp |
tspindler: we pretty much *only* test with production data |
| 15:12 |
RoganH |
If you're talking about broader testing like testing upgrades it's always with production data. |
| 15:12 |
csharp |
the default OU setup and concerto don't feel "real" enough for our end user testers, so we haul around our huge dataset from server to server |
| 15:13 |
csharp |
testing for bugfix signoffs and the like, I use default setup/concerto on current master |
| 04:42 |
|
b_bonner joined #evergreen |
| 04:42 |
|
mnsri joined #evergreen |
| 04:43 |
|
mtcarlson_away joined #evergreen |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:16 |
|
akilsdonk joined #evergreen |
| 08:27 |
|
Dyrcona joined #evergreen |
| 08:31 |
|
mrpeters joined #evergreen |
| 08:48 |
csharp |
680K deleted records from our bib cleanup a few years back |
| 08:48 |
csharp |
so those can be deleted without trouble? I'm looking for constraints for other tables, but don't see them |
| 08:49 |
eeevil |
if you aren't concerned about losing author/title/pub/isbn/etc on reports that pull data from those, you can remove that |
| 08:49 |
csharp |
ok cool |
| 08:49 |
csharp |
in my immediate instance, it's a test server we're using just for reports at the moment, so I'm willing to experiment |
| 08:49 |
eeevil |
historical reports (say, on circs from 2 years ago) will lose data |
| 08:49 |
csharp |
oh |
| 08:49 |
eeevil |
ah, yeah, for a test server I say "BURN IT ALL DOWN" |
| 08:50 |
eeevil |
but for production ... 37G is cheap, even on SSD, these days (IMNSHO ... I hate tossing data) |
| 08:51 |
csharp |
I don't like tossing data either... just looking for options ;-) |
| 08:51 |
csharp |
thanks |
| 08:58 |
|
akilsdonk_ joined #evergreen |
| 12:36 |
Dyrcona |
eeevil: Count me in. I can with high probability even help with code. |
| 12:36 |
eeevil |
Dyrcona++ |
| 12:36 |
* eeevil |
stashes the whisk[e]y video for later... |
| 12:38 |
bshum |
berick++ # make_release patch worked for me. I'll push it and then finish testing this 2.7.0-alpha tarball and get it up to Lupin |
| 12:41 |
dbs |
eeevil: so $hours = $self->editor->retrieve_actor_org_unit_hours_of_operation($lib_id); |
| 12:41 |
dbs |
in EGCatLoader/Library.pm -- that's considered "bad"? |
| 12:41 |
* eeevil |
consults idl... |
| 13:21 |
Dyrcona |
It |
| 13:21 |
Dyrcona |
oops |
| 13:26 |
|
akilsdonk joined #evergreen |
| 13:28 |
bshum |
Remind me, did we put the test builds to the left or right of the current stables on the downloads page usually? |
| 13:28 |
bshum |
I want to say to the right so that latest stable is always at the left |
| 13:28 |
bshum |
But I can't quite recall |
| 13:36 |
eeevil |
bshum: right, I'm pretty certain |
| 13:38 |
bshum |
eeevil: Thanks, just checking. I'm going to edit up the page in a moment to put up the 2.7 files. |
| 13:38 |
bshum |
I suppose at the same time, we can remove 2.4 since that series is ended. |
| 15:59 |
gmcharlt |
just think of earworm distribution as a specialization of readers' advisory |
| 16:05 |
|
Shae_ joined #evergreen |
| 16:28 |
|
tspindler left #evergreen |
| 17:23 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:23 |
|
kmlussier left #evergreen |
| 17:24 |
|
mmorgan left #evergreen |
| 17:55 |
|
akilsdonk joined #evergreen |
| 16:59 |
ahelten |
And 3 or 4 other errors like that (missing functions) |
| 16:59 |
phasefx |
looks like once before csharp had not quite the same error, but in the same vicinity: http://evergreen-ils.org/irc_logs/evergreen/2013-05/%23evergreen.22-Wed-2013.log |
| 16:59 |
phasefx |
http://evergreen-ils.org/irc_logs/evergreen/2013-05/%23evergreen.24-Fri-2013.log |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:12 |
pastebot |
"ahelten" at 64.57.241.14 pasted "Errors during import into PG 9.1 database of 1.6.0.4 export" (38 lines) at http://paste.evergreen-ils.org/72 |
| 17:14 |
ahelten |
phasefx: I think csharp's problem was different and unfortunately those irc logs don't even show how he solved the problem. The more I look at this, the more I think it goes back to the upgrade to Pg 9.1 |
| 17:14 |
ahelten |
Here is the error from the Pg 9.1 import (at least I'm pretty sure that it's from the import): http://paste.evergreen-ils.org/72 |
| 17:41 |
bshum |
I'd wonder if those initial import issues were due to the method used to export / import into the new database. |
| 17:42 |
dbwells |
ahelten: It's late in the day, so this might be suspect advice, but I'd try to just comment out line 96 from that upgrade file and see what happens. It was supposed to be a safety measure, but it might be making assumptions about your DB history / setup which just aren't true. |
| 17:42 |
ahelten |
dbwells: I'll give it a try |
| 17:43 |
bshum |
ahelten: You're running your upgrades on a test server I hope. |
| 17:43 |
bshum |
Using a copy of your real database |
| 17:43 |
ahelten |
Yes |
| 17:44 |
dbwells |
There is something unexpected about your transition from the tsearch2 extension to the inbuilt stuff, but I can't exactly put my finger on where your DB is at. |
| 17:47 |
ahelten |
Error moved to line 98: psql:2.3-2.4.0-upgrade-db.sql:98: ERROR: extension "tsearch2" does not exist |
| 18:27 |
dbwells |
I'm heading out in any case. Hope things go smoother from here for you. |
| 18:27 |
ahelten |
dbwells: most of the "take a while" threats are not true on our little database but it is working away now, looks like the -d worked |
| 18:27 |
bshum |
dbwells++ |
| 18:28 |
ahelten |
dbwells: thanks for the help, you got me past a couple problems anyway |
| 18:57 |
|
jmccarty joined #evergreen |
| 19:51 |
ahelten |
bshum, I have more testing to do but so far it looks like my upgrade to 2.6.2 was successful. Thanks again for the help |
| 19:52 |
bshum |
ahelton: Good luck! Hope things continue to work out |
| 20:10 |
|
wjr_ joined #evergreen |
| 21:51 |
|
mtcarlson joined #evergreen |
| 05:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:57 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
jennyl joined #evergreen |
| 08:05 |
|
jboyer-isl joined #evergreen |
| 14:58 |
* kmlussier |
needs more coffee. |
| 14:59 |
kmlussier |
Dyronca: You're trying to think of a title that the three networks don't have in common? |
| 14:59 |
Dyrcona |
Well, an author title, whatever, where 1 might have a lot of stuff and the others not so much. |
| 15:00 |
Dyrcona |
I'm trying to test dpearl's z39.50 branch. |
| 15:00 |
Dyrcona |
I either get hundreds of things or nothing. |
| 15:00 |
kmlussier |
I would shoot for a title that an academic might own. |
| 15:01 |
Dyrcona |
good idea! |
| 15:04 |
Dyrcona |
I may try a title instead of the author. |
| 15:05 |
Dyrcona |
Well, z39.50 really mangles the UTF-8. |
| 15:06 |
Dyrcona |
I think I've seen that before, because its going through evergreen and yaz, its getting double decoded or rencoded or something like that. |
| 15:06 |
tspindler |
Thanks for looking at this Dyrcona, Janet tested it before on our end |
| 15:06 |
Dyrcona |
tspindler: I'm just trying to find something that resembles the original problem. |
| 15:07 |
Dyrcona |
The changes look good to me, and I get well distributed results with them. |
| 15:08 |
Dyrcona |
One thing that has changed for me with the code is before I loaded the branch when I had 400 or so hits for 'harry potter' as title, I got 12 results in the window, with 4 from each consortium. |
| 16:30 |
Dyrcona |
Does anyone ever get Z39.50 results from biblios.net? |
| 16:30 |
Dyrcona |
I don't. |
| 16:32 |
kmlussier |
It looks like Monday, July 28, 3 p.m. EDT is the winner. I'll add it to the dev calendar. |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:54 |
|
ktomita joined #evergreen |
| 20:01 |
|
RBecker joined #evergreen |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:04 |
|
riot joined #evergreen |
| 05:22 |
|
wjr_ joined #evergreen |
| 07:35 |
|
rjackson-isl joined #evergreen |
| 10:51 |
Dyrcona |
csharp: offline circulation and manualupdate.html |
| 10:52 |
csharp |
argh |
| 10:52 |
Dyrcona |
cgi-bin/offline alias also gives a nice warning when you start Apache on trusty. |
| 10:52 |
Dyrcona |
I haven't tested if it still works, yet. I probably should. |
| 10:53 |
dbs |
krvmga: probably need to provide an example like http://pastebin.com/cxHyWbHC along with some example template overrides for the likes of config.tt2 |
| 10:53 |
Dyrcona |
I'm not sure it is a general Apache 2.4 problem. It may only be a problem with trusty. I saw it after upgrading, and I think bshum saw it with a fresh install. |
| 10:53 |
bshum |
Dyrcona: Ugh, I just saw that error now in the restart I issued |
| 10:56 |
bshum |
Dyrcona: I guess we should file and fix that too |
| 10:57 |
Dyrcona |
It could be something in my configs that is unusual. |
| 10:57 |
Dyrcona |
The upgrade was a mess. |
| 10:57 |
Dyrcona |
I also configured a Dancer app for NCIP testing, but I get that with or without that configuration in place. |
| 10:57 |
bshum |
Well, my clean install gets the same "warning" but yeah. |
| 10:58 |
Dyrcona |
Oh, if you get it clean, then we should do something about it. |
| 10:58 |
bshum |
Course it didn't start giving me that warning till I turned on CGI :) |
| 11:03 |
bshum |
Seems easier to just add cgi to the makefile for trusty to me if that gets us there ;) |
| 11:04 |
csharp |
short term, I agree with bshum, long term, I agree with Dyrcona to move off of CGI if those are the only two things using it |
| 11:06 |
Dyrcona |
I want to make sure offline circ works with 2.4 on trusty before we do much of anything. |
| 11:06 |
* Dyrcona |
jots that down to test later today or tomorrow morning. |
| 11:10 |
bshum |
Yeesh |
| 11:10 |
bshum |
Using the offline gets me skull/crossbone errors |
| 11:10 |
bshum |
Unable to retrieve sessions, unable to create sessions |
| 11:13 |
bshum |
Meh |
| 11:13 |
bshum |
No, it's just an undefined error |
| 11:13 |
bshum |
But yeah, not promising |
| 11:15 |
Dyrcona |
Well, I have 4 books that came in delivery this morning that I can use for a test. |
| 11:18 |
bshum |
014-07-14 11:17:39 trusty gateway: [cgi:error] [pid 4845] [client 10.129.129.3:40991] script not found or unable to stat: /usr/lib/cgi-bin/offline |
| 11:18 |
|
kbeswick joined #evergreen |
| 11:18 |
bshum |
Oops, slightly less/more than I was going to paste. |
| 11:22 |
Dyrcona |
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ |
| 11:23 |
Dyrcona |
jeff: tried "WITH" queries and UNION? |
| 11:24 |
bshum |
Dyrcona: Yep, I see that now. |
| 11:24 |
Dyrcona |
I would try disabling it and testing, but I started a database reload, so I'll have to wait an hour or two. |
| 11:25 |
bshum |
Dyrcona: Disabling meaning commenting out that script alias portion? |
| 11:25 |
bshum |
It looks like it gets turned on when we turn on CGI? |
| 11:25 |
* bshum |
is going to do some reading |
| 11:33 |
bshum |
Yeah, it was. This is new to me. |
| 11:33 |
Dyrcona |
Yep. |
| 11:35 |
Dyrcona |
bshum: You want to add a commit to run a2disconf to my namevirtualhost branch, or do you want it separate? |
| 11:35 |
csharp |
<pedantry>Ubuntu LTS releases are synced with Debian testing, not sid</pedantry> so... |
| 11:35 |
csharp |
@blame jessie |
| 11:35 |
pinesol_green |
csharp: jessie stole csharp's ice cream! |
| 11:35 |
bshum |
Dyrcona: Might as well just make that the "fix Ubuntu 14.04 apache nonsense" branch :) |
| 11:35 |
* Dyrcona |
stands corrected by csharp. |
| 11:38 |
bshum |
for m in $(DEB_APACHE_DISCONF); do a2disconf $$m; done; |
| 11:38 |
mrpeters |
have they tagged 2.6.2 yet? or still just the release uploaded to the site |
| 11:39 |
mrpeters |
s/they/we/ |
| 11:39 |
bshum |
And then setup new params for that |
| 11:39 |
bshum |
mrpeters: I know dbwells uploaded previews and mceraso tested them last week. But I don't know if/when they'll be moved to official. Probably just a minor thing to push all that through. |
| 11:39 |
bshum |
He's probably waiting for the right moment to strike |
| 11:40 |
Dyrcona |
bshum: Why don't you add that to my lp 1341013 branch and put it in collab? |
| 11:40 |
pinesol_green |
Launchpad bug 1341013 in Evergreen "NameVirtualHost deprecated in Apache 2.4" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1341013 |
| 11:40 |
mrpeters |
yeah, we use the tag from Git to build our debs |
| 11:41 |
* Dyrcona |
figures out a configuration to auto-build a trusty VM. |
| 11:47 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/bshum/lp1341013_apache24_tweak |
| 11:47 |
bshum |
Dyrcona: Signed off on your commit and added the changes I think we'll need for mod CGI |
| 11:48 |
Dyrcona |
bshum: Cool. I will add your branch to my dev branch and build a test vm first thing after lunch. |
| 12:05 |
|
gsams joined #evergreen |
| 12:11 |
|
b_bonner_ joined #evergreen |
| 12:15 |
|
hbrennan joined #evergreen |
| 12:46 |
csharp |
yeah - that includes us :-/ |
| 12:47 |
csharp |
same with open-ils.auth_proxy - should be a module |
| 12:47 |
dbs |
isn't it a module? |
| 12:48 |
Dyrcona |
I find the reason for the stripe failure to be humorous: The tests are broken by later versions of Perl. The module itself, still works. |
| 12:48 |
csharp |
dbs: I was told a while back that it was effectively non-disable-able |
| 12:48 |
csharp |
so we live with the constant log errors that look just like errors we would actually care about ;-) |
| 12:49 |
dbs |
csharp: oh, maybe from the TPAC side of things? |
| 16:36 |
bshum |
I wonder if that's SQL schenanigans more than bug in the staff client. |
| 16:36 |
bshum |
But I don't know what's being referred to specifically. |
| 16:38 |
|
kbeswick joined #evergreen |
| 16:42 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:43 |
bshum |
Huh |
| 16:43 |
phasefx |
psql:950.data.seed-values.sql:5019: ERROR: VALUES lists must all be the same length |
| 16:43 |
phasefx |
LINE 2124: ,('circ.use_lost_paid_copy_status', |
| 16:45 |
jeff |
tests++ |
| 16:52 |
Dyrcona |
Actually, I can fix that right quick. |
| 16:52 |
Dyrcona |
It's missing a ", null" at the end of the arguments. |
| 16:55 |
Dyrcona |
Any one have a problem with me pushing it? |
| 03:13 |
|
dreuther joined #evergreen |
| 04:57 |
|
mtate joined #evergreen |
| 05:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:44 |
|
b_bonner joined #evergreen |
| 06:44 |
|
mnsri joined #evergreen |
| 06:45 |
|
mtcarlson_away joined #evergreen |
| 07:48 |
|
jboyer-home joined #evergreen |
| 08:09 |
|
rjackson-isl joined #evergreen |
| 08:12 |
|
akilsdonk joined #evergreen |
| 08:13 |
jboyer-isl |
dbs++ ; Vacuum Analyze took care of the search timeouts on our migration testing server. Apparently when testing it’s no longer optional for us. Thanks! |
| 08:23 |
rjackson-isl |
dbs++ and jboyer-isl++ - now the next set of libraries migrating to EI can review initial data pull! :-) |
| 08:28 |
|
mrpeters joined #evergreen |
| 08:36 |
|
tspindler joined #evergreen |
| 15:21 |
* bshum |
is trying out the make_release dance for the first time |
| 15:21 |
bshum |
Entertaining! |
| 15:29 |
jeffdavis |
gmcharlt++ |
| 15:36 |
bshum |
Oh, yay, i18n dance at last |
| 15:36 |
bshum |
Figuring out all the dependencies was "fun" :) |
| 15:40 |
bshum |
So yeah, once the environment is setup right, this does seem easier than I recalled from our 2.0 days. |
| 15:46 |
|
mrpeters left #evergreen |
| 15:50 |
|
RoganH joined #evergreen |
| 15:56 |
bshum |
RoganH: Thanks for signing off on https://bugs.launchpad.net/evergreen/+bug/1198475 ; I'm planning to get a little more testing on that myself and then push it up to master next week |
| 15:56 |
pinesol_green |
Launchpad bug 1198475 in Evergreen "Support for Lost and Paid Status" (affected: 3, heat: 16) [Wishlist,Confirmed] |
| 15:56 |
RoganH |
bshum: I've been a bad tester but at least I got one in. I'm hoping to get another couple in tomorrow if it's quiet at work. |
| 15:56 |
bshum |
Unless someone else gets there first. |
| 16:16 |
tsbere |
jeff: I know of at least one SIP2 server app that prefers things in alphabetic order. <_< |
| 16:16 |
eeevil |
tsbere: which, as I'm sure you know, is /not/ the same as spec order for some messages :) |
| 16:16 |
jeff |
tsbere: which server? |
| 16:17 |
tsbere |
eeevil: For added fun, it blows up on any field it doesn't understand. |
| 16:17 |
tsbere |
jeff: Luckily it was just a test server for a PC reservation system, though the docs implied it was ripped out of an ILS and given a different database backend... |
| 16:17 |
eeevil |
tsbere: you have a strange sense of "fun", sir... ;) |
| 16:17 |
jeff |
@decide Standard Interchange Protocol or Binary Language of Moisture Vaporators |
| 16:17 |
pinesol_green |
jeff: have you tried local mean solar time for the named city as the reference point? |
| 16:33 |
jeff |
tsbere: does that take care of re-establishing a tunnel, or starting it automatically? The fact that putty-tunnel-manager claims to use plink makes me wonder if plink has those abilities on its own. |
| 16:33 |
bshum |
That's why I didn't catch it till now |
| 16:34 |
tsbere |
jeff: I wrapped it in a cmd file with a goto and helped libraries drop that into task scheduler. |
| 16:35 |
bshum |
Reverting that commit on my test server allows me to complete the make_release dance and get clients built. |
| 16:35 |
jeff |
tsbere: got it. thanks. |
| 16:37 |
jeff |
ah, and there's also http://www.bitvise.com/tunnelier |
| 16:39 |
jeff |
as well as MyEnTunnel and some other options referenced here: http://superuser.com/q/235395/9465 |
| 11:25 |
bshum |
If they're electronic records, then I'm even more concerned about how interconnected they might be. |
| 11:25 |
bshum |
Depending on what kind |
| 11:27 |
Dyrcona |
Then, you'll want to vaccuum full analyze the tables and put the rules and triggers back in place. |
| 11:28 |
bshum |
Well, in any case, just be careful how you identify which bibs to delete. And do it all on a test server a couple of times first. People have been known in the past to have removed their protections and then deleted the wrong bibs to dangerous consequences... |
| 11:28 |
Dyrcona |
Yep, that, too. |
| 11:29 |
bshum |
There's a decent number of instances in our IRC logs for those unhappy stories. |
| 11:31 |
Dyrcona |
IOW, unless you're going to get a major benefit from it, such as cutting your database by a significant %, I wouldn't bother. |
| 11:36 |
Dyrcona |
Deleted records also have the record status field set to 'd' if not already. |
| 11:36 |
Dyrcona |
However, if you're eliminating that many records. It might be worth it to try. It just won't be easy. |
| 11:37 |
asimon |
Dyrcona: TY |
| 11:39 |
Dyrcona |
asimon: Do you have a test/training database you can test it on? |
| 11:39 |
asimon |
Dyrcona: I'll use COPY (SELECT marc FROM biblio.record_entry WHERE deleted = 't') to a file and then convert the XML to MARC with yaz-marcdump. |
| 11:40 |
Dyrcona |
asimon: That sounds like it should work, thought it should already be xml. |
| 11:41 |
asimon |
Dyrcona: Yes, but I want MARC, not XMLMARC. |
| 12:07 |
jboyer-isl |
Self-signed, and I'm tunneling directly into the same LAN with an otherwise completely open machine. |
| 12:07 |
jeff |
tunneling how? you mentioned "direct connection" earlier. |
| 12:08 |
jboyer-isl |
Direct connection just means no load balancer, poor choice of words. The IP the name resolves to is the one running Apache and OpenSRF. |
| 12:10 |
mceraso |
dbwells: Just finished testing the maintanence release for 2.6.2 using Ubuntu LTS 12.04. It works well :) |
| 12:10 |
jboyer-isl |
Tunneled over SSH, though I'm testing a "normal" connection now also. |
| 12:11 |
jboyer-isl |
(It has a public IP) |
| 12:11 |
Dyrcona |
Added content? Could that be using https and the vendor doesn't support it? |
| 12:13 |
jboyer-isl |
I guess it's possible, I'll check. |
| 12:14 |
Dyrcona |
I've never seen searches be slow just over https, so I'm grasping. |
| 12:21 |
jboyer-isl |
Disabled added content to no effect, now we try the ages-old method of restart it and see. |
| 12:28 |
dbs |
jboyer-isl: tunneled over ssh with compression of the ssh tunnel enabled? |
| 12:28 |
dbs |
compression + encryption still shouldn't be that slow though. |
| 12:29 |
jboyer-isl |
dbs: Not that I'm aware of. I'm testing over a regular connection now just to avoid the possibility that it's tunnel related. |
| 12:29 |
jeff |
At the risk of sounding like SAPS, this could be an MTU issue. |
| 12:30 |
jeff |
It would be interesting to see if an HTTPS request for a small file (such as robots.txt) and an HTTPS request for a larger (ten meg or so) are any different from each other, and are any different from the searches. |
| 12:32 |
jboyer-isl |
Oh. It appears to be at least partially related to the hour+ long bib searches that were hung up on 4 of the postgres backends that serve that installation. I cleared that out and now it's returning results in the staff client again. |
| 14:35 |
dbs |
Did anyone drop or recreate indexes recently? |
| 14:35 |
dbs |
All sorts of potential problems. |
| 14:35 |
Dyrcona |
csharp++ bshum++ |
| 14:36 |
jboyer-isl |
The data is identical to production, we did a dump/restore, and ran a test migration. It's every search. |
| 14:37 |
jboyer-isl |
Osrf/Eg versions are also the same. |
| 14:38 |
Dyrcona |
Any problems with the restore? |
| 14:42 |
jboyer-isl |
The usual (rebuild those 2 authority indexes and the auditor schema since I didn't dump it) |
| 14:44 |
bshum |
remingtron++ # taking a look at bug 1210161 and it looks good. Testing the upgrade script and then I'll probably push that on in. |
| 14:44 |
pinesol_green |
Launchpad bug 1210161 in Evergreen "TPAC "my list" still referred to as "bookbag" in some places" (affected: 3, heat: 16) [Medium,Confirmed] https://launchpad.net/bugs/1210161 |
| 14:46 |
dbs |
jboyer-isl: oh, test migration == upgrade to newer version? |
| 14:46 |
jboyer-isl |
Dyrcona: Ah, and apparently all of config.z3950_index_field_map is missing. Is that table more important than it's z3950 prefix would suggest? |
| 14:47 |
jboyer-isl |
dbs: Nope, just adding a new lib. I've got another server for upgrade testing, it went great so far as I can tell though I don't have a client built for it yet. |
| 14:47 |
Dyrcona |
No, it isn't but I've had that happen seemingly randomly before. |
| 14:48 |
dbs |
ANALYZE run after the restore? |
| 14:48 |
bshum |
Calling 0884 |
| 16:57 |
jeffdavis |
it's aliiiiiiiive |
| 16:57 |
jeffdavis |
Someday I should get around to making that list of all the things I need to get around to doing. |
| 16:57 |
jeffdavis |
Finishing old half-finished bugfixes and new features, for example. |
| 17:01 |
bshum |
Hehe |
| 17:01 |
bshum |
eeevil++ # debian defender ;) |
| 17:01 |
bshum |
That's a fair clarification, I didn't quite word my part of that correctly. |
| 17:01 |
bshum |
I should have said we only officially test Ubuntu with that particular version. |
| 17:01 |
bshum |
But others are done as well. |
| 17:03 |
eeevil |
bshum: :) |
| 17:08 |
* dbs |
wades in with a hearty encouragement to use Fedora |
| 17:08 |
eeevil |
hrm... we need to get a debian 7 buildbot host going, and upgrade the live tester ... |
| 17:09 |
eeevil |
dbs: at least that still has a buildbot slave :( |
| 17:09 |
bshum |
dbs++ |
| 17:13 |
|
mmorgan left #evergreen |
| 17:20 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:29 |
bshum |
dbs: Ooh, just found http://stuff.coffeecode.net/2014/lld_preconference/search_engine_cse/ ... I will play through this one :) |
| 17:33 |
|
akilsdonk_ joined #evergreen |
| 17:40 |
sseng |
Question: anyone encountered this error when running osrf_control -l --stop-all? error is: Can't kill a non-numeric process ID at /openils/bin/osrf_control line 149. |
| 17:48 |
jeffdavis |
i.e. does one or more of those files contain an error msg or something, rather than a process id? |
| 17:49 |
Bmagic |
sseng: I have seen that error but it doesn't seem to matter for us |
| 17:50 |
sseng |
jeffdavis: Bmagic : unfortunately i ran the osrf_control with the --kill-with-fire option.... so no longer have access to those .pids with the errors....the good news running the usual --stop_all no longer produce that error! |
| 17:56 |
jeffdavis |
Seems likely that file perms/ownership were wrong on a pid file or the directory. osrf_control just does @pids = `cat $pid_file`; if cat gives an error like "permission denied" then @pids will contain the test of the error message. |
| 17:56 |
jeffdavis |
Anyway, glad it's working now. |
| 17:56 |
jeffdavis |
s/test/text/ |
| 17:57 |
sseng |
jeffdavis: yep, thanks a bunch, will look out for those in future! |
| 18:36 |
|
sseng joined #evergreen |
| 18:36 |
|
ktomita joined #evergreen |
| 09:12 |
krvmga |
csharp: yes, network issues ruled out |
| 09:14 |
csharp |
when I create a patron and save, it's about 5 seconds turnaround between clicking save and when the new page is fully loaded |
| 09:14 |
csharp |
we have 3 stat cats if that makes a difference |
| 09:15 |
krvmga |
csharp: just been testing loading/reloading; the quickest i can get the page is 7 seconds |
| 09:16 |
csharp |
krvmga: how many stat cats? and how many entries per stat cat? I can create a few and see if that adds to load time |
| 09:16 |
csharp |
rough estimate's fine |
| 09:17 |
krvmga |
csharp: two dozen |
| 12:15 |
gmcharlt |
jeff: in any event, the Win8.1 box in quetstion was indeed creating it locally |
| 12:15 |
bshum |
gmcharlt: Done. |
| 12:16 |
gmcharlt |
jeff: thanks for the catch |
| 12:17 |
jeff |
you're welcome! without a win8.1 box handy to test on, I can't say if it mattered or not. :-) |
| 12:17 |
jeff |
(with windows being so spotty with regard to file case) |
| 12:18 |
pinesol_green |
[evergreen|Galen Charlton] LP#1339767: follow-up: Thumbs.db, not Thumbs.DB - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=694d4fa> |
| 12:20 |
Dyrcona |
heh. |
| 12:24 |
jcamins |
jeff: I didn't know there was a global gitignore. |
| 13:42 |
bshum |
tsbere: Aha, okay, maybe that's what I'll check |
| 13:42 |
jeff |
the sip user will need the required override permission. |
| 13:43 |
tsbere |
bshum: Treat the SIP users as staff client users for the most part. Thus any permission a staff user might need to accomplish something SIP will likely also need. |
| 13:45 |
bshum |
tsbere++ jeff++ # thanks guys, we'll test and hopefully that'll be the end of that question |
| 13:58 |
gmcharlt |
jeff: no objection either |
| 14:30 |
|
ningalls joined #evergreen |
| 15:00 |
csharp |
bshum: I created a signoff branch for my ubuntu 14.04 makefile updates -FYI |
| 15:01 |
csharp |
see bug 1315531 for details |
| 15:01 |
pinesol_green |
Launchpad bug 1315531 in Evergreen "Need Ubuntu 14.04 Trusty Makefile target for Evergreen" (affected: 1, heat: 6) [Wishlist,Confirmed] https://launchpad.net/bugs/1315531 |
| 15:01 |
bshum |
csharp: Oh excellent. I'll take a look over that too |
| 15:01 |
csharp |
thanks - I was just trying to update my test box to current master, but couldn't because those commits aren't in yet ;-) |
| 15:05 |
|
ldw joined #evergreen |
| 15:06 |
jboyer-isl |
some quick followup for any interested parties: I've fed the same production 1-hour pg log through pgbadger and pgfouine and there's no comparison. pgfouine took 14 minutes to parse it, missed over 2000 queries, and doesn't give nearly the information pgbadger can. |
| 15:07 |
jboyer-isl |
It doesn't hurt that pgfouine is also hard to look at and pgbadger looks rather nice. |
| 15:23 |
bshum |
So if it was me, I would disable autosuggest, then tweak the template like I did in the file to re-enable dojo. |
| 15:23 |
bshum |
At least till we get deeper with code cleanup / removal / rewriting |
| 15:25 |
jboyer-isl |
bshum: ah, that does look more like it. If we end up turning off autosuggest I'll definitely be doing that. |
| 15:25 |
bshum |
In our case, dojo is turned on because of other config choices we made |
| 15:25 |
bshum |
Like using Google Books |
| 15:25 |
bshum |
Or Novelist |
| 15:26 |
bshum |
So I didn't catch that issue in my original testing when we wrote the patch to disable autosuggest by default. |
| 15:46 |
|
kbeswick joined #evergreen |
| 15:53 |
|
ldw joined #evergreen |
| 16:02 |
|
dMiller_ joined #evergreen |
| 16:40 |
|
rangi joined #evergreen |
| 16:55 |
Bmagic |
jeff: The error I was getting turned out to be due to the required SSL redirect when accessing /reporter. PP was configured to talk to the app servers on port 80 in the backend no matter what. They 301 redirected the clients to talk to port 443. PP answered, and talked to the app servers on 80 again. rinse and repeat |
| 16:56 |
jeff |
redirect loop. |
| 17:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
|
kbeswick joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:41 |
pinesol_green |
[evergreen|Yamil Suarez] Documentation: added AsciiDoc version of old SIP docs from EG 1.6/2.0 docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df806b4> |
| 17:41 |
pinesol_green |
[evergreen|Yamil Suarez] Documentation: updated some SIP content - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5f75319> |
| 17:42 |
bshum |
yboston++ gmcharlt++ |
| 17:42 |
gmcharlt |
yboston++ bshum++ |
| 19:28 |
|
hbrennan joined #evergreen |
| 03:09 |
|
gsams joined #evergreen |
| 04:14 |
|
dcook joined #evergreen |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:01 |
|
jboyer-home joined #evergreen |
| 08:06 |
|
rjackson-isl joined #evergreen |
| 08:21 |
|
dkyle left #evergreen |
| 10:16 |
|
dkyle joined #evergreen |
| 10:39 |
* dbs |
ponders adding a robots.txt.example like http://laurentian.concat.ca/robots.txt to the default install (.example to avoid blowing away existing ones) |
| 10:41 |
Dyrcona |
Ours is a sledgehammer: Disallow: / |
| 10:42 |
phasefx |
btw, that qatests failure, seems like a race condition: http://testing.evergreen-ils.org/~live/test.46.html Unable to retrieve settings from settings server, retrying.. and it looks like it succeeds on the retry |
| 10:42 |
Dyrcona |
phasefx: fwiw, we see a similar message with action triggers from time to time. |
| 10:43 |
Dyrcona |
except it reports, "going to sleep" |
| 10:43 |
dbs |
Dyrcona: huh. given a sitemap like https://bugs.launchpad.net/evergreen/+bug/1330784 and a decent robots.txt, wouldn't you want search engines to index your bib records and holdings? |
| 15:31 |
dbwells |
bshum: My best recollection is that I kept the code as targetted as possible in selecting eligible copies to reduce risk of bugs causing damage. I could imagine it being expanded to include other statuses, probably as a waterfall (e.g. In process, first, then On-order if no In process copies exist). |
| 15:34 |
dbwells |
I'm also not understanding an acq workflow where the receive step gets skipped, but I'm probably not being creative enough :) |
| 15:35 |
dbwells |
If your workflow is such that you can use copy ID as an overlay, I'd say that's much better overall. |
| 15:39 |
bshum |
Yeah I think that might be the way to go in this case. Course the fun part is figuring out the PO JEDI template entries. |
| 15:53 |
bshum |
Strange |
| 15:53 |
bshum |
copy_id => lid.id, # for INC_COPY_ID |
| 15:53 |
bshum |
So it sets the copy_id to the lineitem ID in the EDI template if we include copy data |
| 15:54 |
bshum |
But the label for the entry is copy_id |
| 15:54 |
bshum |
That's weird looking. |
| 15:54 |
bshum |
Maybe this is a weird interaction with whichever vendor was first testing the EDI GIR stuff? |
| 15:56 |
bshum |
Or maybe something to do with electronic invoicing? |
| 15:56 |
bshum |
Sigh... |
| 15:56 |
bshum |
@hate acq |
| 15:56 |
pinesol_green |
bshum: But bshum already hates acq! |
| 15:57 |
bshum |
Hmm |
| 15:58 |
bshum |
Or we add a part to the EDI message for eg_copy_id to pass the copy ID direct |
| 16:51 |
|
patrick left #evergreen |
| 16:54 |
|
pgardella joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 17:23 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:28 |
|
gsams joined #evergreen |
| 19:02 |
|
vlewis_ 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> |
| 05:09 |
|
berickm joined #evergreen |
| 07:38 |
bshum |
@later tell eeevil Hmm, wondering on the performance speed of record_attr_flat when there ends up being lots of uncontrolled_record_attr_value to look for. I'm getting truly terrible query performance on things like "SELECT COUNT(*) FROM metabib.record_attr_flat WHERE attr = 'oclc'" (our custom definition for tag 001) vs. looking for something that is in vlist like 'search_format' |
| 07:38 |
pinesol_green |
bshum: The operation succeeded. |
| 07:47 |
bshum |
My end goal was to figure out how many bibs still need to be reingested with our custom record attribute. Generally counting from uncontrolled, I can quickly find out, but I couldn't use that to narrow exact bib IDs of what remains. |
| 07:48 |
bshum |
We've had to do them in small spurts cause it has been taking terribly long to reingest the one field. |
| 09:28 |
* dbs |
overlooked the "k" in those measurements at first |
| 09:28 |
eeevil |
bshum: I don't want to sound flippant, but that's not a use case that the software itself cares about. we can't make every single query fast, there will always be ones that could be faster if we changed the shape of the data, but that would in turn slow down some other query. the question "how many records don't have this uncontrolled attribute, globally" is not something that needs to be fast, because it's not something we'd put into, say, a |
| 09:28 |
eeevil |
search result or a checkout api call |
| 09:30 |
eeevil |
bshum: that query (and ones like it) are at the opposite end of the spectrum from how that view is used by the software and how they're designed to be used |
| 09:36 |
eeevil |
bshum: now, if you just wanted to know the count, you could likely make things faster by restructuring your query to build an array of the ids of the values from uncontrolled_record_attr that are used as oclc number, and test record_attr_vlist with the overlaps operator. or, a different tactic is to just join record_attr_vlist on uncon_record_attr with (vlist @> intset(un_rec_attr.id) and un_rec_attr.attr=$oclc_attr_def_id) ... that would be |
| 09:36 |
eeevil |
doing what the view does for exactly the one attr |
| 09:44 |
eeevil |
think of it this way, everything that lives in the metabib schema has a very targetted purpose that is /not/ storing data. that schema is, by design, a dumping ground for specific denormalizations of central, authoritative data, and each table and view is intentionally shaped so that its primary purpose (search record attributes, backing tsearch queries, turn one record's attribute-int-arrays back into something a human can use) is as fast as |
| 09:44 |
eeevil |
possible. all other purposes (that is, "how X performs in arbitrary queries") are, at best, secondary concerns, because if we need some other purpose or use case to be fast we can trade a little more disk space for that speed |
| 09:45 |
eeevil |
and, the use case for record_attr_flat is "give me the attribute names and values for this record (or some small set of records)" |
| 09:46 |
* eeevil |
disappears in a puff of uncontrolled smoke |
| 10:45 |
bshum |
eeevil++ |
| 10:46 |
bshum |
Thanks for the rundown. I understand what you're saying here. And appreciate the suggestion on ways of answering the question via database approaches |
| 10:47 |
bshum |
I'll tinker more with it once we finish moving our servers. |
| 14:42 |
remingtron |
berick: thanks. we're hoping to start drafting docs for the web staff UIs as development continues |
| 14:43 |
remingtron |
any comments on which UIs are most "stable" at this point? |
| 14:43 |
remingtron |
or ones to wait on? |
| 14:43 |
berick |
remingtron: this is the best general source -> http://evergreen-ils.org/dokuwiki/doku.php?id=dev:browser_staff:dev_sprints:1 -- however, given that none of these have been thorougly tested, "stable" is a relative term |
| 14:44 |
berick |
anything marked through is feature complete within the realm of the current "sprint" -- that is, there are missing features, but they will be done later |
| 14:46 |
berick |
documenting basic stuff, like login, the splash page, the nav bar, etc. is a good start. then moving on to simpler interfaces -- ones that are less likely to change -- is a good next step |
| 14:47 |
berick |
having said that, though, I have a hard time thinking of tnese UIS will change *drastically* regardless of bugs or missing features |
| 14:47 |
berick |
since they all mimic the XUL client very closely |
| 14:48 |
berick |
hmm, smells like hurricane outside |
| 14:48 |
csharp |
berick: are you in the storm's path? |
| 14:49 |
remingtron |
berick: thanks for the advice, feel free to run and board up the windows if needed |
| 14:49 |
berick |
csharp: just the outer swirly bits. we'll get rain and modest wind. |
| 15:19 |
csharp |
my patch http://git.evergreen-ils.org/?p=evergreen/pines.git;a=blobdiff;f=Open-ILS/src/templates/opac/parts/record/copy_table.tt2;h=c0fbbd2c98b08ca26cd9537b42e21584e464dc80;hp=c29a0171f94c3f4e526dae5cfd651a65d5de9d1d;hb=af5b18ef988dfe2b21f536dd963737a030801899;hpb=c5ee6b43f566ea65b3361cc8a4056edc1c32bbd8 |
| 15:19 |
dbs |
So it could be a bug in RDFa Play |
| 15:19 |
csharp |
oops - dead link |
| 15:19 |
bshum |
dbs: My quick googling finds me the LP bug where we chatted about the testing tool and its quirks :) |
| 15:19 |
csharp |
http://git.evergreen-ils.org/?p=evergreen/pines.git;a=commit;h=af5b18ef988dfe2b21f536dd963737a030801899 - this works |
| 15:19 |
csharp |
(for the logs) |
| 15:20 |
dbs |
bshum: Well, there are different testing tools, each with their own quirks |
| 15:20 |
bshum |
No doubt. |
| 15:22 |
dbs |
yeah, nevermind. As weird as that markup is (really? a div for hold counts that wraps the copy table?) that's not the issue with RDFa Play |
| 15:22 |
dbs |
RDFa Play gets sulky about circular references and refuses to play in that case. And we have one of those in standard markup. |
| 16:29 |
jeff |
there may be permissions required and there's certainly at least one org unit setting that you'll want to verify for this use case -- reset request time on hold uncancellation or somesuch. |
| 16:30 |
|
tspindler left #evergreen |
| 16:50 |
|
ningalls joined #evergreen |
| 17:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
yboston |
@marc 024 |
| 17:16 |
pinesol_green |
yboston: A standard number or code published on an item which cannot be accommodated in another field (e.g., field 020 (International Standard Book Number), 022 (International Standard Serial Number) , and 027 (Standard Technical Report Number)). The type of standard number or code is identified in the first indicator position or in subfield $2 (Source of number or code). (Repeatable) [a,c,d,z,2,6,8] |
| 17:19 |
hopkinsju |
Thanks jeff++ |
| 02:49 |
|
DPearl joined #evergreen |
| 05:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:02 |
|
rjackson-isl joined #evergreen |
| 08:13 |
|
collum joined #evergreen |
| 08:15 |
|
krvmga joined #evergreen |
| 14:39 |
kmlussier |
Under using the OPAC? |
| 14:39 |
remingtron |
yboston: good point, we don't want to release any docs before the web interface is released |
| 14:39 |
yboston |
I am sorry, under "using the staf client" |
| 14:39 |
kmlussier |
Ok, that sounds better. :) |
| 14:40 |
kmlussier |
I'm worried that things may still change as people offer feedback and testing begins. |
| 14:40 |
yboston |
in theory we could do it as part of an index with warnings that this is pre-release features or we can in theory create a new Git branch for syaf client documentation to be merged later? |
| 14:41 |
remingtron |
yeah, we could work in a collab branch and update things if they change |
| 14:41 |
yboston |
BTW, kbutler I see your email now |
| 14:57 |
yboston |
I can send an email to the list to slect amonst ourselves some older features to work on, hopefull we can get newcomers involved too |
| 14:58 |
remingtron |
yboston: yeah, let's focus on older features and web staff client updates now, then hopefully switch to new features as they come |
| 14:58 |
yboston |
OK |
| 14:58 |
kmlussier |
yboston: This list will give you an idea of what might be eligible for 2.7 http://bit.ly/1qyGrOx |
| 14:59 |
kmlussier |
But until the code is tested, I don't think there's any guarantee that anything will definitely make the cut. |
| 14:59 |
yboston |
thanks |
| 14:59 |
yboston |
kmlussier: yes, without testing nothing should be guranteed |
| 15:00 |
kmlussier |
So should we each commit to 1 to 3 features from the 2.5 list between now and the next meeting? |
| 15:00 |
yboston |
you read my mind |
| 15:00 |
* kmlussier |
is psychic. :) |
| 16:31 |
|
kmlussier1 joined #evergreen |
| 16:35 |
|
tspindler left #evergreen |
| 16:37 |
|
ningalls joined #evergreen |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:58 |
|
kbutler_ joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:15 |
|
kmlussier left #evergreen |
| 09:34 |
|
yboston joined #evergreen |
| 09:37 |
|
kmlussier joined #evergreen |
| 09:56 |
|
krvmga joined #evergreen |
| 09:57 |
krvmga |
when a patron is logged into the opac, is there a limit on how many items will be displayed in the Current Items Checked Out screen? |
| 09:58 |
krvmga |
a patron has told me he can only see 15 when he has over 30 checked out. i just tested it (checked out 37) and see all 37 in one screen. |
| 10:01 |
jeff |
krvmga: holds are paged at 15 now, i believe. if you have old templates, you won't have the right paging logic and you'll only be able to see 15. |
| 10:02 |
jeff |
krvmga: checked out items might be using the patron's search result preference? dunno. i haven't encountered the issue you describe, and haven't taken a moment to look at the code just now. |
| 10:03 |
krvmga |
i did my test with a dummy user. search results set to 10 per page. |
| 10:04 |
kmlussier |
krvmga: Did you verify that this patron does indeed have 30+ items checked out? |
| 10:05 |
krvmga |
kmlussier: yes, he currently has 32 out |
| 10:06 |
jeff |
mosh++ |
| 10:07 |
|
tspindler left #evergreen |
| 10:09 |
kmlussier |
krvmga: If you can see 30+ on the current items checked out screen and another user can't, my first guess would be differences in the files on your brick heads. Or maybe the patron is looking at another screen, not the current items checked out screen. |
| 10:09 |
kmlussier |
For example, I think the "my lists" screen used to limit the user to 15 titles. Or maybe it was 10. |
| 10:12 |
krvmga |
kmlussier: i just tested the display from all five brickheads. the 37 items in my dummy account show up on all of them. |
| 10:12 |
krvmga |
kmlussier: i think it was 10 |
| 10:13 |
* jeff |
nods |
| 10:13 |
krvmga |
this is exactly what the patron wrote to me: |
| 10:13 |
krvmga |
I regularly have more than 30 items checked out at a time, as well as many requests. In order to navigate to the second page of my Checked Out items (items number 16 and above), I have to go to the second page of items On Hold; then the second page of my items Checked Out appears. But if I have over 30 items checked out, I cannot see more than the first 30; the final 6 of today's Checked Out items do not display. If after look |
| 11:01 |
|
krvmga joined #evergreen |
| 11:03 |
kmlussier |
krvmga: I think I may have found something. |
| 11:03 |
kmlussier |
krvmga: If you start off on the second page of holds, and then clicked "Checked Out" in the patron dashboard, the paging linnks will persist. |
| 11:08 |
krvmga |
yes, i see that. i had tested only from the tabbed interface. |
| 11:08 |
kmlussier |
That is, the paging limiters. |
| 11:08 |
kmlussier |
I'll see if I can push a fix for it this afternoon. |
| 11:48 |
|
jtaylor__ joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:11 |
Bmagic |
kmlussier: I dont get that message on our production environment (2.6.1). I also do not see it on our 2.4.1 installation |
| 17:14 |
bshum |
Bmagic: I think kmlussier found the library setting she needed to enable in order to get the message to appear. For the logs, it is in the OPAC category, called "Warn patrons when adding to a temporary book list" |
| 17:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:15 |
Bmagic |
bshum: right on |
| 17:16 |
Bmagic |
I have a question as well. One of our catalogers has noticed a difference of behavior from 2.4.1 to 2.6.1. When cataloging a new marc record with fast item add, after the item details window opens, and you "Modify Copies" - the main window DOES NOT refresh and show the newly imported bib. |
| 17:22 |
Bmagic |
Looking at the code, I dont see any differences in volume_copy_editor.js or volume_editor.js between 2.4.1 and 2.6.1, any thoughts? |
