| Time |
Nick |
Message |
| 01:37 |
|
rlefaive joined #evergreen |
| 03:40 |
|
rlefaive joined #evergreen |
| 05:06 |
|
rlefaive joined #evergreen |
| 07:11 |
|
sarabee joined #evergreen |
| 07:27 |
|
Callender joined #evergreen |
| 07:42 |
|
rlefaive joined #evergreen |
| 07:47 |
|
mrpeters joined #evergreen |
| 07:58 |
kmlussier |
Good morning #evergreen! Happy Bug Squashing Day! |
| 07:58 |
|
collum joined #evergreen |
| 08:02 |
|
rjackson_isl joined #evergreen |
| 08:04 |
jboyer-isl |
HEY SYSADMINS. I'm giving up for now on using ubuntu for my dedicated postgresql machines. Supported OS's (that I would consider) are CentOS, Suse, and Red Hat. Any pros/cons you can share? I know I'm on my own re: setup, but it doesn't need to do anything but run postgres, so I can manage that. |
| 08:21 |
csharp |
jboyer-isl: what's going on with ubuntu? |
| 08:23 |
jboyer-isl |
network connections aren't stable. there's a 30-ish% chance that an initial connection will fail, and given enough time, they'll disconnect out from under things. |
| 08:23 |
csharp |
the problems with RHEL and CentOS is that the distro packages are super-old - I have no experience at all with Suse in a server environment |
| 08:24 |
jboyer-isl |
This goes away when connecting 2 servers nic-to-nic, but I've tried multiple switches and they don't help. |
| 08:24 |
csharp |
jboyer-isl: we haven't seen any issues with Ubuntu/PostgreSQL at all |
| 08:24 |
csharp |
jboyer-isl: what NICs are you using? |
| 08:25 |
csharp |
have you ruled out firmware? |
| 08:25 |
jboyer-isl |
csharp: what machines do you have it on? I'm trying brand new HP DL580 G9's with HP's 4 port NICs. (this didn't go away when swapping in an older HP NIC, though I had high hopes) |
| 08:25 |
jboyer-isl |
I ran the latest HP SUM that did update the EFI and NIC firmware, no help. |
| 08:26 |
jboyer-isl |
Neither are in use at the moment, I was going to throw CentOS on one and see if it exhibits the same symptoms, then I can call HP and ask WTF. |
| 08:27 |
csharp |
jboyer-isl: we were on HP DL785 G6's, but are now on Dell PowerEdge something or others |
| 08:27 |
csharp |
we have seen similar-sounding NIC issues with our HP DL585 G(7 or 8)s |
| 08:28 |
|
ericar joined #evergreen |
| 08:28 |
csharp |
I suspect it's hardware somewhere along the line |
| 08:28 |
jboyer-isl |
yeah, my G5's are fine with 12.04 and 14.04, it's only the G9's that are giving me trouble. (I need to upgrade a G8 in this process, I really hope that works...) |
| 08:29 |
csharp |
however, among your three options, I'd probably run with CentOS, but that's because I've used it (in non-production situations) before and know the environment pretty well from using Fedora |
| 08:29 |
jboyer-isl |
csharp: I was hoping it was the MTU or something that the switches didn't like, but a Cisco 35XX and a new HP 3500 aren't likely to barf on that. |
| 08:29 |
jboyer-isl |
I may try updating the HP switch to see if it makes any difference. :-/ |
| 08:29 |
csharp |
we use a Cisco 4510 |
| 08:30 |
csharp |
I think your "change the OS" experiment sounds worthwhile, though |
| 08:31 |
jboyer-isl |
I don't know if I would prefer that it start working or not. This is where I join the sysadmin chorus of "I hate computers" |
| 08:31 |
csharp |
@hate computers |
| 08:31 |
pinesol_green |
csharp: The operation succeeded. csharp hates computers. |
| 08:31 |
csharp |
@love computers |
| 08:31 |
pinesol_green |
csharp: But csharp already hates computers! |
| 08:31 |
csharp |
heh |
| 08:32 |
jboyer-isl |
@itscomplicated computers? |
| 08:32 |
pinesol_green |
jboyer-isl: Sorry, we can't do that because, you know, SOFTWARE. |
| 08:32 |
csharp |
@dontcare computers |
| 08:32 |
pinesol_green |
csharp: The operation succeeded. csharp no longer hates computers. |
| 08:32 |
csharp |
pinesol_green++ |
| 08:32 |
jboyer-isl |
Well that was probably the best of all possible outcomes. |
| 08:32 |
kmlussier |
@karma pinesol_green |
| 08:32 |
pinesol_green |
kmlussier: Karma for "pinesol_green" has been increased 8 times and decreased 1 time for a total karma of 7. |
| 08:33 |
csharp |
@quote add < pinesol_green> The operation succeeded. csharp no longer hates computers. |
| 08:33 |
pinesol_green |
csharp: The operation succeeded. Quote #133 added. |
| 08:34 |
kmlussier |
@quote random |
| 08:34 |
pinesol_green |
kmlussier: Quote #104: "<jeff> that's it. we're all switching to koha, right meow." (added by gmcharlt at 01:16 PM, January 02, 2015) |
| 08:35 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:44 |
|
mdriscoll joined #evergreen |
| 09:02 |
|
artunit joined #evergreen |
| 09:03 |
|
jwoodard joined #evergreen |
| 09:09 |
csharp |
HAPPY BUG SQUASHING DAY EVERYONE! |
| 09:10 |
mmorgan |
Happy Bug Squashing Day! |
| 09:12 |
csharp |
me, looking at acq bugs: https://40.media.tumblr.com/tumblr_m1ischtQ7u1rsa2f4o1_400.jpg |
| 09:13 |
tsbere |
csharp: I dunno if it fits unless the cans are already empty. ;) |
| 09:13 |
csharp |
haha |
| 09:14 |
kmlussier |
Heh. csharp++ |
| 09:18 |
Dyrcona |
Is https://evergreen-ils.org/communicate/calendar/ working for anyone else? It does not work for me. |
| 09:19 |
Dyrcona |
I get an empty space where the calendar ought to be. |
| 09:19 |
csharp |
Dyrcona: same here |
| 09:19 |
kmlussier |
I confirm that it is a bug |
| 09:20 |
csharp |
"Blocked loading mixed active content " |
| 09:20 |
* tsbere |
doesn't get a loaded page at all, but a "something went wrong, but we aren't sure what" page instead |
| 09:20 |
csharp |
so probably adding https to the URL will fix it |
| 09:20 |
Dyrcona |
Sure enough. |
| 09:20 |
tsbere |
switching to http instead of https makes it work |
| 09:21 |
Dyrcona |
Switching to https for calendar URL might fix it in the page... |
| 09:22 |
Dyrcona |
https everywhere is a nice idea, but sometimes it is overkill. ;) |
| 09:23 |
kmlussier |
Fixed |
| 09:25 |
kmlussier |
And now that it's fixed, I see a visible reminder that I'm supposed to be preparing to lead Friday's Evergreen for Academics meeting. |
| 09:25 |
Dyrcona |
kmlussier++ |
| 09:30 |
|
maryj joined #evergreen |
| 09:30 |
|
ericar_ joined #evergreen |
| 09:32 |
|
ericar__ joined #evergreen |
| 09:33 |
Dyrcona |
@coffee kmlussier |
| 09:33 |
* pinesol_green |
brews and pours a cup of El Salvador Finca Siberia Pacamara, and sends it sliding down the bar to kmlussier |
| 09:33 |
kmlussier |
Dyrcona: Thank you! :) |
| 09:35 |
miker |
jboyer-isl: I'm sure you've already investigated this, but we've seen auto-sensing duplex settings fail with HP NICs and some switches ...have to force port speeds and duplex settings. the symptoms are what you describe |
| 09:36 |
* Dyrcona |
has seen auto-sensing fail with a number of different NICs. |
| 09:39 |
|
jlundgren joined #evergreen |
| 09:44 |
kmlussier |
A question about our QA guidelines. A good percentage of the fixes I loaded for Bug Squashing Day have changes made to a .pm file, but I don't think any had a regression test. |
| 09:45 |
kmlussier |
I just want to make sure I'm clear on the guidelines before I start adding needstest tags. Any change made to perl code since May of this year, no matter how large or how small, should have a test? Is that right? |
| 09:46 |
|
ericar_ joined #evergreen |
| 09:51 |
Dyrcona |
kmlussier: I don't think we have been quite that strict, although "should" is a recommendation, not a commandment. |
| 09:51 |
Dyrcona |
My understanding is if the commit messages provide adequate test instructions, the live test can be waived. |
| 09:53 |
kmlussier |
I thought the waiver was only given when there is a statement from the patch author explaining why a test is infeasible without significant refactoring |
| 09:53 |
* csharp |
gets indecisive about which bugs to focus on. Candidates today are bug 1175293 (highest "heat" of acq bugs), bug 1413352, and bug 924952 |
| 09:53 |
pinesol_green |
Launchpad bug 1175293 in Evergreen "ACQ: Allocate to Fund drop down menu (in Funding Source) Not Following Precedents Set by Other Fund Menus" [Medium,Confirmed] https://launchpad.net/bugs/1175293 |
| 09:54 |
pinesol_green |
Launchpad bug 1413352 in Evergreen "New Brief Record estimated price does not populate" [High,Confirmed] https://launchpad.net/bugs/1413352 |
| 09:54 |
pinesol_green |
Launchpad bug 924952 in Evergreen "Acquisitions: Order record loads fail when there is a null value in a holdings subfield" [High,Confirmed] https://launchpad.net/bugs/924952 |
| 09:54 |
Dyrcona |
csharp: Those look like good ones to work on to me. |
| 09:54 |
jeff |
I'm not sure what's more realistic: working toward a point where we aren't considering waiving tests like that, or expecting that regression testing is accomplished by reading commit messages and manually testing things as directed there. |
| 09:54 |
jeff |
(on all future commits) |
| 09:55 |
|
yboston joined #evergreen |
| 09:55 |
Dyrcona |
jeff: I agree. I think we want tests on all things in the future. It's a matter of taking the time to get there. |
| 09:55 |
kmlussier |
I didn't think the commit messages / manual instructions were related to whether a test was provided or not. It was just something that is a best practice to include in any bug fix. |
| 09:56 |
jeff |
@decide kick the can down the road[map] or test paralysis |
| 09:56 |
pinesol_green |
jeff: go with kick the can down the road http://www.firstpersontetris.com/ |
| 09:56 |
Dyrcona |
Well, that was my understanding. I could be mistaken. |
| 09:56 |
* jeff |
gives pinesol_green a look |
| 09:56 |
kmlussier |
I've been going by http://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa |
| 09:56 |
|
genpaku joined #evergreen |
| 09:57 |
csharp |
@decide [someone] or [someone |
| 09:57 |
pinesol_green |
csharp: Error: Missing "]". You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands. |
| 09:57 |
Dyrcona |
I know some bug fixes have been written and pushed since May that have not had live tests. |
| 09:57 |
csharp |
@decide [someone] or [someone] |
| 09:57 |
pinesol_green |
go with ericar |
| 09:57 |
jeff |
here i was hoping that pinesol_green would give us the kobayashi maru style solution when presented with those two equally undesirable options. :P |
| 09:58 |
kmlussier |
OK, but in re-reading that, if it is waived, an additional signoff is required. So, for the bug I'm looking at now, I guess I shouldn't be merging it because it either requires a test or requires an additional signoff. |
| 09:59 |
Dyrcona |
What we really need it a complete regression suite. Basically what we have are a strange hybrid of unit tests and some regression tests of some features. |
| 10:00 |
kmlussier |
But we will have more regression tests of more features if we continue to strongly encourage people to follow the guidelines. |
| 10:01 |
kmlussier |
Unless there is someone out there who has time to write a complete regression suite. :) |
| 10:02 |
Dyrcona |
Someone would have to make that a priority, yes, and devote resources to it. |
| 10:05 |
dbwells |
kmlussier: My understanding of the new test recommendations are the same as yours, though I'm also pretty sure that Dyrcona is right, and others have pushed stuff in without tests (which has generally confused me, and also made me wonder if others felt the descriptive tests were adequate) |
| 10:07 |
Dyrcona |
It was acknowledged that somethings are difficult to test, but I'll go along with requiring tests if that is what others understood. |
| 10:07 |
kmlussier |
Yeah, I don't doubt that some things have been merged without the tests. |
| 10:07 |
Dyrcona |
It could just be a minority (me) who misunderstood. :) |
| 10:14 |
dbwells |
It also isn't explicit in the 2.9 section of the document, but in my understanding we are still only requiring at least one new relevant test with each patch, not a complete and extensive suite (though it would be welcomed :) ). |
| 10:16 |
kmlussier |
Ok, so it looks like the guidelines were formalized at the August dev meeting. What I'm going to do then, for the patches I loaded on Sandboxes, is if the patch was created since August and makes any change to perl or database code, I'll add the needstest tag. |
| 10:16 |
kmlussier |
If it seems excessive for the code being changed, there is always that waiver that a dev can request if it seems excessive. |
| 10:16 |
kmlussier |
Bleh. Just a bit of redundancy in that sentence. |
| 10:19 |
|
rlefaive joined #evergreen |
| 10:24 |
Dyrcona |
I wonder if both pgtap and perl tests are required when the perl tests sufficiently exercise the database changes, but that could be a different discussion. |
| 10:24 |
* Dyrcona |
has a specific branch in mind where he added perl tests but not a pgtap test for the database changes, because function changes can be tricky in pgtap. |
| 10:24 |
kmlussier |
My gut reaction is that if the perl test sufficiently exercises the database changes, the perl test should be adequate. |
| 10:25 |
dbwells |
I agree. |
| 10:27 |
Dyrcona |
Sounds good to me. :) |
| 10:27 |
* Dyrcona |
returns to modifying a library's circ parameters. |
| 10:28 |
kmlussier |
For the discussion we just had, those tests are just for patches that fix bugs, right? In the case of jeff's code for bug 1013786, then, they wouldn't be required since it really is a new feature. |
| 10:28 |
pinesol_green |
Launchpad bug 1013786 in Evergreen "tpac: Check for password strength at login" [Medium,Confirmed] https://launchpad.net/bugs/1013786 - Assigned to Christine Burns (christine-burns) |
| 10:28 |
kmlussier |
I know it' says Medium importance, but, at this point, it feels like new feature to me. |
| 10:30 |
kmlussier |
Heh, I suppose we can remove the jspacremovalblocker tag from that one. :) |
| 10:30 |
jeff |
heh |
| 10:30 |
jeff |
yup. |
| 10:31 |
* jeff |
looks at that bug |
| 10:31 |
berick |
no, we have to merge jspac back in until all of those bugs are closed. |
| 10:32 |
jeff |
Oh, forgot I added pullrequest-worthy code to that bug. |
| 10:35 |
dbwells |
I think the test standards, whatever they may be, should apply more or less equally to bugs and new features. The document refers to "new code contributions", so I think it covers everything. |
| 10:36 |
dbwells |
(Of course, later parts reference "fixes a bug", so who knows :P) |
| 10:37 |
* kmlussier |
nods |
| 10:40 |
Dyrcona |
Right, I thought the standard for bug fixes was deliberately lower than for new features, and that may be 1 source of any misunderstanding. |
| 10:42 |
* Dyrcona |
awaits angularpac.... ;) |
| 10:43 |
|
rlefaive joined #evergreen |
| 10:45 |
jeff |
neat. my holds history breaks TPAC. |
| 10:52 |
* Dyrcona |
isn't surprised. |
| 10:53 |
Dyrcona |
i might be surprised when you figure out the why, however. ;) |
| 10:54 |
* Dyrcona |
should revisit the circ history download bug with a new solution. |
| 10:55 |
kmlussier |
Once I focused just on patches added since August, the number requiring tests wasn't so high. |
| 10:55 |
* kmlussier |
returns to actual testing now. :) |
| 10:55 |
tsbere |
jeff: Do you have metarecord or part holds on no longer existing metarecords/parts? |
| 10:55 |
Dyrcona |
That would not surprise me. |
| 10:56 |
Dyrcona |
And I was think parts holds on part that have since disappeared. |
| 10:56 |
Dyrcona |
I English good. |
| 11:11 |
csharp |
@eightball did I break something *else* when applying the fix? |
| 11:11 |
pinesol_green |
csharp: The outlook is good. |
| 11:11 |
csharp |
"me fail English? that's unpossible!" |
| 11:13 |
jeff |
unlikely to be parts, as we're not an active user of them at this time. |
| 11:13 |
jeff |
(still not impossible) |
| 11:15 |
csharp |
@dunno search apache |
| 11:15 |
pinesol_green |
csharp: 1 found: #4: "Try restarting apache." |
| 11:15 |
csharp |
@dunno 4 |
| 11:15 |
pinesol_green |
csharp: You probably want hard-boiled eggs. |
| 11:15 |
csharp |
@dunno get 4 |
| 11:15 |
pinesol_green |
csharp: Dunno #4: "Try restarting apache." (added by csharp at 02:44 PM, July 02, 2012) |
| 11:16 |
* Dyrcona |
thinks I may have been misunderstood earlier based on a recent bug comment. |
| 11:16 |
Dyrcona |
@dunno |
| 11:16 |
pinesol_green |
Dyrcona: Down time is a fact of business when you're a poor 501c3 corporation. |
| 11:25 |
* Dyrcona |
likes the 2016 conference logo and slogan. |
| 11:32 |
berick |
the nc triangle where i call home is lovely, but if we ever get too uppity: http://abc11.com/news/nc-solar-farm-rejected-over-fear-it-will-suck-up-energy/1122081/ |
| 11:35 |
kmlussier |
berick: That's just sad. |
| 11:36 |
csharp |
berick: saw that - I hope they enjoy the money I'm sure they're getting from the gas/electricity providers :-/ |
| 11:37 |
Dyrcona |
Yeah, that's just nuts. |
| 11:38 |
berick |
csharp: if that's what's actually happening, that makes me feel a lot better. |
| 11:38 |
csharp |
okay, my challenge with bug 1175293 is to figure out how to make the following code 1) |
| 11:38 |
pinesol_green |
Launchpad bug 1175293 in Evergreen "ACQ: Allocate to Fund drop down menu (in Funding Source) Not Following Precedents Set by Other Fund Menus" [Medium,Confirmed] https://launchpad.net/bugs/1175293 |
| 11:39 |
csharp |
oops |
| 11:39 |
csharp |
1) filter out inactive funds and 2) display the fund year: |
| 11:39 |
csharp |
<input jsId='fundingSourceFundSelector' name="fund" dojoType="dijit.form.FilteringSelect" searchAttr='code' labelAttr='code'> |
| 11:40 |
mmorgan |
kmlussier++ # Awesome Sandboxes! |
| 11:40 |
csharp |
I see an example from another file that sets formatFund and filterFund variables to do that, but it looks like its display is performed differently |
| 11:40 |
* csharp |
has too many terminal windows open |
| 11:41 |
csharp |
var fundSearchFormat = ['${0} (${1})', 'code', 'year']; |
| 11:41 |
csharp |
var fundSearchFilter = {active : 't'}; |
| 11:42 |
Dyrcona |
csharp: the ..format one looks like an array to be passed into a string format function. So it builds a string of 'code, (year)'. |
| 11:42 |
csharp |
it then defines widgets that use those variables |
| 11:43 |
Dyrcona |
Second looks like a typical cstore search variable entry. |
| 11:43 |
berick |
csharp: i suggest replacing the existing fundingSourceFundSelector building code w/ the autofieldwidget-based code that supports configirable formats/filters |
| 11:43 |
* Dyrcona |
is sure that doesn't really help. |
| 11:43 |
berick |
funding_source/view.tt2 is using the old-style Fund.js code that is not as configurable |
| 11:43 |
csharp |
berick: good - then I'm on the right track in my thinking |
| 11:43 |
csharp |
awesome |
| 11:44 |
csharp |
okay - gonna tackle that after lunch |
| 11:44 |
Dyrcona |
csharp++ berick++ |
| 11:44 |
csharp |
Dyrcona++ berick++ |
| 11:44 |
Dyrcona |
meh. I didn't say anything useful. :) |
| 11:45 |
kmlussier |
csharp++ |
| 11:45 |
kmlussier |
I know our acq users will be very happy to see that fix done. |
| 12:01 |
|
jihpringle joined #evergreen |
| 12:12 |
kmlussier |
@love bug squashing day |
| 12:12 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier loves bug squashing day. |
| 12:12 |
kmlussier |
@loves |
| 12:12 |
pinesol_green |
kmlussier loves parts; YAOUS; Fridays; clam chowder; coffee; new fanged email thing; quassel; magic eightball; trivia; Evergreeners; BBQ; spell check; mobile catalog; new edit links in the catalog; vim; pizza; grep; spring; summer; fall; clam chowdah; ginger beer; DokuWiki; the random magic spells page; Evergreen, the whole kit and caboodle; and bug squashing day |
| 12:13 |
kmlussier |
I wonder why I ever said I loved DokuWiki. |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:20 |
|
rlefaive joined #evergreen |
| 12:21 |
kmlussier |
Bug 1319998 is ready for merging. It's definitely a bug fix, but I know we try to limit database updates for point releases. Dyrcona and berick: Do you have opinions on whether I should backport it to 2.8 and 2.9? |
| 12:21 |
pinesol_green |
Launchpad bug 1319998 in Evergreen "money.materialized_summary_billing_del() ADDS to balance_owed" [Undecided,Confirmed] https://launchpad.net/bugs/1319998 - Assigned to Kathy Lussier (klussier) |
| 12:22 |
* kmlussier |
will get some lunch and then do her first database schema update this afternoon. :) |
| 12:23 |
|
bmills joined #evergreen |
| 12:27 |
|
kitteh_ joined #evergreen |
| 12:37 |
|
collum joined #evergreen |
| 12:37 |
berick |
kmlussier: i'd like to see it backported. |
| 12:38 |
yboston |
kmlussier: give me a holler when you are back in |
| 12:38 |
dbs |
If it's a bug, it's a bug. Particularly one that messes with patron's money balances! |
| 12:41 |
Dyrcona |
Yeah, backport is OK with me. |
| 12:48 |
|
Christineb joined #evergreen |
| 12:50 |
kmlussier |
OK, I'll backport. Thanks! |
| 12:51 |
kmlussier |
Our Bug Squashing numbers thus far https://docs.google.com/spreadsheets/d/18EVb7HBEXbZ6dbR1Lb67gEuotDFpxEmjMxPMbs3A-lQ/edit?usp=sharing |
| 12:51 |
kmlussier |
But I know it doesn't reflect all of the work that has been happening |
| 12:53 |
|
mrpeters1 joined #evergreen |
| 13:14 |
|
mrpeters joined #evergreen |
| 13:19 |
mmorgan |
Bmagic: I'm testing lp 1331174. and am curious what your intervals for LONGOVERDUE and LOST are in production. |
| 13:19 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 - Assigned to Michele Morgan (mmorgan) |
| 13:20 |
mmorgan |
The seed mark Long Overdue trigger worked fine to mark items long overdue at 6 months. |
| 13:22 |
mmorgan |
Then I changed the mark Lost trigger to mark the items Lost at 7 months. But the Lost trigger didn't find anything to mark Lost. It's looking for transactions with stop_fines NULL or MAXFINES, so my LONGOVERDUE transactions didn't get picked up to be marked Lost. |
| 13:22 |
mmorgan |
Are you using a custom filter for this? |
| 13:24 |
|
mrpeters joined #evergreen |
| 13:31 |
* mmorgan |
run out for a bit |
| 13:38 |
jihpringle |
kmlussier: Am I correct in assuming that the mlnc2 test server isn't generating and sending email? |
| 13:39 |
jihpringle |
I've tested lp 1197636 up to the point where the email should be sent |
| 13:39 |
pinesol_green |
Launchpad bug 1197636 in Evergreen "Email record detail does not check for email" [Medium,Triaged] https://launchpad.net/bugs/1197636 - Assigned to Jennifer Pringle (jpringle-u) |
| 13:40 |
tsbere |
jihpringle: I do not believe any of those mlnc servers were set up for actually sending email. In general. |
| 13:45 |
kmlussier |
jihpringle: Sorry! You're correct. It's not configured to send email. I totally overlooked that need when I was setting it up. |
| 13:45 |
jihpringle |
np, I'll note in the bug that I can confirm everything up to the email actually being sent |
| 13:46 |
* tsbere |
has considered making them "send" email via the host machine....that would then capture every last message in a special account |
| 13:47 |
tsbere |
But then you need to check those accounts and all |
| 13:47 |
kmlussier |
jihpringle: I think Dyrcona already verified that the code was functional, so I think that's fine. |
| 13:47 |
kmlussier |
tsbere: If that's something that would be easy to set up, I think it would be worthwhile. This question has come up a couple of time with the MassLNC VM's |
| 13:49 |
|
gsams joined #evergreen |
| 13:49 |
tsbere |
kmlussier: I can see about looking into it. Checking the accounts may be harder to get up and running, though. I will think on it. |
| 13:52 |
csharp |
ugh - I'm lost in the weeds of JS and dojo :-( |
| 13:53 |
csharp |
I don't have enough context or enough foundation to do much here |
| 13:53 |
csharp |
with the goal of getting *something* done, I'm going to move on to hopefully more familiar topics |
| 13:53 |
kmlussier |
:( |
| 13:54 |
csharp |
it's like trying to read Dante after taking Italian 101 |
| 13:54 |
kmlussier |
csharp: I would send you an @coffee or @dessert to help you along, but I'm afraid they probably wouldn't send you decaf or something healthy. |
| 13:55 |
csharp |
"hey, I now that word!" among many unfamiliar ones |
| 13:55 |
csharp |
kmlussier: thanks |
| 13:57 |
* kmlussier |
finally moves along to merging Bmagic's fix. |
| 14:12 |
kmlussier |
Calling 0950 |
| 14:20 |
|
jlitrell joined #evergreen |
| 14:23 |
Bmagic |
mmorgan: sorry, I was at lunch - in order for the action trigger to target LONGOVERDUE circulations, there is a slight alteration required to be in the action_trigger_filters.json |
| 14:24 |
Bmagic |
{ "stop_fines" : ["MAXFINES"] } IIRC needs to be { "stop_fines" : ["MAXFINES","LONGOVERDUE"] } |
| 14:26 |
|
rlefaive joined #evergreen |
| 14:26 |
|
DPearl joined #evergreen |
| 14:28 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1319998 Stamping upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3e831ac> |
| 14:28 |
pinesol_green |
[evergreen|blake] LP1319998_materialized_summary_billing_del_ADDS_to_balance_owed - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=574cab2> |
| 14:41 |
jboyer-isl |
miker, Dyrcona: Just getting back from a meeting and reading scrollback. I had not come across suggestions to check that (my google-fu was weak) and it never occurred to me because 2015, but I'm absolutely testing that now. I was about to go install another OS to test, this is much faster. |
| 14:42 |
jboyer-isl |
If it works, you each get a meal/drink on me in NC. |
| 14:43 |
* mmorgan |
returns and catches up. |
| 14:45 |
jeff |
ahh, the fond days when 3com switches could lock up Cisco ethernet interfaces hard enough that Cisco would RMA them, but they really just needed to be power cycled. |
| 14:47 |
jlundgren |
I think I just confirmed my first (new) bug - https://bugs.launchpad.net/evergreen/+bug/1513231 |
| 14:47 |
pinesol_green |
Launchpad bug 1513231 in Evergreen "Cancel button renews item when Renew Item with Specific Due Date" [Undecided,Confirmed] |
| 14:48 |
mmorgan |
Bmagic: So the change to the json filter isn't included in the branch? |
| 14:49 |
Bmagic |
mmorgan: no - my thought there was it's possible that some localized library may not want to override a LONGOVERDUE circulation (I could be wrong) |
| 14:49 |
kmlussier |
Huh. I'm fairly sure I did not hit submit twice on that comment I just added to bug 1526159 |
| 14:49 |
pinesol_green |
Launchpad bug 1526159 in Evergreen "Web client: items out count in patron summary is inaccurate" [Medium,Triaged] https://launchpad.net/bugs/1526159 |
| 14:50 |
kmlussier |
jlundgren++ #Excellent! Thanks for helping out! |
| 14:50 |
Bmagic |
mmorgan: in theory a system could have different action_trigger_filters for different cron jobs for different granularity (that's not the way we would do it but hey, I didn't want to force it) |
| 14:51 |
* kmlussier |
adds jlundgren to the spreadsheet. |
| 14:53 |
Bmagic |
mmorgan: also - I believe in a production environment, we may not want some other checkout.due AT to scope LONGOVERDUE |
| 14:53 |
jboyer-isl |
man ethtoold |
| 14:54 |
jboyer-isl |
Oops, sad trombone. |
| 14:58 |
kmlussier |
mmorgan: Are you thinking that you would be setting a transaction to Longoverdue without a bill after, say, 3 months, and then setting it to Lost, with a bill after something like 6 months? |
| 14:59 |
|
jlundgren1 joined #evergreen |
| 14:59 |
mmorgan |
kmlussier: That's the scenario I'm testing, yes. |
| 15:00 |
kmlussier |
Bmagic / mmorgan: Would it be reasonable, then, to add a separate "Lost from Long Overdue" trigger that has the necessary json for those sites that want to use that workflow? |
| 15:01 |
kmlussier |
I can see why you wouldn't want to add it to the typical Lost trigger since there are sites that want to set it and leave it at Long Overdue. |
| 15:02 |
Bmagic |
kmlussier: it's probably not a bad idea to throw a stock AT idea in the branch - but there are a few possibilities |
| 15:03 |
mmorgan |
So a custom filter could be added that looks for LONGOVERDUE also, along with a sample crontab entry? Maybe? |
| 15:05 |
Bmagic |
mmorgan kmlussier - it would have to be an AT with a granulairty paired with a matching cron that uses a different json file |
| 15:05 |
|
abneiman joined #evergreen |
| 15:15 |
mmorgan |
Would clear documentation on how to accomplish the longoverdue to lost be generally accepted? Or is it better to have the examples? |
| 15:19 |
jboyer-isl |
Network? More like Notwork. |
| 15:19 |
mmorgan |
jlundgren++ |
| 15:21 |
kmlussier |
Christineb: Would it be helpful to try the same workflow (if you have time) on another masslnc VM to see if the issue you encountered was caused by the new code? |
| 15:21 |
kmlussier |
Christineb: The VM's are nearly identical with the exception of the branches that were added for testing. |
| 15:21 |
Christineb |
kmlussier - Oh great idea, I will try that |
| 15:23 |
kmlussier |
mmorgan: I think it's generally preferable to have examples, but I don't think the lack of them is a showstopper. But I want to take a closer look at it too. |
| 15:24 |
kmlussier |
Christineb: You could probably hop on the one jihpringle is using. The access info is on the same spreadsheet. |
| 15:24 |
mmorgan |
kmlussier: I guess I would agree that examples would be better. |
| 15:25 |
Christineb |
kmlussier : perfect, Thank you |
| 16:04 |
kmlussier |
Updated tally at https://docs.google.com/spreadsheets/d/18EVb7HBEXbZ6dbR1Lb67gEuotDFpxEmjMxPMbs3A-lQ/edit?usp=sharing |
| 16:05 |
Bmagic |
kmlussier++ |
| 16:06 |
|
mrpeters1 joined #evergreen |
| 16:44 |
kmlussier |
dbwells: I had hoped to look at bug 1422379 today, but it looks like it wasn't meant to be. I hope to put some eyes on it soon, though. |
| 16:44 |
pinesol_green |
Launchpad bug 1422379 in Evergreen "Move money.billing timestamps back to moment of fine" [Medium,Triaged] https://launchpad.net/bugs/1422379 - Assigned to Kathy Lussier (klussier) |
| 16:45 |
dbwells |
kmlussier: Hey, thanks for trying. I've been looking at bugs for the last hour or so, and also generally getting stuck in one way or another. |
| 16:45 |
jlundgren1 |
stompro++ for testing in master build - https://bugs.launchpad.net/evergreen/+bug/1312699 |
| 16:45 |
pinesol_green |
Launchpad bug 1312699 in Evergreen "Editable Checkout History" [Wishlist,Triaged] - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 16:45 |
kmlussier |
Stompro: I'll need to check, but I think the sorting is something that is present in master already. It was a new 2.9 feature |
| 16:46 |
dbwells |
I think I'll report some "new" bugs instead (stuff we've had in production for a while, in some cases :( ). |
| 16:46 |
Stompro |
kmlussier, I just realized, that I added a correction. |
| 16:47 |
* Stompro |
says bad comma, you sat in the wrong spot. |
| 17:06 |
* dbs |
says bad comma you sat in the wrong, spot |
| 17:07 |
|
jlundgren1 left #evergreen |
| 17:07 |
|
mdriscoll left #evergreen |
| 17:10 |
berick |
mdriscoll++ |
| 17:10 |
berick |
(just missed you) |
| 17:16 |
mmorgan |
Good Night Bug Squashers! |
| 17:17 |
|
mmorgan left #evergreen |
| 17:18 |
kmlussier |
Good night mmorgan! |
| 17:18 |
kmlussier |
Ah well, a bit too late |
| 17:19 |
miker |
jboyer-isl: based on "network? more like notwork" I'm guessing duplex and speed autosense was not the issue? |
| 17:23 |
kmlussier |
Just took a look at the signedoff bugs that also has a needstest bug. Other than the bug gmcharlt already commented on, there are two from miker http://bit.ly/1UvXOvc |
| 17:24 |
kmlussier |
miker: If those are examples of bugs where tests would be infeasible, could you note that on the bugs? I don't have a clear sense of what's infeasible and what's doable. |
| 17:37 |
kmlussier |
"101 bugs reported by me" Looks like I missed an opportunity to celebrate when I hit the 100 mark. |
| 17:40 |
berick |
bummed I could not participate today. |
| 17:40 |
berick |
bug_squashers++ |
| 17:42 |
kmlussier |
berick: Well, you do a lot of fixing between Bug Squashing Days. :) |
| 17:56 |
Bmagic |
kmlussier++ #yay bugs and bug guts |
| 17:57 |
kmlussier |
Ewwww. Bug guts |
| 18:45 |
|
jihpringle joined #evergreen |
| 18:47 |
|
jlitrell joined #evergreen |
| 18:50 |
|
dcook joined #evergreen |
| 18:53 |
|
jlitrell joined #evergreen |
| 19:46 |
|
rlefaive joined #evergreen |
| 23:03 |
|
Michaud joined #evergreen |
| 23:08 |
|
Michaud2 joined #evergreen |
