Evergreen ILS Website

IRC log for #evergreen, 2014-08-27

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:29 pinesol_green [evergreen|Liam Whalen] LP1084269, LP1050043 Expert Search Fixes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=085ab00>
00:35 pinesol_green [evergreen|Blake Henderson] LP1277556 Fast Item Add no longer opens record after copy is created - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=dcc5475>
00:39 pinesol_green [evergreen|Ben Shum] LP#1314370: Enable dojo all the time in the catalog - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=92e84a3>
00:43 pinesol_green [evergreen|Thomas Berezansky] LP#1277551: Limit simplified pull list to available copies - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ce45d4c>
00:45 pinesol_green [evergreen|Thomas Berezansky] LP#1322341: Count part holds on records - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4b88afd>
00:47 bshum Calling 0891
00:53 pinesol_green [evergreen|Chris Sharp] LP#1189556: Fix typo in URL_VERIFY permission description - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=293103d>
00:53 pinesol_green [evergreen|Ben Shum] LP#1189556: stamping upgrade script for URL_VERIFY description typo fix - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6116739>
01:09 pinesol_green [evergreen|Jason Etheridge] LP#1010027: more internal options for xul lists - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5ebaf74>
01:09 pinesol_green [evergreen|Jason Etheridge] LP#1010027: tweak patron columns in patron search interface - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b844a3c>
01:15 pinesol_green [evergreen|Elliot Voris] LP#1233757 Correct Spelling Error in Checkout Override Exception - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4f3f43e>
01:17 pinesol_green [evergreen|Bill Erickson] LP#1306675 TPAC maketext default handler - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1d1a431>
01:17 bshum Okay, time for bed.
01:18 bshum Later today, I plan to merge in the work from https://bugs.launchpad.net/evergreen/+bug/1350042
01:18 pinesol_green Launchpad bug 1350042 in Evergreen "Browser staff client / merge prep" (affected: 1, heat: 6) [Wishlist,Confirmed]
01:19 * bshum wanders off.
04:00 jboyer__isl joined #evergreen
04:00 sseng joined #evergreen
04:07 mmorgan joined #evergreen
04:08 rangi` joined #evergreen
04:08 pmurray` joined #evergreen
04:18 _bott_ joined #evergreen
04:57 wsmoak joined #evergreen
05:17 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
07:52 krvmga joined #evergreen
08:12 akilsdonk_ joined #evergreen
08:13 collum joined #evergreen
08:25 jboyer-isl joined #evergreen
08:44 ericar joined #evergreen
08:47 sarabee joined #evergreen
08:49 Dyrcona joined #evergreen
09:00 rjackson-isl joined #evergreen
09:08 * csharp puts the autoreply person on moderation
09:08 tspindler joined #evergreen
09:08 mmorgan csharp++
09:09 csharp mailman's pretty good about catching those
09:12 * tsbere dislikes that entire mail server's vacation module
09:13 Shae joined #evergreen
09:14 mdriscoll joined #evergreen
09:34 yboston joined #evergreen
09:58 bshum csharp++
09:58 krvmga i don't know if anyone's mentioned it before but Adblock can prevent the X images in Advanced Search from showing up.
09:59 krvmga it's probably picking up on the ad at the beginning of the image name adv_row_close_btn.png
09:59 krvmga we ran across this yesterday here
10:00 tsbere krvmga: There is a launchpad bug on that topic, with a branch attached that was incomplete the last time I looked at it
10:00 collum https://bugs.launchpad.net/evergreen/+bug/1190508
10:00 pinesol_green Launchpad bug 1190508 in Evergreen "Ad Block Plus EasyList blocks advanced search images" (affected: 1, heat: 6) [Medium,Confirmed] - Assigned to Dan Pearl (dpearl)
10:00 krvmga joined #evergreen
10:01 tsbere krvmga: Repeating because you disconnected right as I said it: There is a launchpad bug on that topic, with a branch attached that was incomplete the last time I looked at it
10:01 tsbere krvmga: Also collum dug up the actual bug: https://bugs.launchpad.net/evergreen/+bug/1190508
10:01 pinesol_green Launchpad bug 1190508 in Evergreen "Ad Block Plus EasyList blocks advanced search images" (affected: 1, heat: 6) [Medium,Confirmed] - Assigned to Dan Pearl (dpearl)
10:02 jwoodard joined #evergreen
10:02 krvmga tsbere: thanks. don't know what happened. my x-chat suddenly crashed.
10:02 krvmga thanks for the info
10:03 krvmga tsbere++
10:03 krvmga collum++
10:08 berick joined #evergreen
10:16 mllewellyn joined #evergreen
10:43 * tsbere runs one last set of tests before responding to questions on launchpad
10:43 tsbere Just dawned on me that some of the things I am seeing issues with I didn't test without the code in question loaded.
10:45 bshum berick: Fwiw, I had problems with the bookbags too when websockets weren't working right on my test server.  What I saw was two things:
10:45 bshum 1) if websockets was not turned on, then I got internal server errors when trying to add bibs to bookbags
10:46 bshum 2)  if websockets was not accessible (like if it was port blocked or not running properly), then I also found myself being taken to a page where it would stop/break eventually with some popup in XUL client about too many redirects or something
10:48 berick bshum: interesting... OK
10:48 berick thanks
10:48 bshum It was not clear to me that the intent was for these existing parts of the XUL client to remain working without websockets installed and functional.  Given this criteria, I'll curiously follow along and see what else we can find before we move forward.
10:49 tsbere That covers most of what I was going to say on launchpad, though I am doing a clean reinstall of things to see what the results are on a clean master. <_<
10:49 berick tsbere: gotcha
10:50 berick bshum: yeah, the hope was websockets would only be needed if you wanted to experiment w/ the browser client
10:52 * tsbere apparently deleted one thing too many and has to do a much deeper clean install than he originally intended. Whoops.
10:52 * dbs guesses he should probably open a bug for the Makefile install branch
10:52 bshum dbs: Ack, I knew I forgot to merge something last night
10:53 bshum dbs: It was on my list, I just got distracted with so many tasty "signedoff" bugs
10:55 bshum dbs: If you have time to open an LP, that'd be swell, but if you have other matters to attend to, I can finish testing and push your commit later this afternoon.
10:57 jboyer-isl left #evergreen
10:57 jboyer-isl joined #evergreen
10:59 jboyer-isl I know I missed this yesterday, but does anyone have time to look at lp 1241644 ? It's a pretty basic change that we've been running with just fine since October.
11:00 pinesol_green Launchpad bug 1241644 in Evergreen "claims_returned and longoverdue counts differ between open-ils.actor.user.checked_out(.count) and open-ils.storage.actor.user.checked_out(.count)" (affected: 2, heat: 12) [Medium,Triaged] https://launchpad.net/bugs/1241644
11:01 dbs bshum: I'm opening the bugggggggg
11:06 dbs et voila bug 1362210
11:06 pinesol_green Launchpad bug 1362210 in Evergreen "Makefile prerequisite installer should install database server prerequisites too" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1362210
11:07 mmorgan jboyer-isl: where do the different counts show up to users?
11:09 jboyer-isl It's not only the counts. A simple way to see it is if a patron has a claims returned item with 0 fines, the patron summary will show 1, but the Items out window (at the bottom, lost, claimed, etc.) will show nothing.
11:12 berick joined #evergreen
11:12 ningalls joined #evergreen
11:13 eeevil the claims-returned count is /just/ a count of how many times staff have recorded that happening
11:13 eeevil it is not a count of the circs with that fine-stop reason
11:13 eeevil just for clarification
11:16 gmcharlt_ joined #evergreen
11:18 mmorgan ok, so the claimed returned item with 0 fines has a xact_finish date? that's why it's not showing in items out?
11:18 jboyer-isl mmorgan, yes.
11:18 tsbere joined #evergreen
11:19 mmorgan eeevil: gotcha
11:19 mmorgan jboyer-isl: I'd be interested in testing this one.
11:19 mmorgan I think I can get kmlussier to load a sandbox
11:21 mmorgan but this problem have any relation to lp 793550 ? Should these claimed returned items have an xact_finish?
11:21 pinesol_green Launchpad bug 793550 in Evergreen 2.3 "xact_finish (prematurely?) set on claimed returned item if transaction balance reaches zero" (affected: 7, heat: 38) [Medium,Fix released] https://launchpad.net/bugs/793550
11:22 jboyer-isl eeevil: sure, I don't mean the number associated with an actor.usr.
11:22 DPearl1 joined #evergreen
11:22 csharp joined #evergreen
11:24 eeevil jboyer-isl: ah, you know, I did not read enough context. sorry for the noise
11:24 vlewis joined #evergreen
11:26 gmcharlt joined #evergreen
11:27 mnsri joined #evergreen
11:28 jboyer-isl mmorgan, it looks like it should be related (and our database has claims returned items with and without xact_finish set, of course) but we're running 2.5.2 and the latest claims returned with a null checkin_date and not null xact_finish is last week.
11:41 jboyer-isl Uh. The title of that bug refers to claimed returned items, but the only code referenced deals only with lost items. That is a little confusing.
11:45 eeevil bshum / berick_: the holds pull list looks easy to fix.  some "return"s got dropped in 9e8a245ff181e3b837e1e60ef60c8eb3d8b0f190 and they need to be put back. I'll push a (potential) fix branch
11:45 tsbere joined #evergreen
11:46 eeevil berick_: unless you were depending on the "last lvalue gets returned" behavior of subs there? (but that seems a bit too magical to me)
11:50 * bshum doesn't know what that commit references to, so will take eeevil's word for it :)
11:51 eeevil bshum: http://git.evergreen-ils.org/?p=worki​ng/Evergreen.git;a=commitdiff;h=9e8a2​45ff181e3b837e1e60ef60c8eb3d8b0f190
12:05 berick joined #evergreen
12:05 eeevil well, magic last lval does work in a simple test... but I'm still going to offer a branch bringing back the returns
12:09 akilsdonk joined #evergreen
12:13 jwoodard joined #evergreen
12:14 eeevil hold pull list was only changed (AFAICT) in that commit above.  The substantive change to the pre-websockets code was the lack of 'return's, so if you have a test env handy: http://git.evergreen-ils.org/?p=working/Eve​rgreen.git;a=shortlog;h=refs/heads/collab/m​iker/web-staff-phase1-squash-with-returns
12:15 eeevil note that http://paste.evergreen-ils.org/22 suggests it should work, but the sub is much more complicated than that test
12:25 bshum eeevil: Hmm, what was the problem with the holds pull list in the client?  Or is this a web client issue we're troubleshooting?
12:28 eeevil bshum: I'm sorry ... I thought you were saying (up there) that the entry point for the current one broke until you set up (and un-firewalled) websockets. did I misunderstand?
12:28 * bshum didn't notice any breakage in the XUL clients
12:28 bshum eeevil: Oh, we were talking about bookbags
12:28 eeevil oh, well... then what is the complaint about?
12:28 eeevil well, yes, but there was something about holds, I thought
12:28 bshum In the XUL client, trying to add a bib from the catalog to a bookbag (book list, list, whatever)
12:28 tsbere There was a (supposed) issue with placing holds, but I never saw that one personally.
12:28 bshum For me, I noted a quirk with placing holds via the catalog
12:29 bshum But others didn't see that
12:30 * eeevil rereads the ticket ... yeah, I'm not sure where the claim of "holds don't work" originated, then
12:31 eeevil so, either tsbere, bshum and myself all ate the same wAcKy mushrooms, or ... someone said it at some point?
12:31 * bshum blames it on the mushrooms
12:31 gmcharlt eeevil: I must have had that same meal
12:32 gmcharlt but since I was the last one to say the word "holds" to you, apologies for leading you down the (mushroom-lined) garden path
12:33 eeevil gmcharlt: I was going to ask something, but then you started fading away, leaving just a smile floating in the air
12:33 eeevil odd, that...
12:33 * gmcharlt meows
12:33 jeff Jeff: Could you provide me with details (as much detail as you can) on what authentication options [vendor] currently supports?
12:33 jeff Vendor: Please see the attached [single page summary] [...] I'd be happy to provide more information about any of our authentication methods. [...]
12:34 jeff I feel like I'm stuck inside of a TCP joke.
12:37 gmcharlt @quote add <jeff> I feel like I'm stuck inside of a TCP joke.
12:37 pinesol_green gmcharlt: The operation succeeded.  Quote #90 added.
12:40 jeff I would like details on your product.
12:41 jeff Hi! I can provide you with details on our product. Would you like details on our product?
12:41 jeff YES!
12:44 jeff I'm tempted to find out how much Nick Offerman would charge for some "custom Carl Kassell answering machine message" style audio or video of suitable variations on his Eggs and Bacon bit.
12:45 jeff ``Just give me all the ILS data you have. Wait, wait. I'm worried what you just heard was, "Give me a lot of data." What I said was, "Give me all the ILS data you have". Do you understand?''
12:46 eeevil tsbere: do you want to amend your comment on the ticket, WRT having to set up websockets to get the normal (xul staff client, normal tpac) stuff working? I think we've agree that that's not true, bshum?
12:47 bshum eeevil: I have to test further as far as turning off my websockets.  I got mine to work and didn't look back to see what wasn't working with them on.
12:48 jeff the followup is a bit more of a mouthful, though:
12:48 jeff ``Just give me all the details on your authentication options. Wait, wait. I'm worried what you just heard was, "Give me a one page summary of your authentication options." What I said was, "Give all of the details on your authentication options" Do you understand?''
12:48 bshum eeevil: aka, my testing assumption was (get websockets working), find out if anything else was broken.  Not so much, install it all, and see what's just plain broken.
12:49 bshum But I'm getting there.  Have to start a fresh VM.
12:49 gmcharlt bshum: speaking of fresh VMs -- Debian testing no longer includes libemail-send-perl
12:50 gmcharlt deprecated in favor of libemail-sender-perl
12:50 gmcharlt wheee!
12:51 bshum o.O
12:53 geoffsams joined #evergreen
12:53 eeevil bshum: gotcha. I think the low water mark for merging is "does this branch break anything if none if its new features are turned on" ... the high water mark is probably "its features work and so do the ones from outside this branch". in between those, it's a judgement call about the tradeoff between getting it out for user testing (and bug finding, of all varieties, of course!) vs pure bug-free code (regardless of whether it's in use or not) in a
12:53 eeevil release.
12:54 gmcharlt bug 1362260
12:54 pinesol_green Launchpad bug 1362260 in Evergreen "Email::Send is deprecated" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1362260
12:55 ericar joined #evergreen
12:56 eeevil IOW, and IMHO, if simple inclusion (without websockets turned on) does not break existing functionality, I think it should go in. If turning them on breaks something in either xul or web staff client, then we should loudly explain that, and say "really, not for production yet!". if it does not break anything (that we can find) then it should go in and broad testing should be encouraged. my $0.02
12:57 eeevil (and IIUC the testing so far bookbags inside the web staff client, but not in the xul or tpac modes, are having issues ... but nothing else?)
12:57 dbs Of course, determining if existing functionality is broken is tough without a comprehensive walkthrough of system features etc.
12:57 dbs See historical effort to test big XUL staff client changes and we still didn't catch everything
12:57 eeevil dbs: absolutely
12:58 dbs Maybe we could at least reuse that list of manual tests as a starting point :)
12:58 eeevil see also: acq "preview"
12:59 eeevil (granted, this is 99.9% new front-end code only, with almost no backend logic that hasn't seen real use)
13:05 jihpringle joined #evergreen
13:23 tsbere eeevil: In regards to websockets, I haven't actually gotten websockets obviously working, to fix issues in the XUL client or otherwise. I also haven't even attempted to get the web client itself working beyond "try and make websockets work because I was told they fix some of the other issues seen post-merge".
13:26 eeevil tsbere: right ... what I mean is, you claimed that simply merging the branch broke the xul client and/or the tpac (or, that's how berick_ and I both read the last part of your comment) ... but, it seems that's not true? or, it's not actually the reported issue. bshum was just saying he didn't find anything broken in the existing stuff, just in the web-client (and only one thing -- bookbags -- not 2). unless I'm still misunderstanding bshum, which
13:26 eeevil is entirely possible
13:29 tsbere eeevil: At this point I can say that with the code merged, but websockets not working, I could not add things to bookbags from the catalog interface of the xul client. Other discussion with bshum indicates that instead of being an Evergreen issue that may, in fact, be due to an OpenSRF master change that I loaded that bshum had not.
13:29 bshum We're not sure of that though.
13:29 eeevil ah! well, that's good info
13:30 tsbere eeevil: I also can't anything for "with websockets working" as I can't actually confirm I have had websockets working. In general.
13:30 ericar_ joined #evergreen
13:39 _bott_ joined #evergreen
13:40 kmlussier joined #evergreen
13:41 ericar joined #evergreen
13:55 kmlussier bshum++ #overnight merging of signedoff bugs
13:56 ericar left #evergreen
13:56 kmlussier bshum: Technically, it was August 27 in your time zone, but I fgured it was still Bug Squashing Day in someone else'
13:56 kmlussier ugh
13:56 kmlussier Anyway, I gave you credit for the signoffs in the tally. :)
13:57 tsbere kmlussier: What time did the 24 hours that comprise a "day" officially start? If we go for, say, 7 AM EST then he was good by any clock ;)
13:57 kmlussier 12 a.m. is what I was thinking.
14:03 tsbere kmlussier: Stop shooting down my attempts to justify you going past mightnight for counting bshum's work :P
14:03 * kmlussier is also going to count a patch from Terran where the git branch was created yesterday, even though it wasn't posted to LP until today.
14:04 gmcharlt +1 :)
14:05 Bmagic Which funciton in the staff client would cause a row to be deleted from action.transit_copy? Abort transit? We have a scenario where an item was transited for another library. They received it, and checked it in, the row indicating it was transited no longer exists in transit_copy. I see the row from an earlier copy of the database
14:05 kmlussier I'll include this information in my blog post, but I thought it worthy to mention that 2 of the patches bshum pushed last night came from new contributors and 1 of the new patches  came from a new contributor.
14:07 tsbere Bmagic: Aborted transits do, in fact, delete those rows, at least as far as I know. Makes it hard to see where the aborted transit was supposed to have started and ended....
14:43 jeff hrm. "obj.active_services is undefined" in Z39.50 import. This seems familiar.
14:43 bshum jeff: Yes
14:43 bshum That was a bug for awhile
14:43 bshum I thought we fixed that
14:43 jeff bug 1243280
14:43 pinesol_green Launchpad bug 1243280 in Evergreen 2.5 "'TypeError: obj.active_services is undefined' error when entering z39.50 MARC import UI" (affected: 3, heat: 16) [Medium,Fix released] https://launchpad.net/bugs/1243280
14:44 bshum That was it
15:01 pmurray joined #evergreen
15:29 ericar joined #evergreen
15:55 _bott_ joined #evergreen
16:01 ericar joined #evergreen
16:08 jeff Interesting. Seems like selecting OCLC and another Z39.50 target causes there to be zero results (presumably due to a failure related to having no credentials for OCLC). Unchecking OCLC allows the other target to return results.
16:13 ericar left #evergreen
16:23 tspindler left #evergreen
16:39 csharp does anyone use the actor.usr_merge function and if so, are there any gotchas to know about?
16:40 csharp looks pretty straightforward, but didnt' want to assume
16:48 tsbere csharp: is that what the staff client uses in the background to merge users?
16:48 csharp I guess so
16:49 csharp it's definitely thorough from my reading of the code
16:49 csharp and it takes a long time, even on SSD
16:51 buzzy joined #evergreen
16:53 tsbere csharp: Well, I assume it takes a long time when the "merge from" user(s) have a lot of circs/holds. Probably faster when they don't. ;)
17:00 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:09 mdriscoll left #evergreen
17:20 csharp yeah - we're going to be processing a large dupe file this weekend.  I guess it's just going to take a while ;-)
17:24 mmorgan left #evergreen
18:18 bshum gmcharlt++ # pointing out to me what I've been doing wrong testing holds this whole week :(
18:19 bshum I've updated bug 1350042 with my findings this afternoon.  So far I'm not seeing any further problems with my test system running OpenSRF master + Evergreen web client branch.
18:19 pinesol_green Launchpad bug 1350042 in Evergreen "Browser staff client / merge prep" (affected: 1, heat: 6) [Wishlist,Confirmed] https://launchpad.net/bugs/1350042
19:54 kmlussier joined #evergreen
20:40 pinesol_green [evergreen|Dan Scott] LP#1362210: Install PostgreSQL packages where we can - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=57f390e>
21:46 pinesol_green [evergreen|Michele Morgan] lp949101 Hold Columns for Item Status - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=39503e3>
22:00 pinesol_green [evergreen|Terran McCanna] LP#1282783: Use patron hold notification defaults for KPAC - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2f25263>
22:26 bshum Okay, completed one more fresh install of OpenSRF master and Evergreen master (as of a few minutes ago) plus the web client stuff.
22:26 bshum No breakage for hold placement or bookbag adding
22:27 bshum Didn't configure or turn on web client / websockets stuff.
22:30 jeff bshum++
22:33 bshum So far, so good.
22:57 gmcharlt dbs++ # quickest draw in the north east!
22:58 bshum dbs++ # thanks!
23:03 dbs A pleasure to serve in some small way
23:15 bshum kmlussier++ # bug wrapup blog post
23:15 bshum And general wrangling awesomeness
23:15 bshum And karma for everyone who helped, the next time I see them all
23:35 kmlussier left #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat