Evergreen ILS Website

IRC log for #evergreen, 2015-11-17

| 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:16 pinesol_green` joined #evergreen
07:09 Callender joined #evergreen
07:38 rjackson_isl joined #evergreen
07:54 Shae joined #evergreen
08:02 jboyer-isl joined #evergreen
08:09 ericar joined #evergreen
08:24 mrpeters joined #evergreen
08:38 sarabee joined #evergreen
08:57 kmlussier Good morning #evergreen
08:57 kmlussier @coffee [someone]
08:57 * pinesol_green` brews and pours a cup of Kenya Mamuto, and sends it sliding down the bar to rashma
08:57 kmlussier @tea [someone]
08:57 * pinesol_green` brews and pours a pot of Honey Black Tea, and sends it sliding down the bar to book`_ (http://ratetea.com/tea/health-​and-tea/honey-black-tea/7529/)
09:03 Dyrcona joined #evergreen
09:03 jeff_ morning, kmlussier!
09:05 Dyrcona Good morning!
09:06 * Dyrcona just wants to say that tunneling DB connections from PgAdmin over SSH is awesome.
09:07 Dyrcona Or, maybe it isn't.
09:08 Dyrcona Yeah, no. I'll go back to making the tunnels manually. PgAdmin's don't seem so reliable.
09:10 maryj joined #evergreen
09:14 jwoodard joined #evergreen
09:16 sarabee joined #evergreen
09:19 mmorgan joined #evergreen
09:36 yboston joined #evergreen
09:54 sarabee joined #evergreen
10:07 kmlussier Dyrcona: For clarification, test writing day is today, not tomorrow.
10:08 Dyrcona Well, now you tell me.
10:08 kmlussier ldw sent his email last night.
10:08 Dyrcona And, goodbye. I have a day of meetings.
10:36 maryj joined #evergreen
10:45 Dyrcona joined #evergreen
10:46 dbs hrm, looks like pg_enable_utf8 is no longer a good idea in clark-kent.pl
10:48 dbs per http://search.cpan.org/~turnste​p/DBD-Pg/Pg.pm#pg_enable_utf8_(integer) "Use of the default is highly encouraged" (default is -1, we set it to 1). Removing it fixed our utf8 encoding output problems in HTML even though we're on DBD::Pg 2.19.
10:49 dbs behaviour changed in DBD::Pg 3.0.0, but I suspect since we're using use open ':utf8' pragma we're getting extra levels of encoding that we don't really want
10:51 * Dyrcona is likely to disappear in a minute or so.
10:51 gmcharlt dbs: wheee! incompatible changes FTW! at least it was documented
10:53 berick oh right... release cutting.
10:53 * dbs ponders the work required to set up a suite of tests for the reporter
10:54 dbs live tests I guess
10:54 berick kmlussier: are you still our point person for release docs?
10:54 kmlussier berick: Yup. I haven't done the legwork to find somebody to take my place yet.
10:55 sandbergja joined #evergreen
10:55 kmlussier I'm planning to get the point release notes done today, so that y'all aren't waiting on me tomorrow. :)
10:56 berick kmlussier: awesome, thank.  i'm just proud of myself for thinking about it slightly in advance.
10:56 berick er, thanks
10:56 berick let me know if I can assist
10:56 kmlussier will do!
10:59 * Dyrcona wonders how much of his data plan he'll use up today.
10:59 dbs oh that's fun, fixing the HTML output ruins the Excel output
10:59 dbs MADRE DIOS
11:00 Dyrcona dbs: Of course it does.
11:00 bshum "Can open.... worms everywhere...."
11:01 Dyrcona bshum++
11:07 StomproJ Question for the core devs.  I was working on combining all the outstanding "Permission missing from system" launchpad tickets into one branch.  And I was also planning on merging all of the database upgrade scripts into one file.  I was thinking that it would be easier to deal with them all at once, and just have one db update to apply and test.  Is this an ok practice?
11:07 bshum StomproJ++ # yes
11:07 bshum And in fact I mentioned doing something similar at the Hackaway with mmorgan
11:07 ericar joined #evergreen
11:07 bshum Mainly I just worried about having tons of conflict
11:08 bshum Though personally, I also suggested that it might be nice to get rid of the IDs entirely for permission and change it to work off the codes themselves as the key
11:08 StomproJ The 950.seed-data conflicts is what made me want to do it in the first place.  Every addition conflicts with every other addition, so combining them together seemed like a good idea.
11:09 Dyrcona bshum: I seem to recall having the same idea about dropping ids for permissions.
11:09 jeff_ as long as the changes are all similar in nature, it seems reasonable. if we do go that route, i'd suggest one omnibus LP bug to tie it all together.
11:09 bshum It's been floating around for awhile.
11:09 * bshum doesn't claim the idea as his
11:09 jeff_ so that said omnibug would be attributed in the commit message, and could link to the individual bugs.
11:09 StomproJ jeff_, that was my next question, if I should create a meta bug report to cover the ones I'm working on.
11:10 jeff_ oh, look. i've been entailed.
11:10 gmcharlt or even just create the new omnibus bug, then close out the older bugs as "duplicates"
11:11 bshum +1 to gmcharlt's suggestion.
11:13 miker StomproJ: I agree with jeff, but offer this warning: the .override permissions were (at the time) intentionally left out, as that is a "soft" mechanism.  Any event could potentially become override-able, but not all need to be, so a prescribed list was eschewed in favor of letting sites add just the .override perm versions that they needed. the documentation for that was, of course, *COUGH* underwhelming as most early documentation was :)
11:14 jeff launchpad doesn't give us much nuance with regard to this kind of thing, but duplicate seems to be the wrong designator there. i think it might also make things more difficult to search (an impressive feat).
11:15 miker so, the .override permissions will likely continue to lag behind the state of the art... future batch updates will likely be needed
11:15 gmcharlt jeff: meh - if the omnibus bug cites all of the perms being added from the bugs being closed out, it would be as searchable as before
11:15 miker and google's site: makes it marginally searchable
11:18 StomproJ miker, so should the .override related bugs be closed out and documentation updated instead?  Or are you saying that the launchpad bugs for those are showing that they are needed in the default install?
11:20 kmlussier I like including the override ones in the stock permissions if they are ones that are likely to be used.
11:20 miker sorry I was unclear.  I'm personally fine with adding the perms to the seed data (and an upgrade script), but many folks have added some of those perms already, so the upgrade should take care to renumber local ones
11:21 bshum So, to remove IDs.  I'm thinking we need to alter the permission map tables too then, to change them to map to the codes as well.
11:21 miker AND documentation updates to explain that useful permissions can be added (or removed, as the site chooses) to change the ability to override events
11:21 * bshum tries to think of where else to rip it out
11:21 Christineb joined #evergreen
11:21 miker bshum: the map tables should have ON UPDATE CASCADE fkeys to handle that
11:21 miker (and if they don't, now would be a good time to add them)
11:22 sarabee joined #evergreen
11:23 StomproJ The updates have just been adding perms if they don't exist, and haven't tried to add new perms to perm groups so far.  I would be against adding perms to groups on upgrades, but adding them to the seed data where it seems to make sense.  There is just no telling what someone has in mind for the perm groups once they are in use.
11:23 Dyrcona I'm gonna leave. I'll catch up with the logs, later.
11:24 bshum StomproJ: What miker means is that sites may have individually already added the permissions as named.  So if the upgrade script doesn't account for that possibility, it could fail right away on conflict (same name).
11:24 bshum So renumbering an existing permission in someone's database to match what ends up in the seed code can be good for "consistency".
11:25 bshum But if they already have an ID in their DB and it conflicts, that would be bad too.
11:25 * bshum runs away for a moment too.
11:25 kmlussier bshum: But if we remove the IDs, it solves that problem, right?
11:25 bshum kmlussier: That's my hope.
11:25 bshum Maybe that should be a 2.10 goal :)
11:25 kmlussier bshum: Add it to the roadmap! :)
11:26 gmcharlt bshum: if you're offering to do the work, go for it! :)
11:26 berick what gmcharlt said
11:26 * bshum contemplates, and wanders away
11:26 berick too late, you have to do it now.
11:26 kmlussier And I always thought if you added something to the roadmap, it just magically happened. ;)
11:27 StomproJ bshum, I think the adding the same name case is covered, that shouldn't be a problem.  But I hadn't thought about renumbering.  I'll try to add that also.
11:28 gmcharlt kmlussier: alas, the RM is fresh out of magic dust! ;)
11:28 miker renumbering is important if we want to (or already do) protect permissions in UIs (the "reserved range" stuff in conify interfaces)
11:31 dbs oh yay we have a local fix for our DBD::Pg HTML vs. Excel + CSV report output issue
11:32 dbs long story short: use the classic 3-arg open(my $raw, ">:encoding(utf-8)", "$file.raw.html") approach to open the filehandle rather than pg_enable_utf8 & FileHandle
11:33 * berick reads "maintain_control_numbers() GEICO identifiers"
11:34 csharp @tea the GEICO gecko
11:34 * pinesol_green` brews and pours a pot of Top Leaf™ Green Tea, and sends it sliding down the bar to the GEICO gecko (http://ratetea.com/tea/mellow-monk/top-leaf/1186/)
11:35 berick the union of MARC and insurance... it doesn't get any better than that
11:35 gmcharlt berick: that suggests an exciting new model for funding Evergreen development... insurance for your every metadata need!
11:35 gmcharlt *snap*
11:35 jeff miker: and if we're removing IDs adding a bool for "protect this / system perm" might be needed to take the place of the id range(s).
11:36 berick gmcharlt: haha.. "do you keep losing bits to the bucket?  have I got a product for you!"
11:36 gmcharlt jeff: +1
11:37 jeff "Sorry, your Basic Naming Collision coverage doesn't extend to records with incorrect nonfiling indicators."
11:37 * berick chuckles
11:38 csharp @blame librarian road rage because of Evergreen
11:38 pinesol_green` csharp: librarian road rage because of Evergreen broke Evergreen.
11:39 jeff how recursively meta.
11:39 berick it's a vicious cycle
11:43 collum joined #evergreen
11:46 kmlussier bug 1402018 has a milestone of 2.next, but it feels more like a bug fix to me than a new feature.
11:46 pinesol_green` Launchpad bug 1402018 in Evergreen "Acq Copy location UI scoped to registered workstation" [Undecided,New] https://launchpad.net/bugs/1402018 - Assigned to Chris Sharp (chrissharp123)
12:07 pinesol_green [evergreen|Steven Chan] Fix LP1175711, OPAC can't renew item on booking resource list - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=69e5ef2>
12:08 Shae joined #evergreen
12:15 kmlussier Anyone have opinions on whether the above acq copy location bug should be backported?
12:15 * kmlussier wanders off to lunch
12:16 bmills joined #evergreen
12:17 dbs The "Fix HTML UTF8 output of clark-kent" fix we're using is here, if anybody wants to try it out locally: http://git.evergreen-ils.org/?p=cont​rib/Conifer.git;a=commitdiff;h=8eb21​87676508697c2cc6789626b2d08cc5df935
12:17 * dbs sees $index getting initialized twice, goes to fix that
12:19 dbs I meant http://git.evergreen-ils.org/?p=cont​rib/Conifer.git;a=commitdiff;h=78d3d​4e0347178651974f33549039d3058f9661f
12:19 dbs yeah, yeah that's the ticket
12:20 gmcharlt kmlussier: I think it reasonable to treat it as a backportable bugfix
12:23 gmcharlt dbs: what about CSV and the debug HTML output?
12:23 ldw Following the emails regarding test writing day and patch release day, I will postpone test writing day until next week.  I will send out an email shortly.
12:25 dbs gmcharlt: CSV seems to be handled by the Text::CSV_XS module, same way Excel module does
12:25 gmcharlt OK
12:26 gmcharlt (I'm asking on the basis of having just read the patch, not yet putting it through its paces)
12:26 dbs I suppose debug should be fixed too, but I can count on one hand (literally) the number of times I've looked at the debug output
12:26 dbs so that wasn't forefront of mind. More focused on the stuff most mortals actually see
12:27 tsbere dbs: I know that at least one person here in the office uses debug frequently to see what went wrong in the SQL when a template doesn't quite work.
12:27 dbs I haven't bugged this or submitted it as a formal fix because I'm curious about what happens on a system with DBD::Pg 3.0.0+
12:28 dbs tsbere: I can believe that
12:35 jihpringle joined #evergreen
12:41 kmlussier ldw: I don't think that's necessary. Dyrcona thought test-writing day was tomorrow, not today.
12:42 kmlussier ldw: I clarified the date for him in channel, but forgot to send something out to the list.
12:45 sarabee joined #evergreen
12:45 dbs fwiw, the debug output seems thoroughly escaped; a report name of 'Test Francais 8é' gets translated in the output as 'name' => "Test francais 8\x{e9}"
12:46 dbs which seems fine. But then the subject of the email gets corrupted because we're not doing the right SMTP things
12:46 dbs so... how far down this rathole do we really want to go? Me, I'm happy just seeing the HTML output fixed as a start.
12:47 dbs Having fixed the email output for action-trigger notifications way back when, the path is reasonably clear, but the cost/benefit ratio is suspect
12:48 gmcharlt do what you can, LP the rest and move on
12:50 kmlussier ldw: Another thing to consider, next week could be problematic due to U.S. Thanksgiving.
12:57 jihpringle_ joined #evergreen
12:57 Shae_ joined #evergreen
13:11 pinesol_green [evergreen|blake] LP1402018_Acq_Copy_location_UI_s​coped_to_registered_workstation - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4b094b1>
13:20 ldw kmlussier: ahhh.  I think now that I have gone and spammed the list about a date change, I might as well stick with it.  Hopefully, we can find one day next week that works for everyone in the US.
13:24 ldw Unless everyone here wants to write tests today (just reading the emails now).  I am fine with doing it today too.
13:34 kmlussier I'm fine going along with the crowd. Based on the silence, I'm guessing there aren't many people around to do it today.
13:34 ldw kmlussier: seems to be the case.  Do people take extended holidays for Thanksgiving?  Should I move it to the next week?
13:38 kmlussier I think it's common for people to take both Thursday and Friday off - don't want to miss all those Black Friday sales. Monday and Tuesday might be better.
13:38 kmlussier You could always keep next week on the poll and just add a few days from the following week just in case.
13:38 ldw Ok, I will modify the Doodle Poll to include Monday and Tuesday.
13:41 csharp kmlussier++ # using core committer access for great justice
13:42 kmlussier csharp: My goal was to get through all the bugs with a signedoff tag. There's just one left, but it's a new feature, so I'm saving it for another day. :)
13:43 csharp rock on
13:45 jlitrell joined #evergreen
14:06 Callender joined #evergreen
14:16 * jeff ponders the idea of offering to set valid = true on an invalid address when saving changes to it
14:22 tsbere jeff: I can see that being potentially useful. Also potentially annoying as "set to invalid" could be the change.
14:22 jeff well, right. that would be what i would consider to be a poor implementation of my pondered feature. ;-)
14:47 jeffdavis Just to confirm - SIPServer does not support fee payments, correct?
14:48 tsbere jeffdavis: I believe it does, in fact, support payments now.
14:48 tsbere Or, if it doesn't I wonder how one of our library's selfchecks are accepting payments.
14:51 jeffdavis Are they using EG's native selfcheck interface instead of SIP?
14:52 tsbere 3M, I believe
14:52 tsbere We don't have anyone using the native one
14:52 tsbere Or if we do nobody told me
14:57 bshum jeffdavis: As far as I know SIP payments are supported.
14:58 bshum jeffdavis: I say that cause we're working on a spec for enhancing the support for it
14:58 bshum So I've collected some information on what is there now
14:58 bshum https://bugs.launchpad.net/evergreen/+bug/1012328 and https://bugs.launchpad.net/evergreen/+bug/803121
14:58 pinesol_green Launchpad bug 1012328 in Evergreen "Add support for Fine Items (AV) field in Patron Information response message (64)" [Wishlist,Fix released]
14:58 pinesol_green Launchpad bug 803121 in Evergreen "SIP2 Fee Paid Message support (37/38)" [Wishlist,Fix released] - Assigned to Bill Erickson (berick)
14:58 bshum Have been around for awhile.
14:59 bshum What we're interested in (for one of our libraries) is adding the ability to pay a specific fine by ID, instead of mass bill payment.
14:59 bshum So just some bills, not all bills.
15:03 jeffdavis thanks
15:08 tsbere bshum: As far as I know, the EG side of the SIPServer dance already *can* do that if the client sends over the ID.
15:11 tsbere bshum: http://git.evergreen-ils.org/?p=Evergreen.gi​t;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS​/SIP/Transaction/FeePayment.pm;hb=master#l64
15:11 bshum Fun
15:12 * bshum ponders that
15:12 bshum So maybe what we need is a way to let the client know about the billing ID then
15:12 bshum I don't think that's covered by the patron information message
15:13 jeff it's a matter of formatting the Fine Items field, mostly.
15:13 jeff There was a spec. It was not supported by Vendor 3, despite their name being all over the spec.
15:14 tsbere Yea, looking I don't think the formatted lines include the ID. Wouldn't be hard to *add*, but I dunno how various systems would react to it.
15:15 jeff jeffdavis: going back to your original query, there is a distinction between "fine payment" and "fee payment" in some self check clients. Can you clarify if you're looking to support things like "we require $1 to check out this book"? That's "chargeable loans" or "fee" in some cases, distinct from "fines" like "you have these bills on your account".
15:15 tsbere how much is owed, the last billing type, title/author or last note....
15:16 jeff tsbere: various systems will react differently. it would likely be best to have two "typical" formats and a templated config format string to support other formats.
15:16 jeff one being "unformatted, what we've defaulted to for the past few years", another being "the sane/reasonable format that gives enough detail to support paying individual transactions", and then "give me a format string" :-)
15:16 tsbere jeff: Fun. Not in my list of things to implement right now, though.
15:17 * jeff nods
15:19 tsbere jeff: Not that hard to implement if we say "this is going to be a perl-style sprintf format string, here are the things we are passing in, go wild" though.
15:21 jeffdavis jeff: I was basically thinking "pay overdue fines" ... and getting confused by SIPServer's ILS::Transaction::FeePayment module which says "Not implemented," when I needed to be looking at the OpenILS::SIP::Transaction::FeePayment module in EG. :)
15:21 jeffdavis In other words, your questions are too sophisticated for me. :P
15:24 jeff jeffdavis: But did my questions help you to determine which questions to ask? :-)
15:29 jeff oh, and I suppose above I should s/unformatted/unstructured/ on the "unformatted, what we've defaulted to" bit.
16:20 jeff actor.hours_of_operation dow numbering is different from ISO 8601 (and postgres) dow numbering.
16:21 jeff also different from Javascript getDay(). Huh.
16:21 bshum That always used to drive me a little bit crazy.
16:21 bshum Then I just stopped looking at it :)
16:23 jeff Yeah. It seems vaguely familiar that I've been annoyed by this before.
16:24 jeff I'm trying to see if I can make a report that's a bit more aware of hours of operation, closed dates, etc.
16:26 tsbere jeff: That annoys me whenever I am looking at that too.
16:42 csharp rock on
16:42 csharp er.. that was from earlier ;-)
16:43 csharp bad wifi
16:43 csharp @blame bad wifi
16:43 pinesol_green csharp: bad wifi wants the TRUTH?! bad wifi CAN'T HANDLE THE TRUTH!!
16:43 kmlussier heh
16:43 kmlussier mmorgan++ #Grabbing core queries from the NOBLE database.
16:44 kmlussier I added it to the LP bug, but adding it here for the real karma points. :)
16:44 csharp @blame add Forget it, Jake.  It's just $who.
16:44 pinesol_green csharp: The operation succeeded.  Blame #20 added.
17:11 dcook joined #evergreen
17:13 * mmorgan emerges from last meeting of the day just in time to go home :)
17:14 csharp mmorgan: that's always nice
17:15 mmorgan Indeed! Good night #evergreen!
17:15 mmorgan left #evergreen
17:16 kmlussier gmcharlt: Remind me. Do we have a deadline yet for when new features need to be posted to LP to make it for beta?
17:18 kmlussier gmcharlt: Never mind. jlitrell found it for me. Feb. 5
17:18 jlitrell http://wiki.evergreen-ils.org/doku.​php?id=faqs:evergreen_roadmap:2.10
17:19 gmcharlt *quack*
17:19 jlitrell 2016, the year of Linux on the desktop.
17:20 berick heh
17:27 miker jeff: re DOW numbering, that comes from perl's DateTime module, IIRC. to facilitate biz-logic-layer ease
17:27 miker kmlussier: bug updated ... with a branch :)
17:28 kmlussier Excellent! I may load up a VM with it now.
17:28 kmlussier miker++
17:28 * csharp finds http://search.cpan.org/~drolsky/DateTime-1.21/​lib/DateTime.pm#0-based_Versus_1-based_Numbers based on miker's last comment
17:28 kmlussier hmmm...I wonder if I can find a good example in Concerto to test the branch against.
17:29 miker kmlussier: it's a one-liner ... maybe noble's test system can absorb it?
17:31 miker csharp: right... my thinking was, "if we use the /explicit/ *_0 method names in the perl, there will never be a question" ... whether that thinking was sound is left as an exercise for the reader to determine ;)
17:31 kmlussier miker: Maybe. I'll run it by them in the morning since it looks like mmorgan just left.
17:31 csharp miker: makes sense ;-)
17:32 miker of course, the module's contention that "There is a year 0." is ... problematic :)
17:33 csharp @eightball is there a year 0?
17:33 pinesol_green csharp: The answer is certainly yes.
17:34 csharp cal: year `0' not in range 1..9999
17:35 dbwells Those year 10000 bugs are going to be a doozy
17:35 csharp heh
17:40 Christineb joined #evergreen
19:14 jwoodard @librarian
19:14 pinesol_green jwoodard: Management:13, Cataloging:14, Acquisitions:14, Reference:14, Circulation:7, Systems:14, Research:7, Custodial:17
19:16 jwoodard Circulation has felt like that today. "You want to check out a book? Let me get my Director."
19:26 kmlussier jwoodard: On the plus side, you're acing custodial!
19:28 kmlussier For the 2.9 point release notes, I'm structuring things a bit differently. I've never been quite happy with the way I handled some things with the 2.8 release notes.
19:28 kmlussier I have a working branch at http://git.evergreen-ils.org/?p=workin​g/Evergreen.git;a=shortlog;h=refs/head​s/user/kmlussier/2-9-1-release-notes if anyone wants to take a look at the changes before I merge them tomorrow.
19:31 kmlussier And a gist that shows the changes at https://gist.github.com/ano​nymous/41365389d5f537428538
19:51 kmlussier @sortinghat
19:51 pinesol_green Hmm... kmlussier... Let me see now... SLYTHERIN!

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