| 00:45 |
bshum |
@later tell dbs Hmm, for some reason I'm not seeing a webstaff.pot i18n file in Launchpad translations, so I wonder if maybe the sync from your bzr in LP needs some further manual tweaking to get underway. |
| 00:45 |
pinesol_green |
bshum: The operation succeeded. |
| 01:05 |
|
Mark__T joined #evergreen |
| 01:14 |
|
ningalls joined #evergreen |
| 04:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:29 |
|
ningalls joined #evergreen |
| 06:29 |
|
kmlussier joined #evergreen |
| 06:29 |
|
bshum joined #evergreen |
| 06:29 |
|
mceraso joined #evergreen |
| 06:29 |
|
ldw joined #evergreen |
| 06:29 |
|
rangi joined #evergreen |
| 06:30 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 06:32 |
|
TaraC joined #evergreen |
| 06:32 |
|
mceraso joined #evergreen |
| 06:32 |
|
ldw joined #evergreen |
| 10:34 |
Dyrcona |
I could do #1 pretty quickly if you like. |
| 10:34 |
yboston |
on how to write upgrade code |
| 10:35 |
Dyrcona |
bshum++ |
| 10:35 |
yboston |
What I want to learn is what is the proper working branch live cycle |
| 10:35 |
yboston |
like, is it OK for me to just fix that commit and just destroy my branch a recreate it, when is it OK to force push a working branch |
| 10:36 |
yboston |
for now I was juts going to create a fresh branch... |
| 10:36 |
yboston |
then just cherry pick my exisitng commit; fix the bad one, then just add the upgrade code |
| 10:36 |
yboston |
I already have a pgTAP test |
| 10:36 |
Dyrcona |
It is usually OK to force push over a working/user branch. |
| 10:36 |
bshum |
I tend to force push mistakes away, as long as I haven't seen people pick my code up. |
| 10:36 |
Dyrcona |
Generally not OK on a working/collab branch. |
| 10:39 |
Dyrcona |
It's really up to you in your user branch. |
| 10:39 |
yboston |
I had seen the phrse (forced push) in git log; not sure if it is done by git or manually? |
| 10:39 |
dbs |
bshum: hmm, not really sure what's going on with the bzr thing |
| 10:40 |
Dyrcona |
I personally don't have a problem with making a new test branch of my own when a force push happens. |
| 10:40 |
* dbs |
will peek |
| 10:40 |
* Dyrcona |
decides not to pun on bzr/bazaar/bizarre. |
| 10:40 |
yboston |
also, I am crytal clear now that it is OK to force push on a user workign branch, though not on a collab brnach unless coordinated with others |
| 10:42 |
Dyrcona |
The reasoning is partly because only the owner can push to a user branch, but anyone with working access can push to a collab branch. |
| 10:42 |
yboston |
bshum & Dyrcona: thanks for all the info |
| 10:42 |
Dyrcona |
yw yboston. :) |
| 10:43 |
Bmagic |
mmorgan: Did you get that test machine to trigger to lost? |
| 10:43 |
yboston |
Dyrcona: I knew that, but I still wanted to confirm that it is OK to force push after doign a rebase with master on my own user working branch |
| 10:43 |
dbs |
https://code.launchpad.net/~denials/evergreen/master looks like it is plugging along |
| 10:44 |
yboston |
Dyrcona: then again, even though I knew that others could push to collabs, I had not realized how it would be a much bigger no-no to push to a collab branch; thank for helping me lreaize the implications |
| 14:01 |
Dyrcona |
Also faster and based on libxml2. |
| 14:01 |
jeff |
The interesting thing was that given 1000 records, it shifted over time. The first match wasn't always the first record. It changed every X or so. |
| 14:01 |
Dyrcona |
That is interesting. I never noticed that, but I wasn't parsing that many elements. |
| 14:05 |
jeff |
round tripping record to a string and back broke the association and "fixed" things. once i realized what was happening (after making a few test cases) i switched to relative xpath expressions and was happier. |
| 14:05 |
jeff |
but it was a bit confusing at first. |
| 14:05 |
jeff |
once I figured it out I recalled seeing something in the docs, but I think I just found what I was thinking of and it's almost entirely unrelated: ``Note that a string result returned by XPath is a special 'smart' object that knows about its origins. You can ask it where it came from through its getparent() method, just as you would with Elements'' |
| 14:06 |
Dyrcona |
yep. |
| 14:06 |
Dyrcona |
I'm not sure if that behavior is unique to lxml or if it comes from libxml2. |
| 14:10 |
jeff |
I still haven't found where it's documented. I'll let you know if I find out. :-) |
| 14:14 |
|
ningalls joined #evergreen |
| 14:14 |
|
bmills joined #evergreen |
| 14:27 |
jboyer-isl |
People with opinions on tests: I'm torn between simplistic "is there a row with this value in this table" vs actually testing the functionality "if you insert this record, are these fields extracted as expected?" |
| 14:28 |
jboyer-isl |
The functional tests seem more robust (if the rows or tables involved in the back end changes, the test still works) but I didn't know if there was a wider preference. |
| 14:29 |
gmcharlt |
jboyer-isl: testing intent is better than testing implementation details |
| 14:29 |
gmcharlt |
(as a rule of thumb) |
| 14:29 |
jboyer-isl |
That's what I was leaning toward. |
| 14:30 |
jboyer-isl |
I'm likely going to dump the 350+ "is there a row with these 3 fields" tests and replace them with 10-20 of the "are the correct fields extracted from this test marc" variety. |
| 14:31 |
Bmagic |
Dyrcona: About the backdating, I think the library was being misled when the message on the UI contained a date that wasn't what they entered |
| 14:33 |
tsbere |
jboyer-isl: Just ensure you test every combination already in the test set. ;) |
| 14:35 |
jboyer-isl |
tsbere: easy :p "SELECT ok((SELECT * FROM config.upgrade_log WHERE version = 'VERSION MY PATCH APPLIED'), 'fixed fields upgrade'); |
| 14:35 |
jboyer-isl |
;) |
| 14:41 |
bshum |
Bmagic: That's odd... I thought hyphens was fixed for SMS texting a couple versions ago. |
| 15:10 |
jeff |
it's rather trivial to get/guess that with reasonable accuracy. |
| 15:11 |
jeff |
especially if you're targeting a single or small handful of numbers. |
| 15:11 |
hopkinsju |
I wont' speculate about the dificulty or what constitutions reasonable accuracy, but I can say that our OPAC is not required for those attempts to be made. |
| 15:14 |
jeff |
bshum: if you attempt to message an invalid number, you will not be billed. if you attempt to message a number that isn't actually capable of receiving SMS, a lot of the "will i be billed" answer will vary based on the remote provider, the nature of the "why can't this receive SMS", etc. |
| 15:19 |
jeff |
bshum: typically, and on the two tests i just did, if you're sending to a landline you will not be charged. |
| 15:19 |
jeff |
bshum: and perhaps more importantly, you'll know that the message did not go through. |
| 15:28 |
jeff |
hopkinsju: for consortial environments, as long as you didn't mind $1/mo per billed entity, and as long as you could agree on something logical like "home_ou of user pays", billing could be reasonably well sorted out. |
| 15:29 |
jeff |
bonus there would be that the messages would come from a number dedicated to the billed entity, and in the future could do things like actually receive texts, etc, etc. |
| 15:32 |
jeff |
Any other concerns/issues/challenges that come to mind? |
| 15:35 |
|
bmills joined #evergreen |
| 15:36 |
* bshum |
can't think of anything right now, but also feels that Fridays are not his best thinking days. :P |
| 15:36 |
bshum |
Especially Fridays after a nice pizza lunch |
| 17:01 |
mmorgan |
Bmagic: For good measure, I would explicitly set them to False. |
| 17:04 |
mmorgan |
Yay! just tried the scenario from http://irc.evergreen-ils.org/evergreen/2015-08-28#i_199831 with the code from lp 1331174, and the transaction closed :) |
| 17:04 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 17:04 |
jeff |
mmorgan++ testing |
| 17:04 |
mmorgan |
Unfortunately, the mark lost part will need to wait until next week :-( |
| 17:13 |
|
mmorgan left #evergreen |
| 17:24 |
* dbs |
wonders if A/T needs to run to set the penalties that block circ |
| 05:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:14 |
|
rlefaive joined #evergreen |
| 07:45 |
|
collum joined #evergreen |
| 07:56 |
|
rlefaive joined #evergreen |
| 09:34 |
|
john joined #evergreen |
| 09:39 |
Guest3965 |
Hi, I am working on setting up an evergreen instance on ubuntu trusty. When I try to register a workstation with the staff client, I'm receiving 200: OK under version, but 500: Internal Server Error. I've checked the apache and system logs but haven't found anything useful. Does anyone know what might be causing the issue? |
| 09:40 |
Guest3965 |
Sorry, 500: Internal Server Error under status, I mean |
| 09:41 |
jeff |
Guest3965: looks like the nickname "john" was taken, so you've been renamed. |
| 09:42 |
jeff |
Guest3965: apache will return a 500 error in that case if the evergreen opensrf services aren't running (that's the most common cause) |
| 09:42 |
jeff |
Guest3965: I'd stop apache, stop all opensrf services, ensure that both ejabberd and memcached are running (you can restart them, stop/start them, whatever). |
| 09:43 |
jeff |
Guest3965: then, start the evergreen opensrf services. wait for that to be successful, consider using the --diagnostic argument to osrf_control to ensure that they all started. |
| 09:43 |
jeff |
Guest3965: finally, start apache and try the staff client again. |
| 09:44 |
jeff |
Guest3965: if that doesn't work, test with srfsh to ensure that you can successfully log in. |
| 09:44 |
Guest3965 |
Okay, thank you! I'll give that a try now |
| 09:44 |
Guest3965 |
I appreciate the help |
| 09:44 |
jeff |
Guest3965: if neither of those work, you may have a configuration issue with ejabberd or opensrf, etc. |
| 10:10 |
jeff |
docs/TechRef/Circ/custom-best-hold-selection.txt |
| 10:10 |
mmorgan |
jeff++ |
| 10:11 |
jeff |
Stompro: I don't have enough recent/relevant experience in this area to offer much more at this time, sorry. :-) |
| 10:13 |
* mmorgan |
did some testing on this early on. Have some notes somewhere... |
| 10:17 |
* jeff |
refreshed/added some knowledge after all |
| 10:17 |
Stompro |
Is circ_lib the location that the copy currently "lives" at? The term circ_lib just doesn't mean anything to me yet. I'm used to thinking in terms of owning locations for items. |
| 10:18 |
jeff |
Stompro: that table defines what priority is given to each of those attributes when a given hold order is configured. so, in the case of "first in, first out, but holds always go to patrons at the copy's circ lib first", top priority is "hprox" |
| 13:31 |
berick |
i can log in OK |
| 13:31 |
berick |
csharp_athens: chrome? |
| 13:32 |
berick |
chrome and FF both working for me |
| 13:33 |
jeff |
likewise here, including with incognito (testing to make sure my having logged in before wasn't obscuring another error) |
| 13:33 |
jeff |
csharp_athens: draconian firewall between you and webby? |
| 13:33 |
berick |
csharp_athens: could be firewall blocking websocket port. |
| 13:33 |
berick |
jinx |
| 13:33 |
berick |
JS console would show an error |
| 15:07 |
dcmh |
yboston: ok |
| 15:07 |
yboston |
I see that berowskim happened to reply to Stompro, which is perfectly fine |
| 15:07 |
afterl |
yboston: nice tab trick |
| 15:08 |
yboston |
let me try to reply to a bunch of you at the same time, to see if your IRC software/site sounds a ping |
| 15:08 |
yboston |
jacobsd Stompro dcmh loril dkvit: this is a mutliple reply test? |
| 15:09 |
yboston |
sorry I missed some of you |
| 15:09 |
dkvit |
yboston: ooh! I got a sound |
| 15:09 |
yboston |
cool |
| 15:09 |
phasefx |
some IRC clients will also highlight lines that contain your name to better get your attention |
| 15:37 |
yboston |
dkvit: is this what you saw or is it regualr messages that the UI of your IRC cleint/site happens to not make it as clear who is the author? |
| 15:37 |
* SharonD |
just talking to myself |
| 15:37 |
dkvit |
yboston: I think it's that third person thing... |
| 15:37 |
yboston |
ok |
| 15:37 |
yboston |
mmorgan: thanks for the idea |
| 15:37 |
yboston |
so lets recap what we have tried so far... |
| 15:38 |
yboston |
1) replying |
| 15:38 |
yboston |
2) private messages |
| 15:38 |
yboston |
3) karma |
| 15:38 |
yboston |
4) actions/third person voice |
| 15:38 |
yboston |
btw, you hsould all try the third person voice as test |
| 15:38 |
yboston |
*should |
| 15:39 |
* jacobsd |
is thinking in the third person |
| 15:39 |
yboston |
another key concept I wan to show you is how we often do infromal voting on an idea |
| 15:39 |
* dkvit |
a little stressed by the third person/karma thing. Will work through it |
| 16:52 |
jeff |
maybe. |
| 16:53 |
|
vlewis joined #evergreen |
| 16:58 |
jeff |
yup. |
| 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:00 |
|
kmlussier joined #evergreen |
| 17:03 |
|
bshum joined #evergreen |
| 17:03 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 17:06 |
|
jlitrell joined #evergreen |
| 17:07 |
jeff |
doing essentially a no-op batch update (set all these holds to Active when all are active) will end up stripping microseconds because it does an unconditional update. |
| 17:11 |
|
mmorgan left #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:22 |
|
rlefaive joined #evergreen |
| 07:35 |
|
mrpeters joined #evergreen |
| 07:36 |
|
jboyer-isl joined #evergreen |
| 11:00 |
mmorgan |
:) |
| 11:00 |
Bmagic |
Happy Tuesday |
| 11:00 |
Bmagic |
evergreen++ |
| 11:08 |
bshum |
mrpeters: Were you able to replicate Jesse's bug for addedcontent? I'm still processing an upgraded system to test things out, but I didn't see any changes to the source code in that area for quite some time. |
| 11:09 |
mrpeters |
i dont have a 2.8.3 system to test on to verify, but i saw something about a change to added content in release notes for 2.9 beta |
| 11:09 |
bshum |
If not, it might be premature to tell them to file a bug on a potentially serious, but unconfirmed issue |
| 11:09 |
bshum |
mrpeters: Yeah, that's for 2.9 / master, but it was not backported to rel_2_8 |
| 11:09 |
mrpeters |
interesting |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:08 |
|
kitteh_ joined #evergreen |
| 12:17 |
|
bmills joined #evergreen |
| 12:30 |
mmorgan |
Anybody have a 2.9 beta install handy that can test the 90 day Mark Lost action trigger? Barcode CONC4000047 is one to test, it's checked out to user id 5 in the seed data. |
| 12:31 |
mmorgan |
I'm testing lp 1331174 and can't get the 90 day Mark Lost action trigger to work at all, I'm assuming this works fine in beta, and it's either me or the code, but just want to make sure. |
| 12:31 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 12:37 |
Dyrcona |
I have conerto data and the beta still loaded. I can take a look. |
| 12:38 |
mmorgan |
Dyrcona: Thanks! |
| 12:50 |
Dyrcona |
mmorgan: It still work in the beta. |
| 12:51 |
Dyrcona |
works, even. :) |
| 12:51 |
mmorgan |
Dyrcona++ |
| 12:52 |
Bmagic |
mmorgan: are you testing with 2.9 beta? |
| 12:52 |
mmorgan |
Thanks, makes me feel better that the problem is with the code or me. Not sure which of those is more likely ;-) |
| 12:54 |
Dyrcona |
mmorgan: Make sure the event is enabled. It is off by default. |
| 12:54 |
mmorgan |
Bmagic: No, kmlussier built a test server from the branch for the bug. |
| 12:56 |
mmorgan |
Dyrcona: I'll recheck that. Seems like I've had it enabled/disabled and changed the intervals several times. |
| 13:00 |
|
rlefaive joined #evergreen |
| 13:00 |
Dyrcona |
I just enabled the trigger, ran action_trigger_runner.pl --process-hooks --run-pending, and the circulation on the copy mmorgan mentioned went to lost. |
| 13:00 |
Dyrcona |
"Just" meaning all "I did was...." |
| 13:01 |
Dyrcona |
Grr. Fingers don't want to cooperate today. |
| 13:01 |
mmorgan |
Ok, thanks. I'll try exactly that on the test server. |
| 13:27 |
|
ericar joined #evergreen |
| 13:47 |
|
jihpringle_ joined #evergreen |
| 14:17 |
|
rlefaive joined #evergreen |
| 16:11 |
jeff |
another bib that is master on six metarecords has a metarecord fingerprint that seems to show an edit history -- the bib was modified in a way that changed the fingerprint. |
| 16:14 |
jeff |
some of this will date back to open-ils.ingest (now dead and gone) and the days when spidermonkey javascript was generating bib fingerprints. |
| 16:15 |
jeff |
and aside from the usual bugs that you expect to find in all software, metarecords in general were quite hidden for many years (after jspac deprecation and before metarecord support in TPAC) |
| 16:18 |
Bmagic |
jboyer-isl: I tested this theory: Found a group of bibs where the master record is in the group. I updated the MARC of the master record to make the fingerprint be totally different. The master record remained in the group even with a different fingerprint! |
| 16:19 |
Bmagic |
jboyer-isl: I decided to reingest the group, and that took care of it, suddenly the metarecord had a new master bib. However, the differently fingerprinted bib stayed in the group??.... |
| 16:19 |
jboyer-isl |
Delightful. (so to speak...) I was poking around git.evergreen... to see if I could see a hole in the remap logic, that is... slower than actually testing things. |
| 16:19 |
jeff |
i've looked into this before, lightly. |
| 16:20 |
jeff |
(well, "lightly" as in little useful output actually came of my digging) |
| 16:20 |
Bmagic |
It looks like there is an issue with removing members of a group when the fingerprint becomes different than the group. |
| 02:24 |
|
Mark__T joined #evergreen |
| 02:38 |
|
mrpeters joined #evergreen |
| 04:33 |
|
mrpeters joined #evergreen |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:05 |
|
sbrylander joined #evergreen |
| 06:07 |
|
pmurray_away joined #evergreen |
| 07:11 |
|
sarabee joined #evergreen |
| 07:21 |
|
mrpeters joined #evergreen |
| 07:36 |
miker |
bshum: re later from last night, I'll respond to your comment when I get to a real computer, but tldr is "no, there are no concerns about 9.2+, and yes imo it should be pushed". I was hoping csharp would test as the reporter, but such is life and bugs |
| 07:45 |
|
rjackson_isl joined #evergreen |
| 07:47 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
ericar joined #evergreen |
| 08:51 |
|
yboston joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 08:58 |
|
ericar_ joined #evergreen |
| 09:05 |
dbwells |
bshum: thanks for testing. I am guessing you didn't grab enough commits from that branch. There are four by remingtron, but they are proceeded by two of mine, and those have the function you seek. |
| 09:08 |
Dyrcona |
FYI, I usually do a git merge into a development branch when testing. |
| 09:08 |
Dyrcona |
That way you don't miss commits. |
| 09:09 |
Dyrcona |
And, you can can always use https://gist.github.com/Dyrcona/4629200 |
| 09:10 |
Dyrcona |
Just don't use the latter if cherry-picking into a rel_* branch, it'll end up moving over most of master, too. |
| 09:42 |
|
Khanson_ joined #evergreen |
| 09:44 |
Dyrcona |
So, the beta is when the rel_2_X branch gets made, correct? |
| 09:53 |
dbwells |
I think I waited until RC, with the goal of minimizing hassle while focusing on bug fixes, but either way makes sense. In reality, master isn't likely to drift far very fast, so the hassle is really minimal. |
| 09:54 |
mrpeters |
from a personal standpoint, the branch would be nice to have at beta time, as we use it to test our debs |
| 09:54 |
mrpeters |
but, if a tarball is available, that is sufficient too |
| 09:55 |
dbwells |
It would get a "tag" branch in any case, I would think. |
| 10:00 |
|
pmurray joined #evergreen |
| 10:04 |
|
Khanson_ joined #evergreen |
| 10:14 |
csharp |
jeff: :-D |
| 10:15 |
Dyrcona |
bshum removed code from Makefile.am that cleans out existing files because it breaks with fresh installs after the branch is applied. |
| 10:15 |
Dyrcona |
I think we should put those lines back, but add if [ -d .... ] and if [ -f .... ] around the shell code. |
| 10:16 |
Dyrcona |
Or just throw the tests on the line with && in appropriate places. |
| 10:16 |
csharp |
miker: bshum: I'll give bug 1438136 a final poke and will comment on it and/or signoff - sorry for the delay :-/ (yep, life getting in the way) |
| 10:16 |
pinesol_green |
Launchpad bug 1438136 in Evergreen 2.8 "OPAC searching significantly slowed by adding format filters" (affected: 4, heat: 20) [High,Triaged] https://launchpad.net/bugs/1438136 |
| 10:16 |
Dyrcona |
But, maybe, instead of what it does, it should rm existing files for upgrades. |
| 10:33 |
Dyrcona |
berick: Sure thing. I'll probably be asking for help by that point. :) |
| 10:33 |
berick |
k, no problem. and I'm not in any rush, so do your thing :) |
| 10:38 |
|
RoganH joined #evergreen |
| 10:39 |
bshum |
dbwells: I could have sworn I did a merge/rebase when I tested, but you must be right. |
| 10:39 |
bshum |
dbwells: I'll see if I can rectify all that once I get to the office.. |
| 10:39 |
dbwells |
bshum: thanks! |
| 10:40 |
bshum |
No thank you! dbwells++ |
| 10:40 |
Dyrcona |
I'd /like/ to have the tarball on the website by 16:00 EDT. |
| 10:40 |
bshum |
This is what happens when I test at the 11th hour. |
| 10:43 |
kmlussier |
16:00? So how long does that give us to do any last-minute sign-offs? |
| 10:43 |
bshum |
Heh |
| 10:44 |
* bshum |
salutes Dyrcona, "Yes sir!" |
| 10:48 |
Dyrcona |
About 0, I think, but I'm making an exception for that as I consider it part of a feature that is already in. |
| 10:48 |
Dyrcona |
I think I'll note that on the bug, actually. |
| 10:48 |
kmlussier |
OK, then, I think I'll update the release notes to reflect what is there now. |
| 10:49 |
dbwells |
kmlussier: I guess I am more optimistic than Dyrcona, but I don't know how much chance it really has. Testing the code internally now... |
| 10:49 |
kmlussier |
I can always update it when bug 1479107 is done. |
| 10:49 |
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 - Assigned to Dan Wells (dbw2) |
| 10:49 |
kmlussier |
dbwells: I'm on hand to drop everything else to test it when it's ready. :) |
| 10:49 |
Dyrcona |
dbwells: Oh. I don't know how far along you were. |
| 10:49 |
Dyrcona |
s/don't/didn't/ |
| 10:50 |
kmlussier |
Also, the other remaining piece of the negative balance puzzle was bug 1479107 . Just an update to the description for an OU setting if anyone wants to take a look at it. |
| 10:50 |
Dyrcona |
I can test it, too. I'm still waiting on a db reload to finish, so I can add it to my branch with sprint2. |
| 10:50 |
kmlussier |
Wrong bug number apparently |
| 10:50 |
kmlussier |
bug 1479110 |
| 10:50 |
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 |
| 10:50 |
kmlussier |
How do I copy and paste a bug number incorrectly? |
| 10:51 |
jeff |
then when the beta's out, we can REALLY find the bugs. ;-) |
| 10:52 |
jboyer-isl |
I’d also like to stump for bug 1371647 real quick, it’s just a seed data bump (and full tests therefore, Dyrcona changed my mind about that) but not being a bugfix if it’s not in today, it’s 2.9.1 :( |
| 10:52 |
pinesol_green |
Launchpad bug 1371647 in Evergreen "config.marc21_ff_pos_map needs an audit" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1371647 |
| 10:52 |
Dyrcona |
kmlussier: Good typo, though, I've been meaning to look at that one, too. |
| 10:53 |
dbwells |
I guess I'll join the party. If anybody has any extra review eyes, I'd be very happy to see bug 1422379 get in. I have some good display improvements which depend on it, and I feel that biting the bullet it better than stringing it along. |
| 10:53 |
pinesol_green |
Launchpad bug 1422379 in Evergreen "Move money.billing timestamps back to moment of fine" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1422379 |
| 10:55 |
jeff |
dbwells: would the improvements be dampened if the upgrade script doesn't touch ALL billings? i.e., if it were to opt not to change the date on billings on transactions that were closed, or had payments? |
| 10:55 |
jeff |
dbwells: are there interactions with conditional negative billing? |
| 10:55 |
jeff |
dbwells: should we throw it in the beta so it's in there, THEN test the heck out of it? ;-) |
| 10:56 |
dbwells |
jeff: The only billings it /has/ to change are the open ones, i.e. ones which might accrue more overdue files. Otherwise, there will be a ripple in the fine stream. |
| 10:56 |
dbwells |
s/files/fines |
| 10:57 |
kmlussier |
Can I also make a pitch to core committers to review bugs that already have a signedoff tag? http://bit.ly/1E3DGNg |
| 11:23 |
berick |
bshum++ thanks |
| 11:23 |
* berick |
hates making messes |
| 11:23 |
bshum |
Just getting tsbere's fix for amnesty/backdating in first |
| 11:25 |
Dyrcona |
To any of the core committers: Feel free to push anything from test writing day that hasn't gone in, yet. If tests break, we can fix them after. :) |
| 11:25 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1444514: Have amnesty mode override backdate for voiding - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dcdce01> |
| 11:26 |
bshum |
berick: Pushed, thanks |
| 11:26 |
bshum |
berick++ |
| 11:26 |
jeff |
Dyrcona: are you saying those need to go in before beta, otherwise wait until next? |
| 11:26 |
Dyrcona |
No, I'm not saying that. I suppose that they could go in at any time, really. |
| 11:27 |
pinesol_green |
[evergreen|Bill Erickson] LP#1476370 Selfcheck warning template cleanup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8e0fdc5> |
| 11:28 |
Dyrcona |
I s'pose I'm giving a temporary dispensation to not test the tests for the beta. :) |
| 11:28 |
jeff |
hah |
| 11:28 |
jeff |
okay, noted. :-) |
| 11:29 |
berick |
thanks bshum |
| 11:57 |
kmlussier |
miker: Are you around to answer a question about bug 1367926 ? |
| 11:57 |
pinesol_green |
Launchpad bug 1367926 in Evergreen "Add support for (nearly) direct access to the full unapi backend" (affected: 2, heat: 10) [Wishlist,New] https://launchpad.net/bugs/1367926 - Assigned to Kathy Lussier (klussier) |
| 12:00 |
miker |
kmlussier: for a minute, aye. shoot |
| 12:01 |
kmlussier |
I've loaded it on a test vm again. marcxml looks fine, but I still get errors when trying http://mlnc2.mvlcstaff.org/opac/extras/unapi?id=tag::U2@bre/165&format=mods32 in a browser. |
| 12:01 |
kmlussier |
I see your discussion with Stompro. I'm just wondering if that points to a problem or if it's okay because whatever is accessing that data won't be doing it from a browser. |
| 12:02 |
miker |
kmlussier: right. it's perfectly valid xml .. I don't know what firefox's complaint is about |
| 12:02 |
kmlussier |
miker: I get complains from Chrome too. |
| 12:03 |
kmlussier |
miker: Also, for now, it just supports marcxml and mods32, right? |
| 12:18 |
miker |
kmlussier: no, the branch just exposes another facet of some other bug, one we haven't pinned down |
| 12:18 |
bshum |
miker: I'm good with that plan then. |
| 12:19 |
berick |
jeff: i think that should do it |
| 12:19 |
pinesol_green |
Showing latest 5 of 7 commits to Evergreen... |
| 12:19 |
pinesol_green |
[evergreen|Remington Steed] LP#1379815 Add code to assign stat cats on Vandelay imported items - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f974781> |
| 12:19 |
pinesol_green |
[evergreen|Remington Steed] LP#1379815 Add pgTAP test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8df8d6b> |
| 12:19 |
pinesol_green |
[evergreen|Remington Steed] LP#1379815 Add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=97806b5> |
| 12:19 |
pinesol_green |
[evergreen|Remington Steed] LP#1379815 Better error handling - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=303608c> |
| 12:20 |
pinesol_green |
[evergreen|Ben Shum] LP#1379815: Stamping upgrade scripts for vandelay stat cat import - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3cd206a> |
| 12:21 |
bshum |
miker: One thing I can't remember now if I checked for was whether we needed to add a folder for webstaff to contain the translated pot. |
| 12:21 |
bshum |
We might need that in the mix somewhere so that git doesn't forget/destroy things |
| 12:21 |
bshum |
Or maybe that'll get covered when we run the update_pofiles later |
| 12:35 |
jboyer-isl |
OCLC spells that out a little better: http://www.oclc.org/bibformats/en/fixedfield/ltxt.html |
| 12:35 |
miker |
jboyer-isl: one thought: create one ff entry that encapsulates the set, and one for each position (by byte offset). LTxt, uncontrolled, for the whole (for the marc editor) and LTxt1, lTxt2, LTxt3 for use with the coded value map |
| 12:36 |
miker |
think of LTxt as a peer to Date1, and LTxt1 as a peer to Type, say |
| 12:37 |
jboyer-isl |
I see. That should work; I was really hoping to have the FF editor work properly. Sounds like this does that and works as expected. |
| 12:37 |
jboyer-isl |
Guess I’ll be changing that milestone though, that’s not a 1.5 hour job with testing. |
| 12:37 |
jboyer-isl |
Thanks! |
| 12:37 |
jboyer-isl |
miker++ |
| 12:37 |
miker |
np! also... |
| 12:37 |
miker |
marc21-- |
| 12:38 |
miker |
jboyer-isl++ |
| 12:44 |
* jeff |
writes release notes |
| 12:44 |
kmlussier |
jeff++ # Release Notes! |
| 12:45 |
* berick |
is done w/ 0930/0931 |
| 12:45 |
kmlussier |
OK, I'm removing myself as the assignee of https://bugs.launchpad.net/evergreen/+bug/1367926 mainly because I don't feel qualified to test it. |
| 12:45 |
pinesol_green |
Launchpad bug 1367926 in Evergreen "Add support for (nearly) direct access to the full unapi backend" (affected: 2, heat: 10) [Wishlist,New] |
| 12:45 |
kmlussier |
But I think it looks really cool, and the code will remain on mlnc2.mvlcstaff.org for the rest of the afternoon if anyone else wants to look at it. |
| 12:46 |
pinesol_green |
Showing latest 5 of 9 commits to Evergreen... |
| 12:46 |
pinesol_green |
[evergreen|Bill Erickson] LP#1440114 Blanket order release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0938e29> |
| 12:46 |
pinesol_green |
[evergreen|Bill Erickson] LP#1440114 Blanket order pgtap tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2fb0fb3> |
| 12:46 |
pinesol_green |
[evergreen|Bill Erickson] LP#1440114 invoice item type prorate/blanket warning - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b393a14> |
| 12:46 |
pinesol_green |
[evergreen|Bill Erickson] LP#1440114 PO stays open with active blanket charges - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ae9f8cb> |
| 12:46 |
pinesol_green |
[evergreen|Bill Erickson] LP#1440114 Stamping upgrade for Blanket PO - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c6a391d> |
| 12:46 |
dbs |
mmm, blankets |
| 12:46 |
|
jacobsd_ joined #evergreen |
| 12:47 |
kmlussier |
dbs: Are you cold? :) |
| 12:51 |
jeff |
dbs: did you get those early august thunderstorms/winds we got here? |
| 12:51 |
* kmlussier |
still recalls being told in elementary school that she would be using the metric system by the time she was a grown up. |
| 12:52 |
dbs |
jeff: yep, we've had some muggy muggy days |
| 13:01 |
dbwells |
kmlussier: hit some issues in testing :( Still pounding away on it, but looking less likely. |
| 13:02 |
miker |
F = C * 9/5 + 32 ... I actually remembered that! I'm sure I could use that space for something else, though, so ... how to forget it? |
| 13:03 |
jeff |
@praise git-rebase -i |
| 13:03 |
* pinesol_green |
And git-rebase -i raised the report up on high, saying O Lord, bless this thy circ report, that with it thou mayst blow thine enemies to tiny bits, in thy mercy. |
| 13:34 |
kmlussier |
dbwells++ |
| 13:34 |
kmlussier |
Perfect timing! I just finished signing off on something else. |
| 13:35 |
dbwells |
I tried to incorporate the functionality of berick's old branch which focused on just negative bills as well. |
| 13:35 |
kmlussier |
I don't know if anyone took me up on my offer to test the unapi branch on mlnc2, but I'm about to take it down for a few minutes. Or maybe more than a few minutes. |
| 13:36 |
dbwells |
It's a bit more of a rush job than I would like, but unlikely to break anything. |
| 13:38 |
pinesol_green |
[evergreen|Kathy Lussier] lp1479110 Provide more clarity for negative balance settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a3fd9d7> |
| 13:38 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1479110: Stamping Upgrade Script for Negative Balance Settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c8dd43e> |
| 13:58 |
berick |
jeff++ |
| 13:58 |
jeff |
167 images removed. |
| 13:59 |
Stompro |
jeff++ |
| 14:04 |
kmlussier |
dbwells: The adjust to zero option works great. But I'm no longer getting negative balances when I should. Just returned a paid-for lost item with none of the prohibit negative balance settings enabled. |
| 14:04 |
kmlussier |
Still poking at it in case I'm just doing something wrong. |
| 14:05 |
kmlussier |
dbwells: Oh, wait, Never mind. I know what I did. |
| 14:07 |
kmlussier |
Yes, it works! Last negative balance branch tested and ready to be signed off! |
| 14:07 |
jeff |
kmlussier++ |
| 14:07 |
kmlussier |
dbwells++ |
| 14:07 |
jeff |
dbwells++ |
| 14:27 |
|
ericar_ joined #evergreen |
| 14:29 |
bshum |
Releasing 0939... need to fine-tune some upgrade script weirdness first |
| 14:35 |
|
jboyer-isl joined #evergreen |
| 14:36 |
pinesol_green |
[evergreen|Dan Wells] LP#1479107 Move VOID_BILLING perm check to top-level API - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7526df> |
| 14:36 |
pinesol_green |
[evergreen|Dan Wells] LP#1479107 Fix IDL classname for account adjustments - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=637f2a2> |
| 14:36 |
pinesol_green |
[evergreen|Dan Wells] LP#1479107 adjust to zero API - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3e54f24> |
| 14:36 |
pinesol_green |
[evergreen|Bill Erickson] LP#1479107 adjust to zero UI - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d905fd5> |
| 14:39 |
|
buzzy joined #evergreen |
| 14:46 |
pinesol_green |
[evergreen|Bill Erickson] LP#1240119 Safe auth token activity logging - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=697933a> |
| 14:46 |
pinesol_green |
[evergreen|Bill Erickson] LP#1240119 safe auth activity live test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28dfad8> |
| 14:47 |
bshum |
Okay, calling 0939 and meaning it this time! |
| 14:52 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 14:52 |
pinesol_green |
[evergreen|Josh Stompro] LP#1124498 - Patron Notice when account expires - fixes and enhancements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1532a1b> |
| 15:30 |
dbwells |
♪ ♫ "It's on-ly six months a-way" ♪ ♫ |
| 15:34 |
* bshum |
felt small tugs on his heart strings with that |
| 15:35 |
* bshum |
plays the world's smallest violin for missed features |
| 15:36 |
Dyrcona |
My arm is tired, so I had to call it, and there's not enough time to smoke test everything. |
| 15:37 |
jboyer-isl |
YAAAAASSSS. Victory in my tilting at fixed windmills. Shame I couldn’t have figured this out sooner, but I’ll be ready for 2.9.1 at least. |
| 15:38 |
kmlussier |
dbwells: I'm much happier about singing that song than I was the last time you sang it. :) |
| 15:39 |
dbwells |
heh |
| 15:41 |
Dyrcona |
Well, one last i18n commit before rolling a tarball, I guess. |
| 15:44 |
pinesol_green |
[evergreen|Ben Shum] LP#1484650: Add webstaff as an i18n target - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d0f1146> |
| 15:46 |
dbwells |
Dyrcona: It can wait, but depending on where you're at, I pushed a couple more tests to flex the neg balance API bits: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=227af4a527c19c660315cd14f2a6e8a115d8558d |
| 15:47 |
bshum |
:) |
| 15:48 |
* kmlussier |
forgot to commit the neg balance release notes. |
| 15:48 |
* kmlussier |
forgot where she put the negative balance release notes. |
| 16:26 |
kmlussier |
berick: Yes, I'm just working on them now. Was focused on other things earlier. Sorry. :( |
| 16:26 |
berick |
kmlussier: that's quite alright. i just had a moment of confusion as to what was happening |
| 16:28 |
dbwells |
The HeadURL was a subversion thing, so it isn't a big deal to get right. I just figured if we were going to shoehorn a URL into that spot, it might as well be one which works. |
| 16:29 |
bshum |
dbwells: Yeah I'm happy with that. |
| 16:29 |
bshum |
I think we should commit that changeset to master and backport to everywhere |
| 16:29 |
bshum |
I'm testing mine with it now |
| 16:29 |
berick |
it's in master and 2.8 |
| 16:30 |
dbwells |
ah, ok |
| 16:30 |
dbwells |
I couldn't remember, either. |
| 16:47 |
bshum |
We should add that step directly onto the wiki page |
| 16:49 |
berick |
i'm on there, i can add it |
| 16:50 |
bshum |
berick++ cool, thanks |
| 16:50 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:50 |
bshum |
I'm uploading the tarballs for 2.7.7 now. |
| 16:55 |
bshum |
Aww, it's time to pull 2.6 off the downloads page. |
| 16:55 |
bshum |
End of an era. |
| 17:04 |
berick |
it's intermittent. even browser-Back button causes it to happen |
| 17:05 |
berick |
hope it's just me |
| 17:05 |
dbs |
maybe you're in a time warp, and jumping in and out of the cert's valid date range with each click |
| 17:05 |
bshum |
berick: *sad face* |
| 17:05 |
bshum |
berick: I'll be refreshing our main test server tomorrow with master |
| 17:05 |
bshum |
So I'll tell you if I see weirdness too :\ |
| 17:05 |
RoganH |
Has anyone had requests to use the patron self registration to give out a barcode immediately to patrons through the OPAC interface? |
| 17:07 |
berick |
RoganH: i've heard people discuss it in general terms. i don't know if anyone's trying to pursue it |
| 17:07 |
dbs |
berick: is your site HTTPS only? I'm still getting console errors for the Google Books Preview loading, which tries to send an HTTP request (grr) |
| 18:37 |
Dyrcona |
I still get fatal error unable to find local grunt. |
| 18:37 |
|
afterl left #evergreen |
| 18:54 |
|
artunit_away joined #evergreen |
| 19:24 |
kmlussier |
So I guess it's a good sign that our qa tests were successful after all the merging that happened today. |
| 19:30 |
bshum |
Heh, probably |
| 20:02 |
kmlussier |
New app that works with Evergreen - https://play.google.com/store/apps/details?id=com.thehoick.evergreenwishlist |
| 20:02 |
kmlussier |
We should put up a wiki page that lists Evergreen-related apps. |
| 00:15 |
|
bmills joined #evergreen |
| 01:39 |
|
Mark__T joined #evergreen |
| 04:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:32 |
|
artunit_away joined #evergreen |
| 07:02 |
|
jacobsd joined #evergreen |
| 07:20 |
|
rlefaive joined #evergreen |
| 07:35 |
|
jboyer-isl joined #evergreen |
| 07:48 |
|
mrpeters joined #evergreen |
| 07:57 |
|
jacobsd_ joined #evergreen |
| 08:00 |
jacobsd_ |
Good Morning. First time here. Testing a Kindle app and drinking coffee. Lots of coffee. |
| 08:16 |
|
eby joined #evergreen |
| 08:20 |
|
ericar joined #evergreen |
| 08:27 |
kmlussier |
Good morning jacobsd_. Welcome! |
| 09:05 |
|
maryj joined #evergreen |
| 09:06 |
|
jwoodard joined #evergreen |
| 09:12 |
Dyrcona |
gmcharlt++ kmlussier++ # For following up on bugs last night. |
| 09:16 |
kmlussier |
berick: I'm testing bug 1440114 this morning, but I was also wondering if a test is needed for that code. |
| 09:16 |
pinesol_green |
Launchpad bug 1440114 in Evergreen "Support "blanket" orders in acquisitions via direct charges" (affected: 1, heat: 8) [Wishlist,New] https://launchpad.net/bugs/1440114 - Assigned to Kathy Lussier (klussier) |
| 09:16 |
* kmlussier |
still doesn't have a good handle on how to determine if a test is needed and, therefore, may be asking that question a lot this week. |
| 09:18 |
* kmlussier |
is also setting a goal to get acq data in the Concerto dataset before the 2.10 release so that she doesn't have to continually create funds & providers every time she tests acq. |
| 09:19 |
berick |
kmlussier: hm, yeah, a pgtap test at minimum. i can look at that today |
| 09:19 |
berick |
thanks for testing |
| 09:19 |
|
akilsdonk_ joined #evergreen |
| 09:20 |
|
RoganH joined #evergreen |
| 09:20 |
|
yboston joined #evergreen |
| 10:58 |
|
jcamins__ joined #evergreen |
| 10:59 |
Dyrcona |
Well, fr_fr is AZERTY. |
| 11:05 |
|
csharp joined #evergreen |
| 11:07 |
bshum |
jeff: Well, for fun note, make install fails on the jspac removal branch because it tries to copy the jspac files and fails to do so |
| 11:10 |
|
bmills joined #evergreen |
| 11:12 |
|
eady joined #evergreen |
| 11:12 |
|
mtj_ joined #evergreen |
| 11:13 |
bshum |
I think it draws from webcore-install in Open-ILS/web/Makefile.am |
| 11:14 |
bshum |
The last step there is a cd to the different dirs for legacy web |
| 11:14 |
bshum |
And that fails cause we're removing most of them |
| 11:15 |
* bshum |
rebuilds without that for i loop to test |
| 11:17 |
|
bmills1 joined #evergreen |
| 11:17 |
bshum |
That worked at least. |
| 11:18 |
bshum |
Though we probably should go back and gut that Makefile to remove unnecessary bits |
| 11:18 |
* bshum |
builds a staff client to test interfaces |
| 11:18 |
|
bmills joined #evergreen |
| 11:27 |
kmlussier |
berick: In my last comment on the blanket bug, please replace any mentions of "standing order" with the word "blanket." |
| 11:27 |
* kmlussier |
hasn't had her coffee yet this morning. :/ |
| 12:32 |
pdot |
*has all |
| 12:32 |
|
jwoodard joined #evergreen |
| 12:35 |
kmlussier |
pdot: Yes, but it could be another way that the bug manifests itself. |
| 12:35 |
* mmorgan |
did not consider that the bug might be an issue with primary and secondary permission groups as well. Will need to test some more... |
| 12:45 |
mrpeters |
so, come to find out, we're already giving a hint about the password -- Open-ILS/src/templates/opac/myopac/update_password_msg.tt2 |
| 12:45 |
mrpeters |
Note: The password must be at least 7 characters in length, contain at least one letter (a-z/A-Z), and contain at least one number. |
| 12:46 |
mrpeters |
so my patch will only touch the config.org_unit_setting_type with a hint to update that template if you make a change to the regex |
| 14:26 |
jihpringle |
we found that sometimes we had to go through the MARC file and then would find that suddenly the vendor had a typo in a fund code |
| 14:26 |
RoganH |
Sometimes it's useful just to have reaffirmation that my suspicions are right. And yep, it looks like the fund codes got changed. |
| 14:26 |
jihpringle |
I want to say that once there was an extra space before one of the fund codes that threw everything |
| 14:27 |
pdot |
so I've decided to try creating another global admin account to test stuff out, still no luck with add a new patron. could someone tell my the privs required, and their default values? |
| 14:28 |
jihpringle |
I don't know what is actually possible, but long term it would be nice to have the error message at least point you to what it didn't like in the MARC file |
| 14:28 |
jihpringle |
it shouldn |
| 14:29 |
jihpringle |
pdot: it shouldn't affect a gobal admin account, but do you have a working location assigned? |
| 14:44 |
pdot |
hmm, neither seem to function for me, could this have something to do with circulation policy? |
| 14:51 |
mmorgan |
pbot: circulation policies shouldn't prevent you from adding a user. |
| 14:52 |
|
jlitrell joined #evergreen |
| 14:52 |
pdot |
alright, I think I have a hunch as to what my issue is, will confirm in a minute |
| 14:53 |
|
jihpringle joined #evergreen |
| 14:55 |
pdot |
so, I think it's because my schema has no ou at the system level. If I'm correct in assuming that the ACL is a database value comparision, anything at the system level might not be applying |
| 14:56 |
pdot |
in short, my setup looks like consortium > branch1 & 2 |
| 14:57 |
pdot |
as I only have test records at this point anyway, I suspect a DB wipe is in order |
| 14:58 |
kmlussier |
pdot: I don't know the details on this, but I think I've heard it's best to use, at a minimum, the consortium -> system -> branch hierarchy. We have one site that has added a level, but I don't think you want fewer than those three. |
| 15:02 |
pdot |
yeah, I think that's for the best. if my rebuild fixes the issue, I'll make a note for future documentation |
| 15:22 |
|
jonadab_znc joined #evergreen |
| 16:04 |
tsbere |
@weather 01834 |
| 16:04 |
pinesol_green |
tsbere: The current temperature in King St, Groveland, Massachusetts is 87.6°F (4:03 PM EDT on August 18, 2015). Conditions: Overcast. Humidity: 60%. Dew Point: 71.6°F. Pressure: 29.98 in 1015 hPa (Falling). |
| 16:04 |
* tsbere |
glares at web browser not being able to load several weather sites due to a local routing issue |
| 16:06 |
pdot |
locale test! |
| 16:06 |
pdot |
@weather n0b1e0 |
| 16:06 |
pinesol_green |
pdot: The current temperature in Ayr, Ayr, Ontario is 78.1°F (4:06 PM EDT on August 18, 2015). Conditions: Mostly Cloudy. Humidity: 71%. Dew Point: 68.0°F. Pressure: 29.92 in 1013 hPa (Falling). |
| 16:07 |
pdot |
a most useful bot |
| 16:07 |
jlitrell |
Huh, that's cool. |
| 16:10 |
pdot |
all I know is, they're equal when it's -40 out (a not uncommon occasion here) |
| 16:11 |
jlitrell |
Ahh, memories of my youth. I think that's why I enjoy stories of people walking out of Siberia. Reminds me of waiting for the bus in Edmonton. |
| 16:11 |
pdot |
ha, I have spent a few weeks in leduc |
| 16:13 |
Stompro |
Hello, does anyone know how man requests a second their EG front end servers can handle loading the default page? I'm just doing a little testing with the apache bench (ab), and i'm seeing about 11 request/second per server, 20 request/sec through our load balancer. |
| 16:17 |
bshum |
Stompro: I haven't tested that lately. |
| 16:17 |
bshum |
The last time I tried, I knocked out some servers by asking for like 1000 pages at once.... |
| 16:17 |
bshum |
But I feel like hopkinsju and/or Bmagic talked about that stuff once upon a time. |
| 16:18 |
bshum |
I wonder if they have better metrics for that sort of thing now. |
| 16:19 |
bshum |
gmcharlt: So I think that the 2.9 merge for web client sprint2 looks okay. I'm going to wait for Dyrcona to double-check, but I can see the major change between that and the time I last tested was the new copy/volume editing pieces. |
| 16:19 |
Stompro |
I was doing 1000 requests, 32-64 at a time. It looks like it is cpu bound on my hardware. |
| 16:19 |
bshum |
And none of that seems to touch any existing perl/XUL/SQL code, so I don't think it'll break anything to push that along. |
| 16:19 |
bshum |
The ordering of the sql upgrades is handy too, I'd just been guessing at it while testing. |
| 16:21 |
bshum |
berick++ # cool, glad your tests on jspac removal looked good too. |
| 16:22 |
kmlussier |
I have a question about the changing of labels in the acq admin menu that I was discussing with jihpringle earlier? If I change the labels, should I also change the accesskey to something that is more suitable for the new label? |
| 16:23 |
kmlussier |
Or do you think there are users that are accustomed to using the old accesskeys? I don't imagine they are visiting either of these interfaces very often. |
| 16:23 |
bshum |
I think it makes sense to use a key that matches the label. |
| 17:43 |
kmlussier |
remingtron++ |
| 17:43 |
pinesol_green |
[evergreen|Kathy Lussier] lp1486252 Change label for acq admin menu - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3793dde> |
| 17:55 |
jeffdavis |
kmlussier++ # thaks for the reminder about release notes |
| 18:12 |
bshum |
Hmm, I find myself confused now... |
| 18:13 |
bshum |
remingtron / dbwells: Looking over at https://bugs.launchpad.net/evergreen/+bug/1379815 and testing it, but I can't seem to see the stat cat data field during holdings import profiles. |
| 18:13 |
pinesol_green |
Launchpad bug 1379815 in Evergreen "Assign stat cats during Vandelay import/overlay of items" (affected: 1, heat: 8) [Wishlist,New] |
| 18:13 |
bshum |
I checked and my fm_IDL.xml has the proposed changes in there |
| 18:13 |
bshum |
and i would have thought that to update the dojo generated table accordingly, but wacky, weird, nothing seems to show up. |
| 18:20 |
bshum |
Hmm, yep, it should have shown up, since we altered viiad in fm_IDL.xml |
| 18:20 |
bshum |
That's super annoyingly weird... |
| 18:21 |
kmlussier |
bshum: I just loaded that on a VM today. I can take a look later. |
| 18:21 |
bshum |
kmlussier: I'm going to clear my cache and restart everything one more time just to be sure. |
| 18:21 |
bshum |
kmlussier: But thanks, I appreciate any insights you've got later. |
| 18:22 |
bshum |
This is admittedly an area of Evergreen I'm a little weaker on :( |
| 18:22 |
bshum |
Oh, nevermind there it is. |
| 18:22 |
bshum |
Maybe I had to copy it to both fm_IDL.xml files... |
| 18:23 |
bshum |
The one in /openils/conf and the one under /openils/var/web/reports/ |
| 18:23 |
bshum |
Wacky |
| 18:23 |
* bshum |
carries on with exploding his test server with nonsense |
| 18:25 |
bshum |
"Dancing *after* dinner!" |
| 18:25 |
* bshum |
goes to eat first. |
| 18:57 |
|
jihpringle_ joined #evergreen |
| 20:30 |
kmlussier |
Ugh. Why am I getting a conflict on berick's blanket order branch when he just rebased it today? |
| 20:45 |
bshum |
Maybe the progress bar changes touched the same files? |
| 22:24 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1450561: Restore org. unit settings history limit function and trigger - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=34337bd> |
| 22:24 |
pinesol_green |
[evergreen|Ben Shum] LP#1450561: Stamping upgrade script for library settings editor history limits - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=88e32ab> |
| 22:28 |
bshum |
Calling 0926 |
| 22:34 |
pinesol_green |
[evergreen|Dan Pearl] LP#1204671 Allow fund tags to remain attached to new fund during end-of-year propagation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6fe3bbe> |
| 22:34 |
pinesol_green |
[evergreen|Ben Shum] LP#1204671: Stamping upgrade script for fund tag propagation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a0ecf9> |
| 22:42 |
pinesol_green |
[evergreen|Bill Erickson] LP#1481036 Ignore future backdates (part 2). - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dd8f8d5> |
| 22:42 |
pinesol_green |
[evergreen|Bill Erickson] LP#1481036 Ignore future backdates live test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c22cd51> |
| 22:57 |
bshum |
@later tell tsbere Need a rebase on https://bugs.launchpad.net/evergreen/+bug/1444514 for master only. The code is fine for rel_2_8 and rel_2_7, but didn't apply to master because of some changed code. Will try to get that sorted before release cutting tomorrow, pushed the fix through to the older branches for now. |
| 22:57 |
pinesol_green |
bshum: The operation succeeded. |
| 22:57 |
pinesol_green |
Launchpad bug 1444514 in Evergreen "Amnesty Mode doesn't work correctly with Backdating" (affected: 2, heat: 10) [Medium,Confirmed] |
| 23:05 |
bshum |
Calling 0927 |
| 23:06 |
jeff |
bshum++ |
| 23:07 |
kmlussier |
bshum++ |
| 23:08 |
bshum |
I just get nervous about bugs which only work on newer PostgreSQL versions. |
| 23:08 |
bshum |
Mostly in that I only run the newer PG 9.3 now, and so I don't test on PG 9.1 anymore :\ |
| 23:08 |
bshum |
Anyways... |
| 23:08 |
pinesol_green |
[evergreen|Dan Wells] LP#1419172 Optimize full_circ_count view to avoid seq scans - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=54eb62a> |
| 23:08 |
pinesol_green |
[evergreen|Ben Shum] LP#1419172: Stamping upgrade script for optimizing full circ count - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0cbc35b> |
| 23:10 |
pinesol_green |
[evergreen|Dan Scott] LP1431541: SRU UTF8 encoding issues - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=81e6929> |
