| 09:29 |
Dyrcona |
heh |
| 09:44 |
|
sarabee joined #evergreen |
| 09:52 |
csharp |
gonna take down the ubuntu and fedora buildslaves for a bit, FYI |
| 09:53 |
* Dyrcona |
plans to look into the failing test. I think the test needs adjustment. |
| 10:12 |
dbwells |
Dyrcona: I think you are right. I peeked at it last night, and we just need to remove the 'e's from the sample record in the test. |
| 10:15 |
dbwells |
I think the test might also read better if the "have" and "want" were swapped, but maybe that's just me. |
| 10:15 |
|
Christineb joined #evergreen |
| 10:20 |
Dyrcona |
In case you didn't know: cpan -u takes a long time to run and updates Perl modules installed from packages as well as those installed via CPAN. |
| 10:20 |
Dyrcona |
At least on Ubunut 14.04. |
| 11:45 |
mmorgan |
sqish, squish, squash - sometimes all are required :) |
| 11:53 |
Dyrcona |
Hmm. I'm starting to wonder if the fix in lp 1484281 was complete.... |
| 11:53 |
pinesol_green |
Launchpad bug 1484281 in Evergreen 2.8 "authority data may be deleted during propagation with current values of authority.control_set_authority_field" (affected: 1, heat: 10) [Critical,Fix committed] https://launchpad.net/bugs/1484281 |
| 11:53 |
Dyrcona |
The test still fails after I "fix" it. |
| 11:57 |
yboston |
Dyrcona: the deletes are still propagating? |
| 11:57 |
Dyrcona |
No, but a test keeps failing. |
| 11:58 |
yboston |
which test? one of mine? |
| 11:58 |
Dyrcona |
Also, there is a display_sf_list field that should probably be changed, and there is a 111 entry that probably needs the change. |
| 11:58 |
Dyrcona |
http://testing.evergreen-ils.org/~live/test.22.html |
| 11:59 |
yboston |
My understanding is that the $e can stay in the 111 according to cataloging rules; will double check |
| 12:00 |
yboston |
for the record, I thought that the display_sf_list was meant to still display the subfields that were found in the auth tag |
| 12:00 |
yboston |
and that I would want to display if the $e is actually there, but not authoirty control the $e in the auth tag, but my interpretation of display_sf_list could ahve been wrong |
| 12:44 |
krvmga |
i'm getting an error in course reserves whenever i click on an item "item_status() takes exactly 2 arguments (4 given)". has anyone run into this? |
| 12:46 |
krvmga |
the exception is coming out of Syrup/conifer/plumbing/hooksystem.py in callhook, line 24 ( which is "return f(*args, **kwargs)" |
| 12:47 |
jeff |
beware the dreaded kwargs. |
| 12:47 |
Dyrcona |
yboston: For fixing the test or anything else that the original patch mixed, I think we want a new bug. |
| 12:47 |
krvmga |
jeff: usually i can snickersnack them but now i'm stumped |
| 12:47 |
Dyrcona |
**kwargs |
| 12:49 |
gmcharlt |
yboston: ah, but upon reading again, yep, the *111* $e is a different beast |
| 12:52 |
jwoodard |
all I want is population stats! |
| 13:08 |
mmorgan |
krvmga: Is this every item, or only some items? Can you share a link, or is a login required? |
| 13:15 |
krvmga |
mmorgan: it's every item. you don't need a log in. go to http://rb.cwmars.org/qcc/browse and click on any title |
| 13:17 |
Dyrcona |
So, it gets weirder with this test. |
| 13:17 |
Dyrcona |
I run the function in the database that pg_prove says is failing and it looks like it outputs what is expected. |
| 13:18 |
Dyrcona |
Think I'll copy and paste it to be certain, or is that cheating? |
| 13:19 |
|
kbutler joined #evergreen |
| 13:23 |
dbs |
Dyrcona: does something else change the state of the db prior to running the failing test, by any chanceÉ |
| 13:23 |
Dyrcona |
dbs: Not as far as I know. I'm using concerto for this test. |
| 13:23 |
dbs |
ah le clavier Canadienne Multilinguel |
| 13:24 |
Dyrcona |
:) |
| 13:25 |
Dyrcona |
I did get the test to pass. I'm about to diff the two versions of the test, but I think the changed part is all one line so the difference may not stand out. |
| 13:25 |
Dyrcona |
I wonder if field order didn't change some where. |
| 13:25 |
Dyrcona |
did/didn't what's the difference? |
| 13:27 |
Dyrcona |
Ah.... |
| 13:30 |
gmcharlt |
nah, purely my fault for not reading ALL of the scrollback |
| 13:30 |
yboston |
Dyrcona: let me know if I can help with anything |
| 13:31 |
yboston |
Dyrcona: I would love to hear miker thouhgts on display_sf_list versus sf_list |
| 13:36 |
Dyrcona |
yboston: I don't think there's anything wrong with your change. The test needs to be updated, but I wonder why I'm getting the name space in every xml element. |
| 13:37 |
yboston |
OK |
| 13:37 |
Dyrcona |
Looking at the source from the failed testing server it is not getting the nameespace in every element. |
| 13:38 |
Dyrcona |
I am going to make the change that I originally thought was needed and push it to a branch after making a launchpad bug. |
| 13:38 |
Dyrcona |
I am inclined to blame different versions of libxml for the name space change. |
| 13:38 |
|
ericar joined #evergreen |
| 10:23 |
Dyrcona |
The branch name disappears once the code is cherry-picked. |
| 10:25 |
yboston |
good to know |
| 10:26 |
Dyrcona |
I'll amend the commit messages to make sure they're prefixed with the proper lp bug if they need it. |
| 10:30 |
Dyrcona |
And, I'm ready to commence testing. |
| 10:44 |
Dyrcona |
So to test this I run authority_control_fields.pl and watch the $e disappear from my target bibs? |
| 10:44 |
Dyrcona |
Meaning that is the behavior before the fix. |
| 10:50 |
|
ericar_ joined #evergreen |
| 10:52 |
|
ericar joined #evergreen |
| 12:04 |
Dyrcona |
And, lunch |
| 12:04 |
|
Christineb joined #evergreen |
| 12:20 |
|
collum joined #evergreen |
| 12:41 |
Dyrcona |
Guess I'll roll up the 2.9-rc so I'll have a little time to test it. |
| 12:44 |
Dyrcona |
Give me some time to figure what happened with bower. |
| 12:53 |
|
ericar joined #evergreen |
| 12:59 |
|
jihpringle joined #evergreen |
| 13:28 |
Dyrcona |
pgardella1: A/T isn't my strong point, but you need to make sure that the events are enabled and the cron jobs are running. |
| 13:29 |
tsbere |
pgardella: Has anyone tried to submit a request? If so, are they running into the max active requests limit? Do they have email addresses on file? |
| 13:31 |
mmorgan |
For reference, here's what transpired yesterday regarding pgardella's question: http://irc.evergreen-ils.org/evergreen/2015-09-01#i_200538 |
| 13:31 |
pgardella |
tsbere: I'm testing my own account. I have an email on file. So has several other library staff. None of us should have hit the max active requests. |
| 13:32 |
pgardella |
mmorgan++ |
| 13:32 |
tsbere |
pgardella: Are there any recent rows in actor.usr_password_reset? |
| 13:33 |
pgardella |
tsbere: nothing since 8/15 |
| 13:33 |
tsbere |
pgardella: That would imply no successful attempts to initiate one |
| 15:18 |
Dyrcona |
Is it something we would want to discuss at a future meeting, or should we drop it? |
| 15:18 |
jeff |
no specific followup other than that. drop it from the next agenda unless further discussion brings it back to the agenda. |
| 15:19 |
Dyrcona |
#agree drop it for now. :) |
| 15:19 |
Dyrcona |
#info ldw will looking into integrating neg. balance tests on test writing day |
| 15:20 |
Dyrcona |
ldw: I think that happened more or less. |
| 15:20 |
ldw |
I did not get the neg balance tests personally. I do not know if someone else worked on it that day. |
| 15:21 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 15:21 |
Dyrcona |
There are some negative balance tests and more can always be added. |
| 15:21 |
Dyrcona |
dbwells or remingtron anything to add? |
| 15:22 |
dbwells |
I think the goal was to reconsider the way they were setup, but that doesn't need to happen with any particular urgency. |
| 15:23 |
Dyrcona |
So, we'll call that one done, too. |
| 15:39 |
Dyrcona |
#topic Evergreen Release(s) |
| 15:39 |
Dyrcona |
So, I'll take an action item right off the bat. |
| 15:39 |
Dyrcona |
#action Dyrcona to release 2.9-rc after the meeting. |
| 15:40 |
Dyrcona |
I just made the tarball this afternoon, loaded it on a test vm with concerto data, and all looks good. |
| 15:40 |
Dyrcona |
I even got it to work with the web staff client. I think that ended up being bad ownership on a directory. |
| 15:41 |
Dyrcona |
So, do we want action items for the maintenance releases in two weeks or is that overkill? |
| 15:42 |
Dyrcona |
I guess that would include 2.9.0 as well. |
| 17:05 |
Dyrcona |
bshum++ |
| 17:05 |
Dyrcona |
Thanks for taking care of that part. |
| 17:05 |
Dyrcona |
Well, time to go. I'll probably be back on later. |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:09 |
bshum |
Dun, dun, dunnnnn |
| 17:09 |
bshum |
Authority test fail |
| 17:10 |
* bshum |
disappears into the mists |
| 17:33 |
jwoodard |
learned glaring at Evergreen does not fix anything |
| 18:15 |
|
Dyrcona joined #evergreen |
| 19:00 |
|
gsams-web 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> |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 07:43 |
|
graced joined #evergreen |
| 07:57 |
|
mrpeters joined #evergreen |
| 09:33 |
jeff |
but i haven't measured that. |
| 09:34 |
mmorgan |
Using the back button, we can see the previous data that had been entered in the form. |
| 09:35 |
mmorgan |
Yours nicely clears that info. |
| 09:35 |
csharp |
quick question - we enabled Google Analytics in the OPAC yesterday, and it worked fine in all the browsers we tested, but we got mixed secure/insecure content warnings in the staff client (until we re-disabled it). Do others see that? How do you handle it? |
| 09:36 |
jeff |
csharp: pretty sure recent commit disables it in the staff client. |
| 09:36 |
tsbere |
csharp: That probably has to do with the oils protocol bit in the staff client for faking out "remote xul" and all. |
| 09:36 |
mmorgan |
lp 1466201 |
| 10:41 |
pinesol_green |
Launchpad bug 1175740 in Evergreen 2.4 "Acq: Certain workflows produce orphaned fund debits" (affected: 2, heat: 14) [Undecided,Incomplete] https://launchpad.net/bugs/1175740 |
| 10:43 |
csharp |
kmlussier: this came to me as "there are acq-orphaned copies floating around in the OPAC", so I haven't investigated deeply enough to know when copies/bibs aren't orphaned |
| 10:44 |
csharp |
in any case, I think Lebbeous's "prompt the user for copy deletion" approach is the best |
| 10:44 |
kmlussier |
Yes, I did some testing around those a while back and reported my results on bug 1269574. Not sure if the behavior has changed since then. |
| 10:44 |
pinesol_green |
Launchpad bug 1269574 in Evergreen "ACQ lineitems canceled via EDI not deleting linked bibs/items" (affected: 8, heat: 40) [Medium,Confirmed] https://launchpad.net/bugs/1269574 |
| 10:45 |
csharp |
kmlussier: oh - I inexplicably missed your comment on that bug :-/ |
| 10:47 |
kmlussier |
In re-reading bug 1175740, it looks like the initial issue reported was that fund debits stuck around if the lineitem was deleted without first being canceled. AFAIK, you can no longer delete lineitems in the UI, which is why I wasn't able to replicate it. |
| 10:47 |
kmlussier |
Of course, we want people to be able to delete lineitems in the UI, but only when they are in the "correct" state. Correct being pending or truly canceled. |
| 10:47 |
kmlussier |
I think that's on another bug. |
| 10:48 |
kmlussier |
So many bugs |
| 10:50 |
Christineb |
We have seen issues very similar to 1175740 - orphaned fund debits - I have it on my list to do additional testing and add notes |
| 10:50 |
Christineb |
so many bugs |
| 10:52 |
csharp |
yep |
| 10:53 |
kmlussier |
Christineb / csharp: If you can identify another scenario that creates orphan debits, let me know. I'll be happy to re-test an set the bug back to confirmed. :) |
| 10:54 |
kmlussier |
I'll also check back with my acq people to see if they are still seeing the problem. |
| 10:54 |
kmlussier |
I think one of our sites was the original source of that bug report from senator. But I could be mistaking it with another one because...so many bugs. |
| 10:55 |
kmlussier |
Speaking of so many bugs, I've been negligent on scheduling a Bug Squashing Day. We usually do one between beta and the full release. |
| 10:55 |
Christineb |
I think for us - when a line item is cancelled/delayed but then later received, an orhphan debit is created for the encumbrance - so we have a fund_debit where encumbrance = false and a fund_debit where encumbrance = true |
| 10:56 |
kmlussier |
Ah, that makes sense. |
| 10:56 |
Christineb |
I will test and add comments |
| 11:09 |
* kmlussier |
just spent 20 minutes typing up an email with a question to the dev list only to realize what the answer was as she was about to hit 'send.' |
| 11:09 |
dbs |
kmlussier: sounds like a blog post to me! |
| 11:09 |
kmlussier |
I think it would have taken less time if I had just talked to a rubber duck. |
| 16:42 |
pgardella |
What cronjob sends it? I've tried manually running the —run-pending |
| 16:46 |
mmorgan |
pgardella: Is your "Password reset request notification" action trigger enabled? It is not enabled by default. |
| 16:48 |
pgardella |
mmorgan: There isn't one in the example, nor listed anywhere I could find. |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:52 |
tsbere |
pgardella: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/950.data.seed-values.sql;h=2532ba552eb1e9ae65e2fff98e45716fed1bad19;hb=master#l8164 |
| 16:52 |
mmorgan |
pgardella: If you look in the database table action_trigger.event_definition, it should be id 20. |
| 16:54 |
pgardella |
Ah. OK. I'll take a look. |
| 16:55 |
pgardella |
mmorgan: it is enabled. |
| 16:57 |
gsams |
pgardella: we gave password resets their own granularity. The cronjob looks like: */1 * * * * /openils/bin/action_trigger_runner.pl --osrf-config /openils/conf/opensrf_core.xml --run-pending --granularity password --granularity-only |
| 16:58 |
mmorgan |
pgardella: does the user requesting the password reset have an email address set in their account? |
| 16:58 |
pgardella |
Yes. I tested it with mine, as have several other library staff. |
| 16:58 |
tsbere |
gsans: Ours is very similar, but we only run it every five minutes instead of every minute. |
| 16:58 |
gsams |
of course, we had problems with A/T working without granularity settings |
| 16:59 |
pgardella |
I'll take a look and make sure the A/T is set up correctly. It looks like it, but I'll verify it against the git commit tsbere sent. |
| 17:04 |
kmlussier |
mmorgan: How often do your action triggers run? What I like about the approach from gsams and tsbere is that the password reset runs quite frequently. |
| 17:04 |
gsams |
mmorgan: We split it into 4 types, with overdue notices being by OU. The others are passwords, holds, and predue notices. |
| 17:05 |
* mmorgan |
checks the crontab |
| 17:05 |
gsams |
I was impatient when testing so I set it to 1 minute and never ended up changing it to 5 which was intended |
| 17:05 |
gsams |
it hasn't been a problem though, so bonus. |
| 17:05 |
kmlussier |
gsams: I think most users expect to receive the password reset immediately, so that seems like a good approach. :) |
| 17:06 |
mmorgan |
Our triggers run every two minutes. |
| 17:06 |
pgardella |
mmorgan: No events have been created since 8/15. Hum. Time to go figure out what we did that day! I'll check back in tomorrow once I talk to the engineers! |
| 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:43 |
|
sarabee joined #evergreen |
| 07:54 |
|
ericar joined #evergreen |
| 08:01 |
|
jboyer-isl joined #evergreen |
| 14:26 |
dbs |
Dyrcona: yeah, I suspect it's a permission issue |
| 14:26 |
dbs |
weird that it shows up in the staff client menu but whatever, i'm a psql guy anyway |
| 14:28 |
dbs |
Yay, set up a "Circ Modifier trumps ALL!" weight and associated it as the default, and it seems to work. |
| 14:28 |
rfrasur |
Ugh, I completely forgot about the GoToMeeting test call, tspindler. My apologies. |
| 14:29 |
bshum |
rfrasur: tspindler: I knew I was forgetting something too... sigh :( |
| 14:29 |
* bshum |
has been in other meetings too |
| 14:29 |
rfrasur |
bshum, I can't blame other meetings, but I did put together 3 telescopes (and only swore twice). |
| 14:31 |
Dyrcona |
bshum++ |
| 14:31 |
Dyrcona |
I had that it all up on my server at some point, but got a new server or something happened and that was all I could find. |
| 14:32 |
Dyrcona |
Anyway, I'm investigating what looks like a permissions issue and this one is surprising to turn up after four years on Evergreen. |
| 14:41 |
tspindler |
bshum: its ok, Chauncey, Yamil and Andrea were on. I think we saw enough of the functionality to report back. We might want to try a large test later to see how its performance is with a larger number. |
| 14:42 |
|
akilsdonk joined #evergreen |
| 14:43 |
|
mmorgan1 joined #evergreen |
| 14:45 |
bshum |
tspindler: Cool deal, thanks for the update. |
| 14:45 |
bshum |
tspindler: I'm curious, presuming you guys were testing on Windows, maybe a Mac from yboston. Did any other OS make it in the mix? |
| 14:47 |
* bshum |
has used GoToMeeting sorta on his android phone, but remembered some oddities with his Ubuntu workstations once upon a time. |
| 14:48 |
jlitrell |
Last I heard was partial html5 support, so it should (kinda) work in lunix too. |
| 14:51 |
dbs |
hmm, maybe the circ weight matrix problem wasn't permssions, according to our logs: Returning method exception with message: An unknown server error occurred |
| 14:51 |
dbs |
fancy! |
| 15:27 |
pinesol_green |
Launchpad bug 1257915 in Evergreen "Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled" (affected: 9, heat: 48) [Medium,Confirmed] https://launchpad.net/bugs/1257915 |
| 16:04 |
jihpringle |
Bmagic: we do that for at least one of our libraries every few months and haven't run into any issues |
| 16:05 |
Bmagic |
jihpringle++ that makes me feel confident |
| 16:05 |
jihpringle |
we did it on our test server first |
| 16:05 |
Bmagic |
right on |
| 16:06 |
jihpringle |
when she gets back from lunch, Christineb is going to try and find our ticket from when we tested this to see if we noted any issues/things to be aware of when testing |
| 16:07 |
|
tspindler left #evergreen |
| 16:08 |
jeff |
jihpringle++ Christineb++ |
| 16:29 |
jihpringle |
Bmagic: just confirmed in our ticket, all we do is change the state to = received and we've had no reports of issues from libraries |
| 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. |
| 12:16 |
yboston |
bshum: thanks! This really helps to see what I need to include in the DB upgrade part of my bug fix |
| 12:16 |
bshum |
the make_release script goes out and grabs all the numbered scripts from the upgrades dir and compiles them. |
| 12:16 |
yboston |
cool |
| 12:16 |
bshum |
so contributors only need to add an upgrade script file. |
| 12:17 |
bshum |
After that, the rest is handled by core committers / RM |
| 12:17 |
bshum |
For the upgrade script file |
| 12:17 |
bshum |
Lately I've seen people leave the number check commented out |
| 12:17 |
bshum |
And that's actually helpful for testing purposes. |
| 12:17 |
bshum |
Or at least it is for people like me, who has potentially multiple branches loaded up at once with test scripts |
| 12:19 |
tsbere |
I believe the number in the upgrade SQL script filenames is the upgrade script version number. If only because it ends up in a column named "version". :P |
| 12:19 |
yboston |
tsbere: thanks |
| 12:22 |
yboston |
bshum: you are reffering to code like: SELECT evergreen.upgrade_deps_block_check('0887', :eg_version); |
| 12:22 |
yboston |
? |
| 12:26 |
bshum |
Yes, that check should be in the file at the beginning. Well after the BEGIN; anyways :) |
| 12:26 |
* bshum |
wanders |
| 12:30 |
Stompro |
yboston, "Insert into yboston.todo values ('stompro', Test Josh's pgtap test public.lowercase because he tested yours")" |
| 12:30 |
Stompro |
yboston, :-) |
| 12:33 |
|
dcmh joined #evergreen |
| 12:33 |
tsbere |
Stompro: I believe you have an unmatched quote error there. And depending on SQL language details, an incorrect quote type error. :P |
| 12:35 |
yboston |
Stompro: you also signed off my accesibility patch too, I am in your debt |
| 12:40 |
* jeff |
is tempted to change the pending patrons call to be atomic in the xulrunner client, or change the ordering of the underlying query to be most-recent-first |
| 12:42 |
tsbere |
jeff: I have been known to create an extra server-side client folder for testing that kind of tinkering when I couldn't make the changes 100% locally and was only seeing issues in production. |
| 12:42 |
tsbere |
jeff: At least in regards to changing to the atomic version |
| 12:42 |
* jeff |
nods |
| 12:43 |
jeff |
i found some immediate relief by deleting some staged users who were 12 or 13 days old (usually we delete at 14) |
| 13:30 |
|
jlitrell joined #evergreen |
| 16:11 |
Stompro |
tsbere++ thanks again for taking a look. |
| 16:13 |
tsbere |
And now someone else tells me I previously told them it worked differently when set to 0 (or less). So I dunno. I probably mis-interpreted something but I have already closed the file. |
| 17:09 |
|
mmorgan left #evergreen |
| 17:18 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:19 |
jeff |
looks like a problem downloading phantomjs. |
| 20:10 |
|
rlefaive joined #evergreen |
| 20:36 |
|
yboston joined #evergreen |
| 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. |
