Evergreen ILS Website

IRC log for #evergreen, 2015-03-02

| 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
02:42 AnxiousGarlic joined #evergreen
02:42 AnxiousGarlic left #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>
07:11 graced joined #evergreen
07:39 rjackson_isl joined #evergreen
07:42 sarabee joined #evergreen
07:49 csharp Happy Bug Squashing Day, everyone!
08:00 jboyer-isl joined #evergreen
08:14 collum joined #evergreen
08:18 mrpeters joined #evergreen
08:22 akilsdonk joined #evergreen
08:26 ericar joined #evergreen
08:30 Dyrcona joined #evergreen
08:32 julialima_ joined #evergreen
08:42 mmorgan joined #evergreen
08:43 pinesol_green [evergreen|Josh Stompro] LP#1395842: fix labels for A/T environment and parameter ID fields - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=211acf9>
08:51 Newziky joined #evergreen
08:55 gmcharlt grabbing 0914
08:58 Dyrcona Maybe today is a bad day to build a new dev. branch.
08:59 Dyrcona Looks like there will be a lot of churn.
08:59 csharp we hope so!
09:00 * csharp just accidently blew away half his /home directory with 'rm -rf *'
09:00 csharp haven't made that mistake in years
09:00 Dyrcona Oops. Hope you have backups.
09:00 csharp yeah - recent enough :-/
09:01 Dyrcona I deleted the wrong files one day last week or the week before, but could recover them easily enough.
09:01 * Dyrcona keeps almost daily backups.
09:01 * csharp keeps weekly
09:01 pinesol_green [evergreen|Dan Pearl] LP#1155313: Repair generation of label_sortkey for monograph_part entries - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=aa682ee>
09:01 pinesol_green [evergreen|Dan Pearl] LP#1155313: upgrade script and pgTAP tests for monograph_part label normalization fix - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b754ad6>
09:01 pinesol_green [evergreen|Galen Charlton] LP#1155313: fix copy-and-paste-o in test case - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4e15727>
09:01 pinesol_green [evergreen|Galen Charlton] LP#1155313: pin upgrade script to 0914 - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=0c305b9>
09:01 Dyrcona Well, daily on the server, manual on the laptop, but run it every work day.
09:01 csharp but I don't really keep anything of high value on my PC
09:02 csharp I do most of my dev work on a remote server
09:02 Dyrcona I do most of my actual work on the laptop and push it to servers to run it.
09:02 Dyrcona git also doubles as a distribution mechanis.
09:02 Dyrcona mechanism
09:03 Dyrcona Oh. Good. Kernel update. Gonna have to reboot.
09:03 Dyrcona Haven't had this laptop on since Thursday.
09:03 Dyrcona BBIAB
09:05 Dyrcona joined #evergreen
09:06 Dyrcona Heard you missed me! I'm back! :)
09:07 Dyrcona So, for those who don't know: the beta and other upcoming releases are being held back until tomorrow for bug squashing day.
09:15 pinesol_green [evergreen|Galen Charlton] LP#1155313: recalculate normalized labels during upgrade - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c45c445>
09:21 yboston joined #evergreen
09:25 maryj joined #evergreen
09:34 Dyrcona Whee! Garbage in the input. Who knew? :)
09:44 kbutler joined #evergreen
09:45 csharp been using Fedora across all my computers since October, still typing 'sudo apt-get install...'
09:45 Dyrcona Heh.
09:46 * Dyrcona is putting 21,859 copies into storage.
09:46 Dyrcona Or, rather having the database do it for him. ;)
09:47 dbwells gmcharlt: I was momentarily confused by that upgrade script name.  It may need some adjustment ;)
09:47 gmcharlt gah, sorry about that
09:47 gmcharlt I'll fix that now
09:48 Dyrcona And I wait while setting org_unit visibility does its thing with copy visibility.
09:48 dbs csharp: and how are you liking it (other than muscle memory for apt-get)?
09:48 Dyrcona And didn't have to wait too long.
09:49 * dbs loves doing bulk updates via psql
09:49 Dyrcona After doing autogen.sh should I restart opensrf-settings?
09:50 Dyrcona dbs: That or via perl. :)
09:50 bshum Dyrcona: Usually I only restart apache after an autogen
09:50 gmcharlt what bshum said, although generally reloading Apache suffices for me
09:50 gmcharlt dbwells: fixed
09:50 gmcharlt dbwells++
09:51 Dyrcona Yeah, was gonna say I do the reload, but for some reason was thinking settings needed a kick, too.
09:51 dbwells gmcharlt: thank you, sir
09:53 pinesol_green [evergreen|Galen Charlton] LP#1155313: fix mangling of schema upgrade script name - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6c52b6e>
09:54 Dyrcona I don't autogen very often in production.
09:57 Dyrcona Man, I like programming and getting things done.
09:58 Dyrcona Incidentally, my daughter discovered a taste of that "power" this weekend when I showed her how to setup scripts in Nautilus to act on selected files.
09:59 Dyrcona She often seems uninterested, but I'm still hoping she'll become a real computer user.
10:04 Dyrcona Ah.. Just discovered overloaded abbrevs in some of my script names: lp for Launchpad and lp for Large Print.
10:04 Dyrcona Brain nearly exploded. ;)
10:08 Stompro joined #evergreen
10:08 jonadab Just don't get operating systems confused with oversized books.
10:08 csharp dbs: love it
10:10 abowling joined #evergreen
10:15 Dyrcona jonadab: heh.
10:16 Dyrcona That would be a fun one: a report on oversized books. ;)
10:16 jonadab Spoiler:  if you have them shelved off by themselves, they don't circulate as well as you'd want them to.
10:18 gmcharlt thinking aloud... do we need a LP tag for signifying that a pullrequest has been reviewed, may be mostly OK, but requires some more work on the part of the patch author (or a later passerby) to be ready for merging?
10:19 * gmcharlt has seen "incomplete", which canonically is more of a bug status rather than a patch status used for that
10:19 * gmcharlt has also seen (and done) removing the pullrequest tag
10:20 gmcharlt but that's seems going a bit too far unless the original patch is completely unworkable
10:20 gmcharlt reviewed-wip?
10:21 bshum gmcharlt: Personally if a submitted patch requires further work, I would mark the bug as "incomplete" and notes in the comment and removing the "pullrequest" tag.
10:22 bshum Just depends on whether you want to do the reworking, or if you're just telling the original author, hey fix X,Y,Z and we'll review and merge it.
10:23 gmcharlt I think I prefer setting the bug status back to "confirmed" (unless it's also the case that the patch reviewer cannot reproduce the bug at all)
10:24 gmcharlt given that LP's description of that status is "Cannot be verified, the reporter needs to give more info."
10:24 gmcharlt and since there's nothing saying that the patch submitter is the same person as the reporter(s), or that they work for the same organization...
10:25 bshum So in your definition is "submitter" meant to imply the person who wrote the code for the fix?
10:26 gmcharlt yes
10:26 bshum Vs. "reporter" the person who created the LP
10:26 krvmga_ joined #evergreen
10:26 gmcharlt right
10:26 bshum Then I might say that http://wiki.evergreen-ils.org/d​oku.php?id=dev:bug_wrangler:faq defines "incomplete" as a reasonable status for that situation, even if LP's description sucks for it.
10:27 bshum That said, I'm open to setting a bug's status back to "confirmed" or "triaged" in a situation like the one you describe.
10:27 bshum For revised clarity.
10:27 bshum And updating the bug status definitions appropriately.
10:27 gmcharlt bshum: er, where in "The bug report is missing important information preventing it from being fixed. The submitter should be notified to provide additional information." does it say anyting about a patch?
10:27 krvmga_ i tried re-installing EG 2.7.3 from scratch again. i ended up with the same fatal error for SpiderMonkey
10:28 krvmga_ here's the paste: http://paste.evergreen-ils.org/39
10:28 bshum gmcharlt: For my read, I view any unfinished work as "incomplete" if both the bug being incomplete or the submitted work being incomplete.  But that's just my opinion ;)
10:28 bshum So missing information is missing.
10:29 gmcharlt bshum: conflating bug status and patch status could lead to... interesting outcomes
10:29 gmcharlt for example
10:30 gmcharlt Person A reports a bug, and provides enough information for others to report it
10:30 bshum gmcharlt: I'm not disagreeing with you.  I'm just stating how we've previously worked through this.
10:30 bshum You don't need to say more, I'm convinced :)
10:30 gmcharlt Person B writes a patch, makes a pull request, but does a bad job of it...
10:30 gmcharlt OK, I'll stop working out the example :)
10:30 gmcharlt but I think you see where I'm going with it?
10:32 gmcharlt so back to my original question, slightly modified
10:33 gmcharlt do we want to do anything other than removing the pullrequest tag when a reviewer decides that more work is required, but also wants to make it clear that WIP has, in fact progressed?
10:35 bshum Well, do you want to do something extra gmcharlt?  :D
10:36 dbs change the tag to pullrequest+- ? :)
10:36 gmcharlt bshum: along the lines of adding a tag? sure; I wouldn't have started this discussion otherwise
10:36 gmcharlt and perhaps something other than "failedqa" :)
10:37 bshum I suppose in terms of precedence, it's not something we haven't done before with something like "needsreleasenote" (etc.)
10:37 gmcharlt indeed
10:37 bshum The thing I've often found more difficult than adding a tag is getting the original submitter to actually pay attention again and fix what they submitted :)
10:39 bshum So whatever tag you use, sure.  But we also need a way of informing contributors properly if they're not paying attention.  Less we continue to risk code rot on bugs :(
10:40 gmcharlt wrapping comments around rocks tossed through windows?
10:40 gmcharlt :)
10:41 gmcharlt though more seriously, particularly if a patch reviewer cares enough about an issue to actually write the follow-ups they've requested
10:41 csharp yowza - 571 "dusty" bugs
10:41 csharp anyone else looking at those?  I want to go through them without duplicating effort if possible ;-)
10:42 gmcharlt after a decent interval to allow the patch submitter to respond, the reviewer could do their own branch and put a fresh pullrequest on the bug
10:42 gmcharlt either with their follow-ups or, if it came to it, their alternative implementation
10:43 gmcharlt alas, I don't see a way in LP for patch submitters to readily hilight the correspondance on the bugs that they've submitted to
10:44 * csharp stares at bug 1207533
10:44 pinesol_green Launchpad bug 1207533 in Evergreen 2.5 "Triggered event log times out for large-data sites" (affected: 14, heat: 74) [Medium,Confirmed] https://launchpad.net/bugs/1207533
10:44 gmcharlt so, to toss a specific idea out there
10:44 gmcharlt *needspatchfollowup
10:45 Dyrcona Too long.
10:45 Dyrcona Tags should be short.
10:45 csharp tagthatisdescriptivewithoutbein​gtoolonganddoesntstraintheeyes
10:46 bshum "needslove"
10:46 bshum But more seriously
10:46 csharp patchfollowup?
10:46 gmcharlt needsrepatch? needsnewpatch?
10:46 csharp needsrepatch makes sense
10:47 goood FWIW, the postgres community uses "returned with feedback" in their "commitfest" app to signify "reviewed, needs love, but not rejected"
10:47 Bmagic just "repatch"
10:48 * gmcharlt points out that LP does have autocompletion for tags
10:48 gmcharlt feedbacked?
10:50 Dyrcona How bout dontwork
10:50 phasefx back_to_gmcharlt, back_to_bshum? :)
10:51 Dyrcona Only thing I can think of that's shorter is a four-letter synonym of excrement.
10:51 gmcharlt http://www.easypolls.net/poll.h​tml?p=54f486e6e4b0fec8f472c7c6
10:51 bshum phasefx: Well for that, I would use the "assigned to" field, but nobody ever seems to pay attention to those.
10:51 bshum I'm partial to "repatch" for simplicity.
10:52 * mmorgan likes "needsrepatch". Makes it clearer something is needed, like "needsreleasenote"
10:54 bshum Might need to bring this to the dev list or something for broader inclusion?
10:54 phasefx just an aside, folks should feel free to poke me "out of band" for a LP bug if need be
10:55 bshum And write up the whole workflow
10:55 kmlussier csharp: The "dusty" bugs link is just all of the bugs, with the oldest ones sorting to the top of the list.
10:57 kmlussier +1 to needsrepatch
10:57 Dyrcona Dude, that poll site does not look safe.
10:58 Dyrcona It says you need a Java update and if you click no it takes to what appears to be a Flash player update.
10:58 gmcharlt *sigh*
10:58 gmcharlt didn't do that to me
10:59 collum "needsrepatch" is understandable without seeing the above conversation, "repatch" not so much.
10:59 csharp kmlussier: ah - thanks
10:59 jboyer-isl Nor me. gmcharlt are you on a Mac at the moment?
10:59 Dyrcona needsrepatch or needswork work for me.
10:59 kmlussier Didn't do it for me either
10:59 gmcharlt jboyer-isl: Dyrcona: looks like the difference for me is running adblockplus
10:59 gmcharlt *grumble* *grumble*
10:59 jboyer-isl Ah.
11:00 Dyrcona I used to run adblock, but didn't bother after the reinstallation last fall.
11:00 gmcharlt anyway, I won't promulgate the poll link further, but I'll wait a bit for additional results, then this afternoon write something up for the dev mailing list
11:01 ericar_ joined #evergreen
11:07 jboyer-isl Does anyone know if oils_sql.c’s “Empty IN list” error is supposed to be “survivable?” For example, if you call open-ils.collections.user_balance_summary.generate and one of the patrons in collections has paid off all transactions, the summary dies when it hits Collections.pm line 865 (retrieving the balance of no transactions). I’ve fixed that by testing for the existence of values in the array, but if there’s
11:07 jboyer-isl deeper down that should be fixed I’d like to look into that.
11:09 jboyer-isl Though I suppose if everything dies when that happens now and empty in lists are suddenly tolerated there could be repercussions all over.
11:10 Dyrcona jboyer-isl: I didn't look, but are you certain the error comes from the C code and not the database itself?
11:12 berick it comes from the C
11:12 jboyer-isl Yes, the string returned is from oils_sql.c line 2737. It doesn’t look like the sql makes it to the db in that case.
11:12 berick IIRC, it results in a NULL response, which the caller is meant to treat as an error
11:14 jboyer-isl So it is meant to be a drop it like it’s hot, this whole request is busted type of error then. That makes it easy on me. :) I’ll write up my LP bug and put up a branch shortly.
11:18 jboyer-isl The reason I wasn’t certain is that the call in Collections.pm is made regardless of the number of transactions and immediately after the return value is checked for defined-ed-ness, so I thought at one time it may have worked as-is.
11:20 berick it's possible that it could be recovered from, but the usual approach is to be sure the list in question is non-empty before using it in a query.
11:21 jboyer-isl I prefer that anyway, fewer extra error log lines.
11:21 berick yeah
11:21 jboyer-isl thanks for the clarification.
11:28 abowling left #evergreen
11:36 mrpeters joined #evergreen
11:38 dreuther joined #evergreen
11:38 dreuther_ joined #evergreen
11:39 csharp mobius++
11:52 bshum gmcharlt: "Tag tables" per OU sounds... intriguing :)
11:53 goood Here's why we don't paper over an empty IN list by just removing the clause: imagine the query is asking for a small set of objects from a large table; if we just skip that  because user input was empty you'll get the /whole/ table.
11:53 dreuther___ joined #evergreen
11:53 dreuther__ joined #evergreen
11:56 dreuther____ joined #evergreen
11:56 dreuther_____ joined #evergreen
12:00 jihpringle joined #evergreen
12:00 chick joined #evergreen
12:00 dreuther joined #evergreen
12:00 dreuther_ joined #evergreen
12:04 jboyer-isl goood: makes sense.
12:10 Newziky joined #evergreen
12:14 gmcharlt bshum: I've pushed to the working branch a commit that outlines part of the DB schema; hopefully will give you an idea of where I'm going with the per-OU bit
12:25 kitteh_ joined #evergreen
12:29 kmlussier I'll be tracking Bug Squashing Day activity here - http://bit.ly/1EGhB4Q
12:38 * bshum finds re-reading old bugs both interesting and sad
12:48 krvmga_ joined #evergreen
12:49 krvmga_ again, working on EG 2.7.3 install, getting SpiderMonkey error; ran Build installdeps; got SpiderMonkey error; paste is here
12:49 krvmga_ http://paste.evergreen-ils.org/40
12:50 krvmga_ debian-wheezy, opensrf 2.4
12:50 bshum Hmm, https://bugs.launchpad.net/evergreen/+bug/1117658 is an oldie.  We might be able to close that bug now that work on the web client is a real thing, no longer an "experiment"?
12:50 pinesol_green Launchpad bug 1117658 in Evergreen "Experiment with more browser-based staff interfaces" (affected: 2, heat: 16) [Wishlist,Triaged]
12:52 berick krvmga_: using makefile.install?
12:52 krvmga_ berick: using these instructions: PATH=/openils/bin:$PATH ./configure --prefix=/openils --sysconfdir=/openils/conf
12:52 krvmga_ make
12:53 krvmga_ berick: i watched the make fail on SpiderMonkey and looked at the output messages; that's where the instruction to run Build installdeps was
12:54 berick krvmga_: but you previously ran "make -f Open-ILS/src/extras/Makefile.install debian-wheezy" ?
12:54 berick http://evergreen-ils.org/documentation/insta​ll/README_2_7.html#_installing_prerequisites
12:54 krvmga_ berick: yes, i've been following the instructions step by step
12:55 krvmga_ and i did that step
12:55 berick something must have failed before your error message, then, because in your error, CPAN is trying to install spidermonky
12:55 berick but we install spidermonkey manually in makefile.install
12:56 krvmga_ will it hurt if i just run that command for Makefile.install again?
12:56 berick no, it's fine to re-run makefile.install
12:57 krvmga_ berick: thx. i'm off to a meeting right now. i'll be back later to let everyone know what happened.
12:57 berick good luck
13:01 bshum berick: I'm pulling this one back out of the woods, looks like you have a partial fix for https://bugs.launchpad.net/evergreen/+bug/1269865 proposed (and there's some old feedback there)
13:01 pinesol_green Launchpad bug 1269865 in Evergreen 2.5 "ACQ user request can result in double (or quadruple) holds placement" (affected: 3, heat: 14) [Undecided,New]
13:03 bshum From i18n land, https://bugs.launchpad.net/evergreen/+bug/1095280 makes me queasy :(
13:03 pinesol_green Launchpad bug 1095280 in Evergreen "Build process doesn't get all translatable strings from templates" (affected: 1, heat: 6) [Undecided,Triaged]
13:03 bshum I think to fix that we need to have more thought into defining a new PO?
13:03 bshum For other template toolkit files
13:04 sandbergja joined #evergreen
13:06 bshum jihpringle: Hmm, this bug has been assigned to you, but unsure if you've had time to look at / test it:  https://bugs.launchpad.net/evergreen/+bug/1380709
13:06 pinesol_green Launchpad bug 1380709 in Evergreen 2.8 "invoice print amounts-per-fund uses wrong value when item price varies" (affected: 1, heat: 8) [Undecided,New]
13:07 jihpringle bshum: on my list to test today
13:07 bshum Oh, cool :)
13:07 bshum Hope you see good things on it.  Thanks!
13:09 yboston Is there a pinsol_green command to show a commit?
13:09 bshum yboston: Only if the commit is in one of the master branches being tracked by pinesol_green's git module.
13:10 bshum @git repolist
13:10 pinesol_green bshum: evergreen (Evergreen, branch: master)
13:10 pinesol_green bshum: opensrf (OpenSRF, branch: master)
13:10 pinesol_green bshum: evergreen_website (Evergreen Website, branch: master)
13:10 pinesol_green bshum: sipserver (SIPServer, branch: master)
13:10 bshum So if it's a commit in master, opensrf, or sipserver
13:10 yboston bshum: In this case I wanted to show a working commit, but would like to know the syntax for ones in EG master
13:10 bshum Err, master of Evergreen, etc.
13:11 bshum So, basically, if you give it a short snippet or the whole hash, it'll make a nice link for it.  But only the master branches of those repos.  It won't track specific trees I think, or working.
13:11 bshum So like
13:11 bshum 6c52b6e
13:11 pinesol_green [evergreen|Galen Charlton] LP#1155313: fix mangling of schema upgrade script name - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6c52b6e>
13:12 bshum That's all it takes for the bot to pick up and match the commit
13:12 bshum But like
13:12 bshum e600f9f
13:12 pinesol_green [evergreen|Galen Charlton] LP#1155313: recalculate normalized labels during upgrade - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e600f9f>
13:12 bshum Oh, I guess that works too
13:12 bshum :D
13:12 bshum Okay, so it does match the branches.
13:13 berick bshum: yeah, my branch for bug 1269865 would be a good easy win
13:13 pinesol_green Launchpad bug 1269865 in Evergreen "ACQ user request can result in double (or quadruple) holds placement" (affected: 3, heat: 14) [Medium,Confirmed] https://launchpad.net/bugs/1269865
13:13 * bshum wonders now if we added the working repo as a repolist... but somehow taught it not to announce in channel when new commits went to master.
13:14 berick it's only a partial resolution, as noted
13:15 yboston thanks for the info
13:15 yboston so here is my question
13:16 yboston Kathy took a commit from bug 1406350 and resolved a merge conflict on her working branch
13:16 pinesol_green Launchpad bug 1406350 in Evergreen "Mobile device navigation issue in OPAC Shelf Browser" (affected: 1, heat: 8) [Medium,Confirmed] https://launchpad.net/bugs/1406350
13:16 yboston The original code fix does away with the use of "<thead>" tags. The code behaves great, but just wanted to make sure there was objections to it
13:16 yboston 0f53eb85e5ad98d19874c304d55034c8b524158f
13:16 yboston http://git.evergreen-ils.org/?p=worki​ng/Evergreen.git;a=commitdiff;h=0f53e​b85e5ad98d19874c304d55034c8b524158f
13:16 ericar_ joined #evergreen
13:19 buzzy joined #evergreen
13:26 csharp Dyrcona: looking at bug 638509 - it looks like your approach was originally tied in with the overall billing overhaul you were working on, but it looks to me like the fix could stand on its own - do you agree?
13:26 pinesol_green Launchpad bug 638509 in Evergreen 2.4 "renewing lost items fails unintuitively" (affected: 7, heat: 34) [Medium,Confirmed] https://launchpad.net/bugs/638509
13:26 bshum Hmm, how should we deal with DB version upgrade bugs where those versions are no longer supported?
13:27 bshum For example like
13:27 bshum https://bugs.launchpad.net/evergreen/+bug/1205061
13:27 pinesol_green Launchpad bug 1205061 in Evergreen 2.4 "Need more "IF EXISTS" clauses in 2.3-2.4.0-upgrade-db.sql" (affected: 1, heat: 8) [Medium,Triaged]
13:27 bshum Or https://bugs.launchpad.net/evergreen/+bug/883036
13:27 pinesol_green Launchpad bug 883036 in Evergreen "2.0-2.1-upgrade.sql script: insert or update on table "org_unit_setting_type" violates foreign key constraint "org_unit_setting_type_grp_fkey"" (affected: 6, heat: 28) [Low,Confirmed]
13:27 csharp bshum: it's possible that someone out there needs to upgrade from unsupported versions
13:27 bshum True enough.
13:28 csharp (though God help 'em if theyre still on 2.0 :-))
13:28 Dyrcona csharp: That was part of a bigger group of four changes. It was one of the two changes that could stand on its own.
13:29 csharp Dyrcona: I'm going to test it and sign off.  That's something that has needed to be fixed for a long time
13:29 * Dyrcona is surprised kmlussier never signed off on it, but it fell by the wayside behind other things.
13:29 Dyrcona csharp++
13:29 kmlussier Dyrcona: There was still a bug in that one.
13:29 Dyrcona There was?
13:29 kmlussier I'll add a comment to the bug, because I think the question was raised here before.
13:30 Dyrcona Best to put things in writing. I have too much going on and even then, I don't keep up with written stuff, either.
13:31 kmlussier Dyrcona: It was related to new overdue fines being added when a site was using the setting to add new overdue fines a lost checkin. It's possible it might be resolved now that the changes were made to the fine generator.
13:31 kmlussier I'll have to dig up my notes on it.
13:31 Dyrcona Right. I don't think it was ever determined if that issue was necessarily related to these changes.
13:31 bshum berick: For that acq dupe holds bug, what I'm going to do is split issue #1 away from the rest of that bug so that we can merge #2 and close it out against a specific milestone.  We can tackle the #1 part better in the next go of things.
13:32 bshum By split, I mean open a new bug to track that issue separately.
13:33 kmlussier Looking at my notes, it looks like there were two remaining issues. I'll post it to the bug.
13:41 csharp hmm - renewing worked as expected from my point of view - it moved it from the bottom to the top window
13:41 csharp well, actually, I didn't see the override popups, but I'm logged in as admin
13:43 kmlussier csharp: https://bugs.launchpad.net/eve​rgreen/+bug/638509/comments/12
13:43 pinesol_green Launchpad bug 638509 in Evergreen 2.4 "renewing lost items fails unintuitively" (affected: 7, heat: 34) [Medium,Confirmed]
13:43 kmlussier Those were the two remaining issues I had found with that branch.
13:46 csharp actually, what I'm seeing is: Mark Item Lost, reload patron account, Renew lost item and nothing happens - no popups or reload that shows the action succeeding, but when I manually reload, the previously lost item is back in the top window with a new due date
13:46 csharp is that what's expected?
13:49 kmlussier csharp: Yes, my recollection is that is how it worked. But it's been a few months since I looked at it.
13:49 csharp ok
13:49 kmlussier I do know you need a permission to do it.
13:49 csharp I see, so I would be stopped if I were a circ staff without that perm
13:50 Dyrcona Meh. Billing's a mess. Should be refactored. All we need really are a handful of functions in a single file instead of dozens scattered over several.
13:51 Dyrcona Circulation, too, though instead of one giant hairball, it should be split up.
13:51 * csharp likes the name "Michael Ramon Barber"
13:51 csharp (one of the generated staff users in the sample dataset)
13:52 csharp also "Mary Townsend, Jr."
13:53 kmlussier csharp: I think you need the COPY_STATUS_LOST override permission to renew lost items and the COPY_CLAIMS_RETURNED override permission to do the same for claims returned items
13:56 kmlussier Looks like Evergreen won't be participating in GSoC this year. But many thanks to bshum, dbs, and Dyrcona for setting up to volunteer as mentors!
13:57 berick thanks bshum
13:57 bshum kmlussier: I'm going to check #gsoc during the meeting later to find out what we need to do better with.
13:57 kmlussier bshum: I'm guessing it would help if we had more projects. :)
13:58 kmlussier bshum: But thanks for doing that! It would be helpful to hear what they say.
13:58 bshum kmlussier: Yeah, probably, but I'll still find out what I can.
14:04 dbs alas :/
14:25 mllewellyn joined #evergreen
14:26 chick left #evergreen
14:30 Dyrcona Speaking of bills. I can't make heads or tails out of the interface.
14:30 Dyrcona I'm looking into an "in-house use" card that has 951 bills.
14:30 Dyrcona They actually all load for me.
14:31 bshum They load better in Linux than Windows.  (go figure?)
14:39 Stompro LP#754899 , can someone give me a pointer on how to set preview values for the receipt template macros?  It's marked as bitesize so it must be reasonably easy.. right?
14:40 Stompro bug 754899
14:40 pinesol_green Launchpad bug 754899 in Evergreen "receipt template editor preview busted for most templates" (affected: 3, heat: 16) [Low,Confirmed] https://launchpad.net/bugs/754899
14:44 jboyer-isl Stompro: The preview data dictionaries are in Open-ILS/xul/staff_client/server/c​irc/print_list_template_editor.js Then, print_list_template_editor.xul will need to reference the new/corrected data.
14:44 Stompro jboyer-isl thank you very much.
14:47 ericar_ joined #evergreen
14:52 Dyrcona @hate billing even MOAR!
14:52 pinesol_green Dyrcona: The operation succeeded.  Dyrcona hates billing even MOAR!.
14:57 kmlussier @whocares billing
14:57 pinesol_green kmlussier: I can't find anyone who loves or hates billing.
14:57 jboyer-isl So, talk of release notes for bug fixes (not tied to a new feature) came up some time ago, should we have a Fixes directory under docs/RELEASE_NOTES_NEXT ?
14:58 jboyer-isl kmlussier, do you remember if there was ever any consensus on that?
15:00 Dyrcona I recall the consensus being not now, maybe later, let's discuss it.
15:00 Dyrcona Since I brought the question up....
15:00 kmlussier jboyer-isl: I don't think there was anyone against the idea. I don't know if it's a case where people need to create separate release notes entry as they do with new features or if it's something the release maintainers/DIG people can pull from change logs.
15:02 jboyer-isl I wondered if most of them would be “X didn’t work/crashed before, now works as expected” which does make a most of them redundant.
15:02 * Dyrcona wonders at the best way to clear bills from a patron for items that are no longer checked out to that patron, when said patron is not a real patron, but the children's room.
15:02 Dyrcona @hate billing
15:02 pinesol_green Dyrcona: The operation succeeded.  Dyrcona hates billing.
15:02 Dyrcona :)
15:02 jboyer-isl Dyrcona: several scary DELETE FROM statements, I suspect.
15:02 bshum Given that by the time a major series is cut, the RM would have likely reorganized content into an actual RELEASE_NOTES_2_x file, my recommendation is that we have DIG, etc. work off the main file instead of having more notes added in the block that need compiling each maintenance release.
15:04 kmlussier Yes, I do agree with bshum that we it probably would be easiest to work on the existing RELEASE_NOTES_2_x file. Which means we would be working off the Change Log.
15:04 jboyer-isl Sounds good to me.
15:04 kmlussier I think the key is that the commit messages contain useful information.
15:04 bshum With new features being merged all at different times, having the single file in flux is harder than the bug fixes that get added to the main file that's already compiled.
15:04 Dyrcona jboyer-isl: combined with an update to set xact_finish.
15:04 jboyer-isl Just wanted to make sure I had relnotes this time, if needed.
15:04 Dyrcona Maybe something in Perl is called for.....
15:05 jboyer-isl Dyrcona: yes, don’t want to forget that one. We’ve seen some instances where someone got ahead of themselves and we had 600+ transactions finished with no payments. That’s an interesting display in the client.
15:06 Dyrcona Crazy thing is it looks like the patron is due for a $1,240 refund, with a current negative balance of $96.89.
15:07 Dyrcona I don't know how to read that interface though.
15:07 Dyrcona With this many bills it just looks all kinds of fubar.
15:16 dreuther__ joined #evergreen
15:16 dreuther___ joined #evergreen
15:20 dreuther_ joined #evergreen
15:20 dreuther joined #evergreen
15:42 jboyer-isl Since it is bug cleanup day, someone with Teh Powerz might want to merge 990066 and 1394989. The eldest hasn’t been touched in some time, while the newer is nearly complete from the sound of the comments.
15:43 ericar_ joined #evergreen
16:10 julialima_ left #evergreen
16:21 Dyrcona Does this ring a bell with anybody?
16:21 Dyrcona Hold was not successfully placed Problem: The item's circulation library does not fulfill holds
16:24 Dyrcona Ah. Think I found it, not sure though.
16:33 pinesol_green [evergreen|Mike Rylander] LP#1287791: Restrict authority browse to controlled subfields - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=74ddf23>
17:03 pinesol_green [evergreen|Bill Erickson] LP#1205072 A/T granularity UI sane default, honors case - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=54f7dba>
17:03 pinesol_green [evergreen|Bill Erickson] LP#1205072 A/T granularity upgrade notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2f1754a>
17:03 pinesol_green [evergreen|Josh Stompro] LP#1205072 - Assorted fixes for action trigger granularity settings - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e0d9c5c>
17:03 pinesol_green [evergreen|Remington Steed] LP#1205072: Correct and clarify the upgrade notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=9ccc056>
17:11 mmorgan left #evergreen
17:17 dcook joined #evergreen
18:28 wlayton joined #evergreen
19:06 akilsdonk joined #evergreen
20:29 akilsdonk joined #evergreen
20:37 artunit joined #evergreen
20:55 dcook joined #evergreen
21:28 pinesol_green [evergreen|Adam Bowling] LP #1406350 Mobile Device Navigation Issue Fix for Shelf Browser - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d364097>
21:28 bshum Doing a clean sweep on things that were signed off.  Thanks everyone.
21:34 pinesol_green [evergreen|Bill Erickson] LP#1287370: allow AutoGrid to persist filter state and page offset - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=39fb207>
21:34 pinesol_green [evergreen|Bill Erickson] LP#1287370: apply filter/offset persistence to the fund search page - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=05fd625>
21:34 pinesol_green [evergreen|Galen Charlton] LP#1287370: minor textual cleanup - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=06ca57f>
22:02 AnxiousGarlic joined #evergreen
22:03 AnxiousGarlic left #evergreen
22:23 bbqben joined #evergreen
22:24 wlayton joined #evergreen
23:05 mglass joined #evergreen
23:05 chatley_ joined #evergreen
23:08 dreuther joined #evergreen
23:08 dreuther_ joined #evergreen
23:15 chatley joined #evergreen
23:15 dreuther joined #evergreen
23:15 dreuther_ joined #evergreen
23:15 mglass joined #evergreen

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