| 00:07 |
|
bshum joined #evergreen |
| 00:07 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 00:09 |
|
kmlussier joined #evergreen |
| 00:11 |
|
mceraso joined #evergreen |
| 01:58 |
|
jonadab_znc joined #evergreen |
| 02:12 |
|
gsams joined #evergreen |
| 04:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:43 |
|
mrpeters joined #evergreen |
| 07:46 |
|
rlefaive joined #evergreen |
| 11:44 |
Dyrcona |
mrpeters: I have many custom git branches. |
| 11:44 |
mrpeters |
i meant for websockets |
| 11:44 |
Dyrcona |
websockets doesn't take that long on the OpenSRF side. |
| 11:44 |
mrpeters |
from my testing so far, i can do a hand install of opensrf/evergreen |
| 11:45 |
mrpeters |
and then run the debs to install websockets, bower, and grunt |
| 11:47 |
Dyrcona |
I haven't gotten to the Evergreen bit, yet. I think I might just adjust my build and setup scripts to do those steps for me. |
| 11:47 |
Dyrcona |
Think I'll get something to eat. |
| 11:53 |
terran |
Does anyone have a moment to help me with a fieldmapper question? I'm trying to figure out how to get to acq lineitem_detail info and I can't get the syntax right... |
| 13:19 |
Dyrcona |
mmorgan++ jboyer-isl++ |
| 13:19 |
Dyrcona |
Anyway, think I'll try the master branch of node.js. |
| 13:19 |
* Dyrcona |
is crazy like that. |
| 13:20 |
bshum |
Dyrcona: I think I've only tested with the version specified. But berick experimented with older versions of nodejs too |
| 13:20 |
bshum |
http://irc.evergreen-ils.org/evergreen/2014-11-05#i_135615 |
| 13:20 |
bshum |
The one that comes packaged with trusty was 0.10.25 |
| 13:21 |
Dyrcona |
OK. |
| 13:22 |
Dyrcona |
So, I could just install the package, then.... |
| 13:22 |
bshum |
In theory, yes. |
| 13:22 |
bshum |
Not sure where berick left that one. |
| 13:22 |
Dyrcona |
I know I've checked out tag 0.10.34 and used it. |
| 13:22 |
Dyrcona |
I'm lazy and thought I'd just give the master branch a whirl. :) |
| 13:23 |
* Dyrcona |
has spent more time talking/thinking about it than it would actually take to test...so much for lazy. :) |
| 13:23 |
berick |
Makefile.ubuntu-trusty installs the nodejs package |
| 13:23 |
berick |
it should do everything you need |
| 13:24 |
Dyrcona |
berick: It doesn't appear to do that. |
| 13:27 |
terran |
berick: mmorgan: I'm still getting no results - I also tried connecting to distribution_formulas in case I was trying to pull from the wrong source |
| 13:27 |
Dyrcona |
ok, I'll just run makefile.install again. |
| 13:29 |
Dyrcona |
I suppose the node stuff will move when the web staff client is mainstream, he said rhetorically. |
| 13:29 |
berick |
oh, and to clarify, the installer handles node and npm. installing the node packages and bower deps is still done by hand. |
| 13:30 |
berick |
starting with "== Building, Testing, Minification ==" from /Open-ILS/web/js/ui/default/staff/README.install |
| 13:30 |
|
rlefaive joined #evergreen |
| 13:31 |
Dyrcona |
Right. It looks like node, npm, and bower get installed. |
| 13:31 |
Dyrcona |
And, yeah, was gonna say looks like that is where to start. |
| 14:38 |
terran |
mmorgan: thanks for the moral support! |
| 14:39 |
Dyrcona |
kmlussier: Evergreen should be running on my dev vm with the web staff client and the latest branches you requested. |
| 14:39 |
kmlussier |
Dyrcona++ Thank you! |
| 14:39 |
Dyrcona |
I haven't had a chance to test it, yet, myself. |
| 14:42 |
bshum |
Well the upgrade worked. But non of the network adapters are functioning. Still it didn't completely blow up at least. |
| 14:43 |
* bshum |
continues his adventures |
| 14:56 |
|
jwoodard joined #evergreen |
| 15:14 |
gmcharlt |
yes |
| 15:14 |
ldw |
#action gmcharlt to organize webstaff client hacking day in September |
| 15:14 |
yboston |
ldw++ |
| 15:14 |
ldw |
#info jeff will look into removing old self check interface. |
| 15:15 |
|
rlefaive joined #evergreen |
| 15:16 |
ldw |
#action ldw will follow up with jeff about removing old self check interface status |
| 15:16 |
ldw |
#info jeff will look at removing old JSPAC code. |
| 15:17 |
ldw |
#action ldw will follow up with jeff about removing old JSPAC code status |
| 15:17 |
ldw |
#info dbwells will hopefully write more neg balances tests and push whatever he has ready on July 10 |
| 15:18 |
dbwells |
they done got wrote, mostly by remingtron |
| 15:18 |
Dyrcona |
That one is done. |
| 15:18 |
ldw |
#info dbwells done got wrote'em |
| 15:19 |
Dyrcona |
#info remingtron, too. |
| 15:19 |
berick |
heh |
| 15:19 |
dbwells |
though, apparently nobody actually tried to /run/ them, since the tests immediately failed after getting pushed in (due to a missing setup file) |
| 15:19 |
gmcharlt |
dbwells: something that had existed in your setup but missed being committed? |
| 15:19 |
dbwells |
gmcharlt: yes |
| 15:20 |
gmcharlt |
thought so |
| 15:20 |
Dyrcona |
Well, that's partly 'cause I didn't get to my part. |
| 15:20 |
ldw |
Is there anything else that needs doing on this item? |
| 15:21 |
kmlussier |
I don't think so |
| 15:21 |
ldw |
#info kmlussier to complete her testing on the negative balance branch by July 8 |
| 15:21 |
kmlussier |
#info kmlussier's negative balance testing is complete. Remaining issues have been reported in bug 1479107 and bug 1479110 |
| 15:21 |
pinesol_green |
Launchpad bug 1479107 in Evergreen "Replace manual void option with an "adjust to zero" option" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479107 |
| 15:21 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479110 |
| 15:22 |
ldw |
#info Dyrcona will follow up with negative balance branch after July 10. |
| 15:23 |
ldw |
did this discussion start? |
| 15:23 |
Dyrcona |
No, it hasn't. |
| 15:24 |
ldw |
#action ldw will follow up with jeff on merge vs cherry-pick discussion |
| 15:24 |
dbwells |
Perhaps on test writing day we can get some more eyeballs on the neg. balance tests. They do the job, but some parts are a little funky, and may need some more thoughts about best practices. |
| 15:24 |
ldw |
#action ldw will looking into integrating neg. balance tests on test writing day |
| 15:24 |
ldw |
#info : |
| 15:25 |
ldw |
#info : |
| 15:25 |
ldw |
#info yboston to followup with ldw about a testing day. |
| 15:25 |
ldw |
done |
| 15:25 |
ldw |
#info bshum to work with berick and others on crafting more information about release maintaining and schedules |
| 15:26 |
berick |
no such crafting has occurred that I know of |
| 15:26 |
ldw |
berick: are you still able to work on this with bshum? |
| 15:26 |
berick |
ldw: yes |
| 15:42 |
kmlussier |
They both have different objectives. One clears the negative balance off the record. The other adjusts a bill so that the balance is zero. |
| 15:42 |
berick |
ah, ok |
| 15:42 |
berick |
nevermind, then |
| 15:43 |
dbwells |
I would prefer to see the alpha released as-is, rather than rush/delay things. Unless we feel like there is nothing else worth testing in the alpha. |
| 15:43 |
berick |
raise your hand if you will install the alpha |
| 15:43 |
kmlussier |
Well, I install master on a regular basis, but I don't need an alpha release to do so. :) |
| 15:43 |
Dyrcona |
I already have, basically. :) |
| 15:46 |
* berick |
chuckles |
| 15:46 |
ldw |
#info Dyrcona protests an alpha action item ;P |
| 15:46 |
miker |
Dyrcona: thougths on pulling in the sprint2 branch at or around alpha time? |
| 15:47 |
Dyrcona |
miker: Well is sprint2 ready for testing or still work in progress? |
| 15:47 |
miker |
today, WIP, but we're closing it on it |
| 15:47 |
|
jwoodard joined #evergreen |
| 15:47 |
miker |
and, tbh, I think any working code should go in regardless of sprint boundary ... but, that's just my opinion |
| 15:51 |
* berick |
would like to see it merged in a lot more frequently |
| 15:51 |
ldw |
#action Dyrcona to investigate sprint2's integration with an alpha release |
| 15:52 |
* dbwells |
seconds more frequent merges |
| 15:52 |
bshum |
I've been testing sprint2 merges during my last two system builds with recent master. |
| 15:52 |
bshum |
It's not too crazy looking to me anyways. |
| 15:52 |
* bshum |
would say more but typing on a phone isn't so easy. |
| 15:53 |
* bshum |
will chat further with Dyrcona on that lookover. |
| 15:53 |
|
ericar_ joined #evergreen |
| 15:55 |
ldw |
Dyrcona: will you set a date for a release/skip an alpha release once you have examined the possibility of a sprint2 merge? |
| 15:55 |
Dyrcona |
Yes. |
| 15:57 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:57 |
kmlussier |
I added that topic to the agenda because the status of the QA proposal seems to still be in limbo. |
| 15:58 |
kmlussier |
I added the proposed guidelines to the contributing page after gmcharlt gave it the okay in that thread, but there were concerns raised shortly thereafter. |
| 15:58 |
ldw |
My concerns are not necessary. Your comment about a developer being able to state why a test is infeasible invalidates my concerns. |
| 15:59 |
dbwells |
I only have a couple minutes before I need to run, but would like more feedback on my proposal for multiple sign-offs in lieu of the "it's too hard to write tests" clause. |
| 15:59 |
ldw |
dbwells: I like that idea. |
| 15:59 |
dbwells |
I think it might keep things a little more objective and self-correcting. |
| 16:00 |
gmcharlt |
well, I think I would like to push back a bit on the notion of sign-offs as being "objective", per se |
| 16:00 |
ldw |
Would it be necessary for us to add a negative sign-off? Incase a committer feels strongly about a test being needed? |
| 16:01 |
gmcharlt |
which is not to dismiss the proposal of trading additional review in place of a statement that automated tests can't be written for a given patch |
| 16:01 |
Dyrcona |
ldw: That's typically done in a comment on the LP bug. |
| 16:02 |
dbwells |
Certainly not all signoffs are created equal, but more-is-better should generally hold true across the aggregate. |
| 16:02 |
gmcharlt |
also, in my view a statement to the effect that a test is not infeasiable is not meant to be a flat assertion |
| 16:02 |
gmcharlt |
rather, a reasoned argument |
| 16:03 |
gmcharlt |
that said, I'm not wedded that wording |
| 16:04 |
gmcharlt |
but I am in disfavor of frequent use of infeasibility statements OR multiple signoffs purely as a mechanism for folks to avoid writing unit tests |
| 16:04 |
gmcharlt |
or to put it another way |
| 16:04 |
gmcharlt |
- more tests: generally good |
| 16:04 |
gmcharlt |
- seeking out additional reviewers: almost always good |
| 16:04 |
gmcharlt |
- not writing tests for new code or significant bugfixes - AVOID! AVOID! |
| 16:05 |
* kmlussier |
is in agreement with gmcharlt |
| 16:06 |
ldw |
do we need to have a +1 type vote on this issue? |
| 16:07 |
gmcharlt |
ldw: dbwells: give me one moment to propose a wording change |
| 00:26 |
|
_robbat2|irssi joined #evergreen |
| 04:28 |
|
sarabee joined #evergreen |
| 05:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:48 |
csharp |
@praise sys admins |
| 07:48 |
* pinesol_green |
sys admins is kind and patient to newbies |
| 08:05 |
|
maryj joined #evergreen |
| 12:30 |
jboyer-isl |
Oops. I was wrong; no regex, but a substr($msg,-9,2), so basically the same thing. I'm not familiar enough with SIPServer to know where to start looking to fix that |
| 12:30 |
jboyer-isl |
jeff: count the number of digits after the AY. |
| 12:31 |
jboyer-isl |
Time to lunch and visit some GenCon'ers. |
| 12:39 |
jeff |
still not sure why on a test instance i get a 96 (retransmit) and on prod i get dead air. might be a secondary bug in multiplex. uncertain yet. |
| 13:45 |
jeff |
but yes, any SIP message that is at least 11 characters and whose last 9 characters start with AY will be passed through verify_checksum |
| 14:27 |
|
akilsdonk_ joined #evergreen |
| 14:32 |
|
Shae_ joined #evergreen |
| 14:59 |
kmlussier |
I'm just getting a chance now to wish a very Happy SysAdmin Day to all the awesome Evergreen Sys Admins in here! |
| 15:39 |
jeff |
apparently additional extensions / internal documentation adds a few others. |
| 15:40 |
jeff |
the argument for having them backed by config is getting stronger in my head, but i'm not sure where i think that config belongs. |
| 15:40 |
jeff |
the first step will be to treat 01 and 02 the same |
| 16:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:49 |
|
hopkinsju joined #evergreen |
| 17:51 |
hopkinsju |
Using vandelay to import some record we got back from backstage. They had RDA fields added, cleaned up, etc. Odd thing is that when I import with a 901c match set, I get 2 matches per record. |
| 18:05 |
berick |
using a 901c match set just adds another match on the same field |
| 18:05 |
berick |
if you choose "exact match only" (or whatever it's called) the built-in 901c matching should do what you need, no match set needed |
| 18:05 |
hopkinsju |
Well that's bizarre. This is a *ahem* newly acquired system for us. It came with a 901c matchset. I thought that was standard. |
| 18:06 |
berick |
just checked, there's not one in my test DB |
| 18:06 |
hopkinsju |
Oh yeah, weird. I never noticed that Missouri Evergreen doesn't have a 901c matchset. KSL had one, and I just selected it, because it was there. |
| 18:06 |
berick |
ther are merge profiles using 901c, but no match set |
| 18:06 |
hopkinsju |
Cool, well, that clears things up then. |
| 02:16 |
|
eady joined #evergreen |
| 05:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:03 |
|
gsams joined #evergreen |
| 07:42 |
|
ericar joined #evergreen |
| 07:47 |
|
graced joined #evergreen |
| 07:58 |
|
mrpeters joined #evergreen |
| 08:11 |
|
Dyrcona joined #evergreen |
| 08:21 |
jeff |
hah. thought i was seeing something Really Odd. |
| 08:22 |
jeff |
enabled SIP msg64_hold_datatype = barcode, did some testing with (a possibly hacked up copy of) tsbere's PHP SIP2 client. requested Hold and UnavailableHolds summary types in a patron information message. |
| 08:23 |
jeff |
the only item barcodes i was seeing in the response were not items i had holds on... but they were items that i would not be able to renew because someone ELSE had a hold on them. |
| 08:23 |
jeff |
This seemed like a Really Odd failure method until I realized that something was amiss and that the details I was getting were overdue items (which just so happened to be overdue because they had not been able to be renewed, etc) |
| 08:24 |
jeff |
Anyway, all better. |
| 08:24 |
jeff |
And if I didn't break it in the first place, I'll pass on a patch to tsbere. :-) |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:41 |
|
mrpeters joined #evergreen |
| 08:49 |
|
akilsdonk joined #evergreen |
| 12:37 |
jeff |
Yup. |
| 12:37 |
jeff |
bug 1013263 |
| 12:37 |
pinesol_green |
Launchpad bug 1013263 in Evergreen "Support SIP payment type 02 - "credit card"" (affected: 1, heat: 6) [Wishlist,Fix released] https://launchpad.net/bugs/1013263 |
| 12:39 |
jeff |
i wrote, you tested and signed off, lebbeous committed since neither you nor i could push to master at that point in time. :-) |
| 12:39 |
jeff |
I seem to recall it was only a few lines of code. |
| 12:57 |
Dyrcona |
Oh, three years ago... No wonder I don't remember. :) |
| 13:00 |
kmlussier |
Funny...I tend to recall bugs from 3 years ago better than I remember ones from a month ago. |
| 13:04 |
jboyer-isl |
So, about pgTAP tests; are we assuming the use of pg_prove, or should test scripts include all of the \pset and \set boilerplate? Only pg_prove is referenced in the documentation but most of our tests have all of the boilerplate, so... |
| 13:05 |
jboyer-isl |
I'd like to dump the lines we don't need, unless there was a decision that we do need them. |
| 13:06 |
|
Christineb joined #evergreen |
| 13:10 |
RoganH |
I need to invent a SIP wheel of doom so I can spin it each day and see what I think SIP will do today. |
| 13:15 |
jboyer-isl |
RoganH: My favorite experience was when a PC time management company wrote their own SIP communication library that would recognize field codes ANYWHERE. Made capitalized addresses much more "exciting" because it would also crash when it didn't understand what it was getting. |
| 13:19 |
|
gsams joined #evergreen |
| 13:20 |
tsbere |
They insisted that I couldn't use a repeating field for what I was using it for because the standard didn't *do* that. Then I pointed them at several in the standards doc they were using... |
| 13:23 |
jboyer-isl |
Although, come to think of it my toy code didn't take that into account properly either. At least I wasn't trying to charge anyone to use it. |
| 13:24 |
jeff |
so: tips of the day... a basic AAA membership card behaves enough like a Visa card for smoke testing credit card payments at a self-pay kiosk |
| 13:24 |
miker |
jeff: nice |
| 13:24 |
jeff |
and tip 2: if you have someone remoting into a kiosk to work on it and you want the kiosk obviously out of service with screen obscured, grab your nearest clean library T-shirt |
| 13:25 |
jboyer-isl |
jeff++ # lifehacks |
| 13:35 |
Dyrcona |
I never put anything on the prepaid bit, so don't use it, but that is a handy tip. |
| 13:35 |
jeff |
if everything else is working correctly, mine fails with SERV NOT ALLOWED |
| 13:35 |
Dyrcona |
And, since Dell.com is flaking out on me, I'll have to find something else to do. |
| 13:36 |
jeff |
which saves me from needing to 1) re-bill my patron / test patron, 2) void the charge before settlement or 3) remove/zero the payment in the ILS if things DO test well. |
| 13:36 |
jeff |
Once that part works, I usually do a $1.23 or similar payment and consider it the cost of knowing things are working. |
| 13:37 |
jeff |
(er, to be clear i'd usually have to do 1, 2, AND 3 above, not OR) |
| 13:39 |
|
collum joined #evergreen |
| 13:40 |
Dyrcona |
And, I don't see how the 408 could be my fault. I'm not on the wireless at the moment. :) |
| 13:48 |
* Dyrcona |
mumbles something about "magic beans." |
| 13:48 |
jboyer-isl |
re: pgTAP, I'm assuming no comment means "sure, do that" and I'll be dropping the noise from my upcoming tests. :) |
| 13:48 |
bshum |
@dessert add Lemon Cupcakes |
| 13:48 |
pinesol_green |
bshum: The operation succeeded. Dessert #38 added. |
| 13:49 |
bshum |
@dessert add Key Lime Cheesecake |
| 13:49 |
phasefx |
jboyer-isl: I think the live tester is using pg_prove, but psql should work just as well I thought |
| 13:50 |
csharp |
@dessert add A Moon Pie and some RC Cola |
| 13:50 |
pinesol_green |
csharp: The operation succeeded. Dessert #40 added. |
| 13:51 |
jboyer-isl |
phasefx: The README in the tests dir also only talks about pg_prove, so I figured that's what would see the most use. |
| 13:52 |
phasefx |
jboyer-isl: cool deal |
| 13:53 |
phasefx |
jboyer-isl: looks like psql can run them, but pg_prove actually parses and summarizes the test results |
| 13:54 |
phasefx |
but does that require the boilerplate you mentioned? |
| 13:55 |
phasefx |
oh I see.. those psets make it look nice if using psql |
| 13:56 |
phasefx |
could put that stuff into a common file and \i it |
| 13:56 |
kmlussier |
@dessert 40 csharp |
| 13:56 |
* pinesol_green |
grabs some A Moon Pie and some RC Cola for csharp |
| 13:59 |
jboyer-isl |
phasefx: yeah, the boilerplate is just for formatting, pg_prove sets all of that ahead of time. I was hoping to just say "we suggest using pg_prove, so do that" and then we can ignore all of that, simple tests could have 4 necessary lines vs a dozen lines of setup + 4 lines of work. (line # are estimates, of course) |
| 13:59 |
phasefx |
sounds good to me |
| 14:01 |
bshum |
@dessert 40 csharp |
| 14:01 |
* pinesol_green |
grabs some Moon Pie and some RC Cola for csharp |
| 09:17 |
pinesol_green |
Launchpad bug 1479107 in Evergreen "Replace manual void option with an "adjust to zero" option" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479107 |
| 09:19 |
kmlussier |
For bug 1479110, I would be curious to know if others agree with our assessment of how the settings should interact with each other. |
| 09:19 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479110 |
| 09:24 |
dbwells |
kmlussier: If we model it straight after the void interface code, it should be pretty simple. I don't think it is worth delaying the alpha for, though. I think the alpha is a litmus test to see if we're way off track, which means undone stuff is a given. |
| 09:25 |
dbwells |
kmlussier: I could add with a high degree of confidence that it should take less time than the original bug. |
| 09:25 |
* dbwells |
ducks |
| 09:33 |
jeff |
and... now you've jinxed it. |
| 09:35 |
|
yboston joined #evergreen |
| 09:58 |
kmlussier |
I'm inclined to agree with Dyrcona on the alpha delay if it's something that can be done in a reasonable amount of time, just because it would be nice to have it in as good shape as possible for the litmus test. |
| 09:59 |
kmlussier |
But, as bshum said, Dyrcona is our fearless leader. |
| 10:01 |
kmlussier |
Of course, part of me is also thinking of all the documentation I have to write and wanting to get started on it as soon as possible. |
| 10:02 |
Dyrcona |
Well, you could get started on the documentation. |
| 10:03 |
Dyrcona |
I find it is sometimes better to write the documentation first, and then write the code so it works according to the documentation. ;) |
| 10:03 |
kmlussier |
Actually, that was an idea raised at the Google doc sprint. Maybe I should start doing it for all of MassLNC's development projects. :) |
| 10:31 |
jeff |
mrpeters: check the value of ingest.reingest.force_on_same_marc in config.internal_flag? |
| 10:32 |
jeff |
mrpeters: still, 12 hours is a bit much to reingest 6k bres unless you're on really underpowered hardware. |
| 10:32 |
jboyer-isl |
mrpeters: Even if they are reingested that sounds like an enormous amount of time. Are things otherwise ok with this installation? Otherwise, jeff is right, that flag being set should be the only reason for a reingest if you don't touch the marc field. |
| 10:33 |
mrpeters |
yeah, its a test server, but comparable hardware to production |
| 10:33 |
jboyer-isl |
Stock postgresql.conf or edited? |
| 10:33 |
jeff |
mrpeters: did you do the updates in individual transactions? if not, is there any other activity on the system? have you checked for locking issues? |
| 10:33 |
jeff |
mrpeters: what does postgres think is happening with that query, and any other queries? |
| 10:40 |
mrpeters |
i will need to reingest eventually, because i will also be changing the marc with REGEXP_REPLACE but i hadn't even gotten to that point in the process yet, but, now i see a lot of hung up crap in the db that may take care of things |
| 10:41 |
Dyrcona |
mrpeters: I'd suggest possibly doing whatever you're doing via Perl. I find it much easier to manipulate MARC in Perl than directly in the database. |
| 10:41 |
|
jboyer-isl joined #evergreen |
| 10:41 |
phasefx |
didn't see it in channel this morning (net-split?), but there's a new failure at http://testing.evergreen-ils.org/~live/ re: perl live tests for negative balances |
| 10:42 |
mrpeters |
gotta stick with what i know, for now, Dyrcona |
| 10:42 |
Dyrcona |
pfft. I'm always keen to learn new things. :) |
| 10:43 |
Dyrcona |
But, I get it if you don't think you have the time. |
| 10:45 |
mrpeters |
yeah, time is the issue...and it's just adding a 856$9 to existing records, and regex_replace has never failed me in the past |
| 10:45 |
jeff |
Dyrcona: with ingest.reingest.force_on_same_marc set to true, UPDATE biblio.record_entry SET id = id WHERE id = 1; will cause a reingest of bre id 1. |
| 10:45 |
dbwells |
phasefx: thanks. Looks like two problems. One, do_checkin_override didn't make it into TestUtils, so it was probably missing from the branch. Two, we need to decide how to handle the pre-test SQL. I'll push something in for #1, but am not sure about #2. |
| 10:46 |
mrpeters |
turning off that flag will be key, i think -- i can then build a script to reingest just the records that changed |
| 10:46 |
mrpeters |
system isnt in use, so no harm in having that flag off while i update the few bibs |
| 10:47 |
jboyer-isl |
mrpeters: that flag should be set to false already, you really don't want edits that don't touch the marc to cause a full reingest all the time. You don't have to do anything special to cause a reingest of records whose marc you're editing. |
| 10:48 |
mrpeters |
although, i think its better than the old production server |
| 10:49 |
mrpeters |
gonna give it a whirl on the new hardware |
| 10:49 |
Dyrcona |
jeff: I guess I imagined the trigger checked more than it does. :) |
| 10:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Add missing util function for tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=437550e> |
| 11:11 |
|
Dyrcona1 joined #evergreen |
| 11:15 |
Dyrcona |
wifi-- |
| 11:35 |
|
bmills joined #evergreen |
| 11:36 |
kmlussier |
So I don't know if we should wait to merge them. |
| 11:39 |
Dyrcona |
We probably should wait. |
| 11:45 |
|
Christineb joined #evergreen |
| 11:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Move negative balance test xacts into sample data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a6c040> |
| 11:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Load negative balance test transactions in load_all.sql - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b842239> |
| 11:55 |
|
bmills joined #evergreen |
| 11:56 |
dbwells |
tests should be happier now; we'll see! |
| 11:57 |
jeff |
dbwells++ |
| 11:58 |
kmlussier |
dbwells++ |
| 12:56 |
Dyrcona |
dbwells++ |
| 14:37 |
kmlussier |
:( |
| 14:53 |
|
vlewis_ joined #evergreen |
| 14:56 |
|
vlewis__ joined #evergreen |
| 15:09 |
mrpeters |
follow up from earlier Re: bib source updates -- ran fine once i cleared out some queries that had hung in this particular test server -- ran in a matter of a couple minutes like I would have expected. |
| 15:11 |
Dyrcona |
mrpeters++ |
| 15:15 |
mrpeters |
for the logs, in case anyone ever needs to add 856$9 tags to e-resource bib records, this works nicely |
| 15:15 |
mrpeters |
UPDATE biblio.record_entry SET marc = REGEXP_REPLACE(marc, $$(<datafield tag="856" ind1="." ind2=".">)(.*?)(</datafield>)$$, $$\1<subfield code="9">SHORTNAME</subfield>\2</datafield>$$, 'g') WHERE id=foo; |
| 16:36 |
* jeffdavis |
goes ahead and does both |
| 16:42 |
kmlussier |
Sorry, I was working on something else. The settings go changed sometime around when comment 28 was added to the bug (see 3a). https://bugs.launchpad.net/evergreen/+bug/1198465/comments/28 |
| 16:42 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 17, heat: 80) [Wishlist,Fix committed] |
| 16:43 |
kmlussier |
But I also recall only setting the interval in my original testing. |
| 16:43 |
kmlussier |
I'm fine with whatever the community decides is more intuitive, but in discussions with the team here, there was general consensus that most people would think that, once people set prohibit to true, they would think it would be prohibited in all cases. |
| 16:45 |
kmlussier |
At the same time, in our environments, there are only a few individuals who would be allowed to touch those settings, so it's not as big of an issue as it would be if it were something most end users would be adjusting on a regular basis. |
| 16:56 |
|
vlewis joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:18 |
dbwells |
yay |
| 17:20 |
bshum |
dbwells++ |
| 17:21 |
|
vlewis_ joined #evergreen |
| 12:07 |
gsams |
jwoodard: Turns out it was nevery turned on afterall because I was afraid it would get used without everyone knowing about it |
| 12:09 |
gsams |
kmlussier: I read the new features docs everytime a release is done and I still miss/forget features exist |
| 12:12 |
kmlussier |
gsams: One of the reasons I like working on the release notes so much is because it keeps me aware of all the new things we're getting. :) |
| 12:13 |
jwoodard |
gsams I turned it on for our library to test it out upon learning that it existed. It is a neat feature that I plan on implementing. |
| 12:13 |
kmlussier |
phasefx: I have no opinion on bug 1478299. I'm fine with your solution if you want to merge it. |
| 12:13 |
pinesol_green |
Launchpad bug 1478299 in Evergreen "Fix hold permit test" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1478299 |
| 12:14 |
jwoodard |
Our library services a large area so a feature like this is very helpful. |
| 12:14 |
kmlussier |
phasefx: Or do you need a signoff for it? |
| 12:16 |
gsams |
jwoodard: I'm going to flip the switch for the whole group |
| 12:41 |
gsams |
jwoodard: I turned your link on for the registration |
| 12:58 |
jwoodard |
gsams: Thank you! I shot you an email about adding stuff to the page. |
| 12:59 |
bshum |
kmlussier: phasefx: I'm leaning towards his solution being generally more predictable too. I wasn't sure how the copy was chosen, since the IDs are generated somewhat randomly? |
| 13:02 |
kmlussier |
bshum: OK, well, like I said, I'm fine with it if somebody wants to merge it so that our tests can be happy again. |
| 13:14 |
|
akilsdonk_ joined #evergreen |
| 13:30 |
bshum |
~search_path |
| 13:30 |
pinesol_green |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
| 14:34 |
bshum |
Where _bott_ solved the null card problem a different way by having that method skip over any deleted users. |
| 14:34 |
bshum |
I think we should incorporate both fixes for a complete solution. |
| 14:34 |
bshum |
I'll try and mix-match everything into one LP with a proper pullrequest branch in a few moments. |
| 14:38 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1478299: fix location for asset used in test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=001bb57> |
| 14:45 |
bshum |
_bott_++ |
| 15:04 |
|
ericar_ joined #evergreen |
| 15:08 |
|
jlitrell joined #evergreen |
| 16:26 |
jboyer-isl |
:Q |
| 16:27 |
|
mrpeters joined #evergreen |
| 16:27 |
bshum |
Calling 0921 |
| 16:34 |
pinesol_green |
Showing latest 5 of 18 commits to Evergreen... |
| 16:34 |
pinesol_green |
[evergreen|Remington Steed] LP 1198465: Initial tests for conditional negative balances - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=336f8a6> |
| 16:34 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Make conditional negative balances test sql re-runnable - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=14836cc> |
| 16:34 |
pinesol_green |
[evergreen|Remington Steed] LP 1198465: More tests for conditional negative balances - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cde1573> |
| 16:35 |
pinesol_green |
[evergreen|Kathy Lussier] LP 1198465: Adapt some language in the negative balance branch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5ee86b> |
| 16:35 |
pinesol_green |
[evergreen|Ben Shum] LP#1198465: Stamping upgrade script for conditional negative balance - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ea55537> |
| 16:36 |
kmlussier |
I never thought I would see the day... |
| 16:36 |
mmorgan |
Woo-hoo!!! |
| 16:37 |
* dbwells |
feels a disturbance in the Force |
| 16:38 |
kmlussier |
Dyrcona: Well, I obviously am not going to give karma to myself! :) |
| 16:38 |
mmorgan |
dbwells: ...as if millions of negative balances suddently cried out in terror and were suddenly silenced. ;-) |
| 16:39 |
dbwells |
mmorgan: that's right :) |
| 16:40 |
kmlussier |
Also, mmorgan++ for doing a fair share of the testing. |
| 16:41 |
kmlussier |
Should I file a follow-up LP bug on the manual adjustments we discussed last week? |
| 16:42 |
dbwells |
remingtron++ # he deserves a little extra, those pesky tests ended up being 1700+ lines of code (repetitive, yes, but still!) |
| 16:42 |
kmlussier |
bshum++ for writing my release note entries for me. |
| 16:43 |
kmlussier |
Looks like it's a karma party day. :) |
| 16:43 |
bshum |
remingtron++ dbwells++ Dyrcona++ kmlussier++ |
| 16:53 |
pinesol_green |
[evergreen|Ben Shum] LP#1454879: Release notes for Account Expiration Date in OPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c6a5404> |
| 16:53 |
bshum |
And also, probably backport. |
| 16:53 |
bshum |
Cause it looks ready to go |
| 16:57 |
pinesol_green |
[evergreen|Mike Rylander] LP#1465385: Fix some syntax issues with make_release - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c05aeb2> |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:02 |
kmlussier |
hmmm |
| 17:04 |
|
edoceo joined #evergreen |
| 17:04 |
kmlussier |
Looks like it's unrelated to new copy locations this time around. |
| 00:36 |
|
eady joined #evergreen |
| 04:38 |
bshum |
kmlussier: Going to test https://bugs.launchpad.net/evergreen/+bug/1198465 later today, got it put together on our test server. |
| 04:38 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 17, heat: 80) [Wishlist,Confirmed] - Assigned to Dan Wells (dbw2) |
| 04:38 |
bshum |
Just one minor note though, one of the library settings in the upgrade script has a typo in it. "overde" instead of "overdue" |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:19 |
|
Bmagic_ joined #evergreen |
| 07:47 |
|
ericar joined #evergreen |
| 07:59 |
|
rjackson_isl joined #evergreen |
| 13:40 |
csharp |
hmm - having an acq issue where my "acq admin" user can't see/interact with the list of providers (Admin -> Server Administration -> Acquisitions -> Providers) |
| 13:40 |
csharp |
as admin, I'm able to see them |
| 13:41 |
kmlussier |
csharp: Has your acq admin user been able to see them in the past? |
| 13:41 |
* csharp |
continues to look in the postgres logs for clues |
| 13:41 |
csharp |
kmlussier: I don't think so |
| 13:42 |
csharp |
the user in question has all of the *_PROVIDER perms assigned at the System level, and the providers are owned by the library system in question |
| 13:42 |
csharp |
(system, not branch) |
| 13:44 |
csharp |
I can also see that the SQL queries are being performed for the providers, but they aren't displaying |
| 13:44 |
csharp |
the user passes all the permission tests I can see being performed in the logs |
| 13:44 |
kmlussier |
This reminds me of an old bug that was fixed a long time ago. |
| 13:45 |
kmlussier |
bug 731510 |
| 13:45 |
pinesol_green |
Launchpad bug 731510 in Evergreen master "Acquisitions - Unable to view providers" (affected: 2, heat: 12) [Medium,Fix released] https://launchpad.net/bugs/731510 - Assigned to Mike Rylander (mrylander) |
| 13:45 |
kmlussier |
csharp: I can't imagine it's the same thing, but if you page through the interface, do you see the providers? |
| 13:48 |
csharp |
kmlussier: nope :-( |
| 13:49 |
kmlussier |
csharp: And the library selector on that page is the same as the OU that owns the providers? Sorry to ask obvious questions. |
| 13:50 |
csharp |
yes, that's right |
| 13:51 |
csharp |
one possible clue (that could be a red herring), the JS console shows "TypeError: item is null" |
| 13:52 |
csharp |
when I look at Open-ILS/web/js/ui/default/acq/financial/view_provider.js, I see the term "item" used - I'm assuming that's what's being referred to in the JS error |
| 13:57 |
csharp |
also 'request open-ils.acq open-ils.acq.provider.org.retrieve <authtoken>' shows the expected list via srfsh |
| 13:57 |
csharp |
which is what is called by that JS library |
| 13:58 |
csharp |
again, if I'm admin, I can see everything as expected, so it *seems* like this should be perms, but I'm not seeing any messages in the logs |
| 13:59 |
csharp |
and all the perms I do see checked appear to be assigned at the appropriate levels (or I wouldn't expect the srfsh test to work) |
| 14:03 |
berick |
csharp: the JS error mentions view_provider.js specifially? |
| 14:03 |
berick |
i think that file might actually be deprecated |
| 14:04 |
berick |
Open-ILS/web/js/ui/default/conify/global/acq/provider.js is loaded by |
| 14:40 |
jeffdavis |
Is that expected behavior? If not, how would you normally expect to prevent it in a load-balanced environment? |
| 14:41 |
bshum |
berick: gmcharlt: For https://bugs.launchpad.net/evergreen/+bug/1394989, we're looking to try implementing the solution that you suggested alternative to mrpeters' patch. If it passes, should we rework that to be a proper git branch and get it submitted towards review and inclusion in a future release? |
| 14:41 |
pinesol_green |
Launchpad bug 1394989 in Evergreen "Collections API users_of_interest can crash on users with null card values" (affected: 1, heat: 6) [Low,Confirmed] - Assigned to Michael Peters (mrpeters) |
| 14:41 |
csharp |
ooh - another point of interest - the problem is *not* happening on our production server, just our acq testing server :-/ |
| 14:41 |
bshum |
mceraso's been poking around at this at Unique's behest and we just found the LP |
| 14:42 |
gmcharlt |
bshum: yes please |
| 14:43 |
mrpeters |
sorry guys, i never caught those comments |
| 14:43 |
bshum |
From the comment, I think we can just grab berick's approach and copy it in, but we'll test and see what blows up :P |
| 14:48 |
miker |
jeffdavis: that load balancing is probably expected, and you probably don't want to prevent it. if the translator is what's initiating it, it's almost certainly because of a stateful connection from the client side, which is required for several interfaces to work correctly. they have to be able to send several messages, possibly through different apache servers, to one opensrf backend. the translator knows how to coordinate that via a memcache blob |
| 14:56 |
jeffdavis |
What we are seeing is that the translator on server A sends an XMPP request to opensrf private.localhost/open-ils.pcrud_drone_server_B, and gets a 503 error in response |
| 15:01 |
miker |
ah, yeah... you'll need to set up real (if internal-only) names and addresses and cross-register services, and set up the <trusted_domains> stuff ... I'll see if there are pointer docs |
| 01:56 |
|
Mark__T joined #evergreen |
| 02:08 |
|
geoffsams joined #evergreen |
| 02:34 |
|
hopkinsju joined #evergreen |
| 05:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:27 |
|
Callender joined #evergreen |
| 07:59 |
|
ericar joined #evergreen |
| 08:22 |
|
Shae joined #evergreen |
| 10:10 |
kmlussier |
berick: If we had a lot of bib records that were appropriate for all of the copy locations you created, I might have felt differently. |
| 10:10 |
kmlussier |
And I do think we need a better set of bib records. But we're not there yet. |
| 10:10 |
berick |
great, my thoughts exactly |
| 10:12 |
kmlussier |
The reason I found the bug was because I had asked jlitrell to look at bug 1340852. Just having any copy location groups in the test data to replicate the bug would have been helpful. |
| 10:12 |
pinesol_green |
Launchpad bug 1340852 in Evergreen "Copy Location Groups search not retaining original search params after searching" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1340852 |
| 10:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1155771 Sample data : copy locations, location groups - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=58aecfd> |
| 10:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1155771 Copy location sample data additions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=406d79e> |
| 11:08 |
bshum |
kmlussier: Well it could be... I suppose. |
| 11:09 |
bshum |
But it seems more like a "from here forward, this is how it is" kind of new feature to me. |
| 11:09 |
kmlussier |
It feels like new feature to me too. |
| 11:09 |
* bshum |
goes back to merging branches for his test system |
| 11:15 |
|
bmills joined #evergreen |
| 11:17 |
berick |
dbs: FYI it worked w/ 2 changes total: http://pastie.org/10309986 |
| 11:18 |
* berick |
just logged in to his VM catalog w/ a salted/crypted password WOOT |
| 13:05 |
kmlussier |
And working on 2 things at the same time, which is never a good idea |
| 13:05 |
jeff |
I'm still in favor of either "Other" or "General". |
| 13:05 |
mmorgan |
Multitasking is highly overrated ;-) |
| 13:06 |
* gmcharlt |
adds "Multitasking Tax" as a billing type to kmlussier's test database ;) |
| 13:06 |
jeff |
and as a refresher, the last large conversation about this subject that i recall was in January: http://irc.evergreen-ils.org/evergreen/2015-01-08#i_148257 |
| 13:06 |
tsbere |
I don't think we should label it as "Staff" myself as that would imply nothing else ever generating them. Same with "Manual", for that matter. "Other" and "General" would work well for me. |
| 13:06 |
kmlussier |
jeff: Yeah, I revisited that when I came up with the original options. |
| 13:23 |
mrpeters |
few kinks to work out still that jeffdavis has helped me with, but man it has to be nice for the patrons once its running! |
| 13:23 |
jeffdavis |
schan wrote most of the code, I just got it over the finish line - but thanks :) |
| 13:23 |
mrpeters |
schan++++++++++++++++++++++++++ too |
| 13:23 |
* kmlussier |
considers moving overdrive-eg-opac testing up on her priority list |
| 13:24 |
mrpeters |
its pretty awesome, anyone using Overdrive should try it out |
| 13:24 |
mrpeters |
i should make a demo video |
| 13:24 |
kmlussier |
mrpeters: Did it take a lot of work to get it working? |
| 16:49 |
kmlussier |
miker: Enjoy your weekend! |
| 16:51 |
* kmlussier |
disappears in a puff of smoke too. |
| 16:51 |
mmorgan |
Have a good weekend! |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:57 |
phasefx |
good way to end a Friday :) |
| 17:01 |
kmlussier |
phasefx: hmmm...could adding copy locations to the sample data affect the pgtap tests? |
| 17:01 |
* kmlussier |
obviously does not know how to disappear |
| 17:02 |
phasefx |
kmlussier: a lot of those live tests make use of the data, so if the data changes, the tests can break. This particular test expected a hold to be permited, but it was not based on a location.holdable flag |
| 17:07 |
|
mmorgan left #evergreen |
| 17:13 |
phasefx |
kmlussier: so the test makes use of item CONC51000640, and the copy location for that item changed from Stacks to Reserves (holdable = f) |
| 17:14 |
phasefx |
easy fix, at least |
| 17:14 |
* phasefx |
out, have a good weekend |
| 17:14 |
kmlussier |
phasefx: You too! |
| 19:23 |
|
bmills joined #evergreen |
| 19:50 |
|
bmills1 joined #evergreen |
| 01:16 |
|
collum joined #evergreen |
| 02:16 |
|
eady joined #evergreen |
| 02:19 |
|
jonadab_znc joined #evergreen |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:44 |
|
ericar joined #evergreen |
| 07:46 |
|
sandbergja2 joined #evergreen |
| 08:07 |
|
jboyer-isl joined #evergreen |
| 11:07 |
mmorgan |
:-D |
| 11:07 |
bshum |
kmlussier: miker: Certainly worth a shot anyways :) |
| 11:08 |
kmlussier |
Ah, yes. The serials template issue. |
| 11:08 |
bshum |
Our problem solving predated copy location groups, and we don't use them anywhere. Yet. |
| 11:08 |
bshum |
Could see how hard it is to make some groups though on a test server to illustrate the idea anyways. |
| 11:08 |
kmlussier |
bshum: I think the one problem with copy location groups is that you need to remember to add any new copy locations to the groups. |
| 11:09 |
bshum |
kmlussier: Yeah we already get fun with that whenever people forget to add new copy locations to the filder group for KPAC. :) |
| 11:09 |
bshum |
"Why doesn't my new kid's book show up in KPAC search?" Because nobody added it to the list of searchable locations... |
| 11:24 |
jeff |
yeah, in reality it was a small set of commits to look over, and it was a missing END :-) |
| 11:27 |
|
Christineb joined #evergreen |
| 11:38 |
miker |
jeff: bisect via %][% ;) |
| 11:54 |
* kmlussier |
discovers bug 1155771 two years late and realizes it would be a very handy thing to see on her test system right now. |
| 11:54 |
pinesol_green |
Launchpad bug 1155771 in Evergreen "Add copy locations, groups (more?) to sample data" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1155771 |
| 11:54 |
|
bmills joined #evergreen |
| 11:59 |
bshum |
kmlussier: Never too late... |
| 13:23 |
bshum |
So i think you're missing something else more major. |
| 13:23 |
bshum |
DPearl: You installed OpenSRF right? |
| 13:27 |
DPearl |
bshum: OpenSRF is in and running. |
| 13:37 |
jeffdavis |
kmlussier: I think we ran into that bug during our upgrade testing, give me a minute to try and dig up our fix |
| 13:41 |
kmlussier |
Thanks jeffdavis! |
| 13:46 |
bshum |
Hmm |
| 13:46 |
bshum |
cat.sip_field() is null |
| 13:47 |
kmlussier |
jeffdavis++ |
| 13:48 |
kmlussier |
I'll get it loaded on a VM and hopefully get a signoff on it today. |
| 13:48 |
kmlussier |
bshum: It's strange, though. Looking at the history of the file, it hasn't been modified since 2012. I wonder why it suddenly became a problem in 2.8. |
| 13:48 |
* bshum |
is testing it too; but can push kmlussier's signoff version when you've tested too |
| 13:48 |
jeffdavis |
Yeah, I never figured out why it wasn't a problem before. |
| 13:49 |
bshum |
Looks good to me. |
| 13:49 |
bshum |
jeffdavis++ |
| 13:51 |
kmlussier |
I don't know what point release they're at. |
| 13:51 |
bshum |
Okay, well then I won't backport unnecessarily |
| 13:52 |
* kmlussier |
could always bring up 2.7 on a VM just to be sure, but thinks we're probably okay there. |
| 13:52 |
bshum |
If you get to test it later, just add a note if we need to backport it further. |
| 13:52 |
bshum |
I'll leave it be for now. |
| 13:57 |
pinesol_green |
[evergreen|Jeff Davis] LP#1477677 - fix JS TypeError that prevents stat cats from displaying in stat cat editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b5a0a74> |
| 14:01 |
jeff |
the marc_xml that /opac/myopac/circs has access to does not contain <attributes>, so displaying format (short of falling back to LDR/06) is not possible |
| 14:18 |
kmlussier |
jeffdavis++ bshum++ #I love it when bugs are fixed on the day they're reported! |
| 14:59 |
jeff |
yep. exactly that. |
| 15:01 |
|
jlitrell joined #evergreen |
| 15:02 |
jeff |
0865 only upgraded holdable_formats WHERE hold_type = 'M' AND fulfillment_time IS NULL |
| 15:05 |
kmlussier |
I just realized berick didn't have a pullrequest on the branch that adds copy locations to the sample data, but I signed off on it anyway because I do think it's useful to have on a test system. |
| 15:05 |
berick |
kmlussier++ |
| 15:06 |
berick |
it was only missing the pullreq becuase i have vague plans to do more with it. it was certainly pull-able |
| 15:06 |
berick |
s/have/had/ |
| 15:43 |
jeff |
csharp++ |
| 15:49 |
jeff |
ah, because we're locally keying off of subjects and such also. |
| 15:57 |
dbs |
csharp++ |
| 16:26 |
jeff |
hrm. also breaks on values like {"0":[{"_attr":"item_type","_val":"a"},{"_attr":"item_type","_val":"t"}],"1":"","2":[{"_attr":"item_lang","_val":"eng"}]} |
| 16:26 |
jeff |
due to the "1":"" |
| 16:27 |
jeff |
note to self: sample/test data needs fulfilled metarecord holds. ;-) |
| 16:34 |
|
bmills joined #evergreen |
| 16:37 |
jeff |
hrm. so 'at--eng' is transformed into '{"0":[{"_attr":"item_type","_val":"a"},{"_attr":"item_type","_val":"t"}],"1":"","2":[{"_attr":"item_lang","_val":"eng"}]}' |
| 16:38 |
jeff |
and that is the most common legacy holdable_formats value in our data |
| 16:43 |
jeff |
the upgrade script didn't generate any values that are invalid json, though... so that's good! :-) |
| 16:48 |
|
buzzy joined #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 18:37 |
|
akilsdonk joined #evergreen |
| 11:57 |
kmlussier |
Yeah, I understand there aren't additional steps. I just know that my three consortia would most likely not give the manual void permission to anyone, and if every other site that prohibits negative balances does the same thing, it may just be extra work, extra options, and extra permissios when we might not need them. |
| 11:58 |
|
mtj_- joined #evergreen |
| 11:59 |
dbwells |
mmorgan: That's correct. |
| 11:59 |
kmlussier |
mmorgan: Yes, and all of most tests showed that the automatic piece was working properly. Of course, I could have missed a test, but I did my best to make it break. :) |
| 12:00 |
kmlussier |
s/most/my |
| 12:00 |
|
Christineb joined #evergreen |
| 12:01 |
dbwells |
We're just trying to figure out how to handle the manual void using the interface. At the very least we need the interface to switch terminology, so that the void option goes away and is replaced with a zero option. Otherwise we just accentuate confusion that they are not the same thing. If we just want to start with that, it makes sense to me. |
| 12:02 |
mmorgan |
Ok, thanks. I'm trying to think of a use case where staff manually voiding a partially paid lost item would expect a negative balance for the amount the patron paid. |
| 13:03 |
gmcharlt |
and ditto for bshum |
| 13:03 |
kmlussier |
gmcharlt: Let's assign RoganH with all the tasks. |
| 13:03 |
* rfrasur |
chuckles |
| 13:03 |
gmcharlt |
inevitable joke is inevitable ;) |
| 13:04 |
gmcharlt |
#topic Status updates / past action items |
| 13:04 |
gmcharlt |
#action At long last, the DIG test VM will be up later this afternoon |
| 13:04 |
kmlussier |
Woo hoo! |
| 13:04 |
gmcharlt |
er |
| 13:04 |
kmlussier |
gmcharlt++ |
| 13:05 |
gmcharlt |
#info At long last, the DIG test VM will be up later this afternoon |
| 13:05 |
gmcharlt |
#info A copy of the webserver VM has been created, http://test-www.evergreen-ils.org/ |
| 13:05 |
gmcharlt |
it's been used to test an operating system upgrade to Debian Jessie |
| 13:05 |
gmcharlt |
as well as a software upgrade for the Piwik web analystics package |
| 13:06 |
gmcharlt |
bshum is still poking at Piwik, but we should be able to schedule a production OS upgrade for the main webserver, lupin, soon |
| 13:07 |
gmcharlt |
so, one of the incidental things from that: the Piwik data for the past few years is consuming a fair amount of disk space on lupin |
| 13:07 |
gmcharlt |
and bshum and I have been discussing pruning it down to just keeping the past year of analytics |
| 13:08 |
gmcharlt |
on the basis that it will save disk space, that the web statistics data have not been really used, and if they were looked at, there's little reason to keep more than a year of them |
| 13:08 |
gmcharlt |
any thoughts about that before we commit to that position? |
| 13:08 |
kmlussier |
A year of stats seems reasonable to me. |
| 13:08 |
phasefx |
sounds good to me |
| 13:09 |
rfrasur |
Is someone tracking the web stats offline? |
| 15:49 |
|
jlitrell joined #evergreen |
| 16:52 |
|
buzzy joined #evergreen |
| 17:02 |
|
buzzy joined #evergreen |
| 17:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:22 |
|
mmorgan left #evergreen |
| 17:51 |
|
bmills joined #evergreen |
| 17:56 |
|
buzzy joined #evergreen |
| 10:07 |
jboyer-isl |
You should hear how some other people have tried to spell it over the years. “Is that wirh a “W”? how many “Y”’s, etc.) |
| 10:07 |
RoganH |
jboyer-isl: I get it with Rogan a lot though you wouldn't think it's that hard to pronounce or spell |
| 10:10 |
RoganH |
jobyer-ils: yeah, the _are functions check to see if there are extra tables/views/whatever and fail the test then |
| 10:10 |
RoganH |
So I lean to including both for more granularity of testing. |
| 10:11 |
RoganH |
Once I've pulled the tables/views/whatever out of information_schema it won't be that big a deal to do both |
| 10:11 |
jboyer-isl |
Yeah, I should have read more closely. In that case I’d be hesitant to use the _are functions because I’m always wary of “it’s ok if X fails” and the like. (Now, I also think anyone adding any tables should do it in a separate schema like local. or similar, but I don’t want to argue about it) |
| 10:12 |
jboyer-isl |
Also, in the “correct” case it’s testing a bunch of stuff twice which I’m also not a big fan of. |
| 10:12 |
RoganH |
jboyer-isl: I can see it both ways. Maybe add the _are tests in a separate subfolder under /t |
| 10:13 |
jboyer-isl |
It’s up to you. More files to maintain = more potential for drift though. |
| 10:13 |
tsbere |
RoganH: Are you doing things by hand? |
| 10:14 |
jboyer-isl |
(It’s tempting to only use _are and badger people into accepting my local. notion, but then schema_are complains and it’s all in shambles now.) |
| 10:14 |
RoganH |
RoganH: not really, most of it is pulling it out of information schema and then having some scripts construct it though I go through and check them. |
| 10:14 |
RoganH |
why am I replying to myself? I'm feeling very self referential. |
| 10:15 |
tsbere |
RoganH: I just seem to recall we already have a script pulling things out of information schema for tests, wasn't sure if you were just adding to that script or not |
| 10:16 |
jeff |
adding new tables in a distinct schema is often good, but I'm pretty sure we have some schemas where local tables are not uncommon -- such as people who audit more tables than are audited in a stock system. |
| 10:16 |
RoganH |
jeff: that was my concern, and one reason I wanted a conversation about it. my first instinct was to say that _are is bad because it will generate errors and then confuse people. Then another part of me wants the granularity. |
| 10:17 |
RoganH |
I think the _are tests can be good but maybe shouldn't be in /t. |
| 10:18 |
RoganH |
Anyway, I'll proceed with tidying up the has_ tests and worry about are_ tests another day. |
| 10:19 |
|
collum joined #evergreen |
| 10:21 |
bshum |
kmlussier: I noticed that problem with the IRC log site after the reboot, but I hadn't quite figured it out yet. |
| 10:21 |
bshum |
Using the full URL for the index will give you the page though: http://irc.evergreen-ils.org/evergreen |
