| 10:50 |
kmlussier |
krvmga: No, I don't think it is. The bug report is unclear. |
| 10:50 |
Dyrcona |
No, I'm asking krvmga. |
| 10:50 |
krvmga |
maybe i should add a note to that bug |
| 10:50 |
kmlussier |
You're seeing the eresource result on the first screen. And that's consistent with what I found when I tested the bug. |
| 10:50 |
kmlussier |
But then, when you click into the results, that's where the e-resources aren't showing up. |
| 10:50 |
krvmga |
kmlussier: yes |
| 10:50 |
Dyrcona |
We find that e-resources on transcendant sources show up where you might not want them. |
| 10:50 |
kmlussier |
In your case, there is just one other record, so it's immediately jumping to that. So I think it's a spin on that bug. |
| 16:34 |
miker |
if I'm reading it right, of course |
| 16:36 |
miker |
if so, a facet_xpath should be able to grab just <title> and not <partNumber> |
| 16:36 |
miker |
(but, again, docs...) |
| 16:37 |
* jeff |
nods |
| 16:38 |
* jeff |
tests |
| 16:45 |
Stompro |
miker, our series titles are stored with 490[ind1=0], so that shouldn't be an issue. |
| 16:46 |
berick |
hmm, in all the discussion of negative balances, has there ever been any talk of avoiding a negative balance only when it's negative because of a forgive payment? |
| 16:46 |
miker |
if I'm, indeed, correct, you could set the facet_xpath to "//*[local-name()='title']" on the series title index definition, then. my tuits are lacking for testing, but give it a try? |
| 16:47 |
miker |
berick: specifically a money.forgive_payment row? I don't thinks so |
| 16:47 |
berick |
for example, if a patron returns a lost item they paid for, they get the money back. but, if a patron returns a lost item whose charge was forgiven, they don't |
| 16:47 |
berick |
miker: right |
| 16:47 |
kmlussier |
berick: We made a distintion between overdue balances and lost items. No talk of forgive fines in discussions I've been involved in. |
| 16:57 |
kmlussier |
There's this http://wiki.evergreen-ils.org/doku.php?id=scratchpad:negative_balances . But then I forgot that I wrote that, so I then did this several months later. http://wiki.evergreen-ils.org/doku.php?id=qa:billing_test_cases |
| 16:57 |
jeff |
kmlussier++ thanks |
| 16:58 |
jeff |
kmlussier: anything else, before you presumably start your weekend? |
| 16:58 |
kmlussier |
The latter is what remingtron referred to when adding some of the live tests with the code. |
| 16:58 |
kmlussier |
Weekend? What's that? |
| 16:58 |
kmlussier |
Nope. That's all. |
| 17:03 |
miker |
Stompro: reingest a record (save it in the marc editor) and search again with a cache killer (put "-sdflkklsdaklsdf" without quotes at the end of the search string) |
| 17:05 |
miker |
berick: entirely unrelated to your topic, we can't cause the webstaff to set is_staff in mod_perl today (and cause staff searches in the embedded opac) because it will force an oils: protocol. correct? |
| 17:07 |
miker |
well, and because it's currently done via an http header |
| 17:12 |
miker |
hrm... ok... thanks. seeing bugs where they don't be. pardon the noise |
| 17:14 |
miker |
and, yep. ye olde "no workstation" prob |
| 17:28 |
Stompro |
miker, no change after reingesting ~10 records and using the cache killer line. Thanks for the help though, I'll keep trying various things. |
| 17:29 |
miker |
np, thanks for testing |
| 17:34 |
|
bmills joined #evergreen |
| 18:06 |
|
Dyrcona joined #evergreen |
| 18:07 |
|
Dyrcona left #evergreen |
| 14:33 |
yboston |
Stompro++ |
| 14:33 |
yboston |
jihpringle: works for me |
| 14:34 |
yboston |
#action jihpringle will send out an email to the list to ask DIG memebers to sign up for pending 2.9 new featutres |
| 14:34 |
* kmlussier |
should start documenting new features while she's testing them. |
| 14:35 |
yboston |
remingtron: about deciding if a new feature/release not entries needs docs. maybe we can team up to make that assesment together? |
| 14:35 |
yboston |
remingtron: so we can save volunteer time? |
| 14:35 |
remingtron |
yboston: yes, I can help with that |
| 14:36 |
yboston |
cool |
| 14:36 |
yboston |
#action yboston & remingtron will asses which 2.9 new features do not require new documentation |
| 14:37 |
yboston |
I'll send you an email |
| 14:37 |
Stompro |
If anyone wants to test out the adding adoc to the release notes commit, that would be appreciated. LP 1482336 |
| 14:37 |
pinesol_green |
Launchpad bug 1482336 in Evergreen "create_release_notes.sh include .adoc files" [Undecided,New] https://launchpad.net/bugs/1482336 |
| 14:38 |
yboston |
#action yboston will test and sign-off on Launchpad bug 1482336 - allowing release notes with ".adoc" suffix |
| 14:38 |
pinesol_green |
Launchpad bug 1482336 in Evergreen "create_release_notes.sh include .adoc files" [Undecided,New] https://launchpad.net/bugs/1482336 |
| 14:38 |
yboston |
anything else on 2.9 new features? |
| 14:39 |
remingtron |
regarding the .adoc conversion testing, I think we found a reason to halt |
| 14:39 |
yboston |
the git history concern? |
| 14:40 |
remingtron |
yes, git can track history across file name changes, but only if you use an additional command line parameter |
| 14:41 |
yboston |
remingtron: darn, I thought it would do it automatically |
| 14:42 |
yboston |
what is the parameter? |
| 14:42 |
remingtron |
Stompro: yes, I think we should encourage using .adoc for new files |
| 14:43 |
remingtron |
yboston: the parameter is --follow, like 'git log --follow' |
| 14:43 |
yboston |
have we tested that Robert's ascidoc parsing code can handle it? |
| 14:44 |
yboston |
remingtron: had no idea, but I am no git expert. all tutorial made it sound that renaming would "just work" if I used "git mv" |
| 14:44 |
remingtron |
yboston: I guess it works from some perspectives, but not the git log view |
| 14:44 |
Stompro |
yboston, when something gets included from the root.txt I don't think the parser knows what the file extension was, so it shouldn't matter. |
| 14:45 |
remingtron |
yboston: yes, the official docs already include an .adoc file |
| 14:52 |
yboston |
the good news/bad news of all the new content that we pushed probably broke something in the PDF build |
| 14:53 |
yboston |
I will set a generic action item to have folks look into it |
| 14:53 |
remingtron |
hm, guess we should email Robert to ask what errors he's seeing |
| 14:53 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script and test file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9298b2> |
| 14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 libdbi DATE types translated via gmtime - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c42d4c> |
| 14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 DoB as date PGTAP test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e174b43> |
| 14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 Store date of birth as SQL DATE type - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7159229> |
| 14:54 |
yboston |
#action need volunteers to see why the 2.9 and the master/dev PDF is not being built |
| 14:54 |
yboston |
#action yboston will send Robert an email to check on problems with 2.9 and master PDF |
| 14:56 |
yboston |
I need to attend a meeting at 3 PM EST |
| 14:56 |
yboston |
final thoughts or questions? |
| 14:56 |
jihpringle |
is it just the MassLNC demo server running on 2.9? (I want to include a link in the email to where people can test features to document if they don't have their own 2.9 server) |
| 14:56 |
kmlussier |
Do we know when it stopped building? |
| 14:56 |
remingtron |
kmlussier: not sure we have that info besides Robert |
| 14:56 |
kmlussier |
Yes. The MassLNC demo server is running 2.9 and the ESI server is running 2.8. We coordinated this time around so that we would have the two stable releases on demo servers. |
| 08:08 |
|
ericar joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:39 |
|
Dyrcona joined #evergreen |
| 08:49 |
jeff |
thought exercise for the day: anonymizing live data for testing purposes. |
| 08:53 |
|
Shae joined #evergreen |
| 08:54 |
Dyrcona |
jeff: Fill names and addresses with pseudo-random noise. |
| 08:54 |
Dyrcona |
Ditto if you have ID fields and phone numbers. |
| 08:54 |
Dyrcona |
Email addresses, too.... |
| 08:54 |
Dyrcona |
Hmm.. Sounds like it could be a big project. |
| 08:58 |
tsbere |
jeff: I had some code for that at one point when I had to do something like that for MassLNC testing |
| 08:58 |
tsbere |
I can check the masslnc server to see if I left a copy sitting there? |
| 08:59 |
|
ericar_ joined #evergreen |
| 09:03 |
jeff |
tsbere: sure, i'd be interested. |
| 09:04 |
jeff |
i'm also trying to keep in mind some of the issues around such things, especially https://en.wikipedia.org/wiki/AOL_search_data_leak |
| 10:01 |
Dyrcona |
jeff: It was used to anonymize patron data during the performance evaluation done by OmniTI. |
| 10:02 |
Dyrcona |
We used actual data from C/W MARS. |
| 10:03 |
jeff |
Got it. That was one of the possibilities that came to mind, but I figured best to ask. |
| 10:05 |
kmlussier |
My use case now is similar. There are times I want to use production data for testing, but, since we work with multiple partners, I prefer to do it with anonymized data. |
| 10:08 |
|
rjackson_isl joined #evergreen |
| 10:19 |
|
dbwells joined #evergreen |
| 10:25 |
|
ericar_ joined #evergreen |
| 11:05 |
remingtron |
both sections have comments about optional steps during an upgrade |
| 11:07 |
kmlussier |
remingtron: Seems reasonable to me. Thanks! |
| 11:08 |
remingtron |
kmlussier: thanks for the feedback |
| 11:42 |
csharp |
jeff: I was just pondering test data anonymization myself - I don't have anything to offer other than "me too", though ;-) |
| 11:50 |
dbs |
remingtron: "If you were still using the JSPAC... Why? WHY?!?!" |
| 11:51 |
csharp |
pinesol_green: WHY?? |
| 11:51 |
pinesol_green |
csharp: have you tried local mean solar time for the named city as the reference point? |
| 16:06 |
yboston |
Dyrcona: Stompro put in a patch, but I think it needs a signoff |
| 16:06 |
kmlussier |
Dyrcona: Yeah, in this case I'm not doing a release notes entry |
| 16:08 |
kmlussier |
28e9f061 |
| 16:08 |
yboston |
kmlussier: I thought that remingtron might still need to do some testing |
| 16:08 |
kmlussier |
That never works for me. |
| 16:08 |
Stompro |
kmlussier, if you are adding something new, I would go with adoc format. We were waiting on figuring out if it is possible to move all the .txt to .adoc without totally screwing up the git history, or making it hard to use. |
| 16:08 |
kmlussier |
Stompro: OK, will do |
| 01:37 |
|
Mark__T joined #evergreen |
| 05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:56 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
rjackson_isl joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 09:22 |
kmlussier |
I know the page you're talking about. It is indeed very difficult to find. |
| 09:23 |
kmlussier |
http://wiki.evergreen-ils.org/doku.php?id=website_administration |
| 09:23 |
remingtron |
yeah, I just searched for Chris Sharp and found that page too |
| 09:25 |
kmlussier |
I guess I see the release notes acknowledgements as a way to thank the people/organizations responsible for contributing the code, docs, tests that made a release happen. We could expand upon it, but there may be better places where we can acknowledge other contributions to the community. |
| 09:26 |
remingtron |
kmlussier: on the main website? |
| 09:26 |
kmlussier |
Yes, that seems appropriate. Because they are ongoing contributions. |
| 09:26 |
remingtron |
I agree, ongoing contributions are different than version contributions |
| 12:39 |
bshum |
Disagree? |
| 12:39 |
Bmagic |
or agree |
| 12:41 |
Bmagic |
I think that the issue is the link actually. It should reference "id" instead of "source" |
| 12:50 |
Dyrcona |
csharp: I am installing 2.8.4 so I can test the upgrade script for 2.8.4 to 2.9.0. |
| 12:55 |
mmorgan |
Bmagic: Disclaimer, I don't pretend to have a deep understanding of the idl, but the id field has datatype "id", not "link" so it's not referring to that link field. |
| 12:56 |
Bmagic |
mmorgan: compare to metabib::record_attr |
| 12:56 |
Dyrcona |
Well, it should most likely be a link to bre.id. Does that appear in the list of links? |
| 13:45 |
Dyrcona |
It works for me. I'm going to post a branch based on rel_2_9. |
| 13:46 |
Dyrcona |
You check it out and just try the 2.8.4 to 2.9.0 upgrade script, or you can go through the whole install process from git if you like. |
| 13:52 |
Dyrcona |
csharp: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1497307_fix_upgrade_script |
| 14:27 |
csharp |
Dyrcona: excellent! I'll test |
| 14:27 |
Dyrcona |
csharp++ |
| 14:33 |
csharp |
so far so good - I'm at the authority update, which will take a while |
| 14:33 |
csharp |
I'll update the bug with a signoff unless I hit anything |
| 15:38 |
Dyrcona |
I'll send an email to the general list to let anyone know who has already downloaded it that they should download it again. |
| 15:38 |
csharp |
excellent |
| 15:44 |
kmlussier |
Stompro: Glad you got it to work the way you wanted! |
| 15:52 |
* csharp |
experiments with parallel pg_dump |
| 15:53 |
csharp |
on a test server with SSDs and 64 processor cores (using 48) - this should speed up a couple of upgrade steps ;-) |
| 15:56 |
* jlitrell |
sighs wistfully |
| 16:03 |
Bmagic |
I might have found a bug, would someone confirm. Using the staff client, replacing a barcode using this method: Edit Menu -> Replace barcode. It's resulting in a new item instead of replacing the barcode of the old item. Seems to be new in 2.8+ |
| 16:05 |
* jeffdavis |
submits a feature request entitled "Require all SQL generated by the reporter to be reviewed and approved by a knowledgeable human before being run" |
| 16:13 |
jboyer-isl |
That’s the first I’ve heard of it. Almost like an in-line version of the audit tables (but I assume with a different feature set in mind, long, long ago) |
| 16:14 |
Dyrcona |
Probably. |
| 16:14 |
berick |
apt metaphor. a MARC record eats its owner, its owner goes on to provide power for the MARC record, which would have otherwise died out. |
| 16:14 |
kmlussier |
Bmagic: I tested it on master too and had the same results as mmorgan. |
| 16:14 |
jboyer-isl |
berick++ |
| 16:14 |
Bmagic |
weird |
| 16:15 |
kmlussier |
mmorgan: The sound was a little unexpected, wasn't it? |
| 16:16 |
mmorgan |
Maybe it's the old barcode saying: Noooooo! as it goes poof. |
| 16:16 |
mmorgan |
Actually, we have not replaced it. |
| 16:17 |
mmorgan |
I wonder if our users would miss it if we replaced it now. I think we still have folks that pine for the turtle. |
| 16:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:17 |
|
bmills1 joined #evergreen |
| 19:44 |
|
jihpringle joined #evergreen |
| 20:31 |
gmcharlt |
doing maintenance on evergreen-ils.org |
| 23:40 |
|
serflog joined #evergreen |
| 23:40 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 23:44 |
gmcharlt |
testing |
| 23:48 |
gmcharlt |
ok, all done - everything should be up and running again (with the exception of piwik tracking, which I've mostly disabled) and running Wheezy |
| 23:49 |
csharp |
gmcharlt++ |
| 23:49 |
gmcharlt |
another O/S upgrade is in store some time next week |
| 04:13 |
|
mnsri_ joined #evergreen |
| 05:01 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:14 |
|
sarabee joined #evergreen |
| 07:31 |
|
graced joined #evergreen |
| 07:39 |
|
jboyer-isl joined #evergreen |
| 07:42 |
|
ericar joined #evergreen |
| 07:46 |
|
collum joined #evergreen |
| 08:12 |
miker |
so, that test failure is due to a postgres bug fix which, by the way, we desperately want: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=79af9a1d2668c9edc8171f03c39e7fed571eeb98 |
| 08:12 |
miker |
I'll adjust the test to match modern PG, because everyone should upgrade to the most recent minor version in any case :) |
| 08:25 |
dbwells |
miker: Thanks for the commit link, I've been wondering about the history behind the change. Do you think it's going to cause problems for some of our uses? It seems like in some cases we actually just want an XML fragment, since we're going to insert into another record or whatnot. |
| 08:25 |
miker |
no, the fix is going to allow us to simplify all /sorts/ of xpath-using code |
| 08:27 |
dbwells |
Ah, I wasn't really thinking that direction. There are a bunch of places where we have to dance around not having a proper namespace. |
| 08:32 |
miker |
I look at it like this: it's just space, which is cheap ... and, while I've certainly been known to do it, and it's currently much faster, munging xml via regex is still wrong and shameful |
| 08:33 |
dbwells |
but it's so fast! ;) |
| 08:33 |
|
Dyrcona joined #evergreen |
| 08:35 |
miker |
Dyrcona: sorry to pounce immediately, but I have a fix for the test failure, and as RM[aintainer] I'll just ask you: shall I wait for launchpad to load, create a bug, push a branch, and update the bug, or just push the test fix to master? :) |
| 08:36 |
Dyrcona |
That's what has typically been done with test fixes so far, so I'd say yes. |
| 08:36 |
miker |
you mean push to master? |
| 08:36 |
Dyrcona |
No, I mean create a bug on launchpad, etc. |
| 08:37 |
miker |
k |
| 08:38 |
dbwells |
miker: I'm happy to sign off based on what I already know about the situation, so the bug report can be pretty "lite" :) |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:40 |
dbwells |
Maybe a small consolation. |
| 08:40 |
Dyrcona |
Well, I don't think we need much for fixing tests. Something like "test [blah] is broken, this should fix it." |
| 08:41 |
|
maryj joined #evergreen |
| 08:43 |
miker |
dbwells: bug 1496837 at ya', and thanks! |
| 08:43 |
pinesol_green |
Launchpad bug 1496837 in Evergreen "xml-related test is invalid" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1496837 |
| 08:45 |
|
mrpeters joined #evergreen |
| 08:47 |
pinesol_green |
[evergreen|Mike Rylander] LP#1496837: Postgres fixed a bug and broke our test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b06b541> |
| 08:47 |
dbwells |
dang, forgot the -s to sign-off. |
| 08:58 |
|
rjackson_isl joined #evergreen |
| 09:08 |
miker |
dbwells++ |
| 14:04 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Kent County Public Library |
| 14:04 |
bshum |
I'll keep us going for now then. |
| 14:04 |
sherbertbc_ |
having connection problems, sorry |
| 14:04 |
bshum |
#topic Minutes/actions from last meeting - http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-07-16-14.00.html |
| 14:05 |
bshum |
1) tspindler will announce a test meeting in the next 2 months to |
| 14:05 |
bshum |
use our GoToWebinar so we can test it and invite other members of the |
| 14:05 |
bshum |
Evergreen community to join if they want. |
| 14:05 |
bshum |
tspindler++ for putting that together |
| 14:05 |
bshum |
And thanks to all of you who participated |
| 14:05 |
rfrasur |
What was the verdict? |
| 14:05 |
bshum |
#info tspindler to test GoToWebinar with other EOB members |
| 14:06 |
bshum |
#info tspindler's results: http://list.evergreen-ils.org/pipermail/eg-oversight-board/2015-September/001114.html |
| 14:06 |
tspindler |
I think it worked well over all. Gives us some different options if you want to use it |
| 14:06 |
yboston |
I thought it worked well. Might want to test it with more people at once to be safe |
| 14:06 |
montgoc1 |
I agree. Seemed like it would be fine. |
| 14:07 |
yboston |
I bet it would be fine |
| 14:07 |
abneiman |
I'm on record before but I like the audio convo better than IRC, I'm more comfortable speaking extemporaneously than typing. Agree on testing with more members. |
| 14:07 |
rfrasur |
And, was the idea that it supports voice and it's recordable? |
| 14:07 |
tspindler |
rfrasur: yes |
| 14:08 |
* rfrasur |
is just restating for the log. |
| 14:12 |
rfrasur |
Let's shoot for October if all are amenable. |
| 14:12 |
montgoc1 |
Sure. |
| 14:13 |
sherbertbc_ |
I'm n/a Oct 15, our annual all staff, but go ahead w/o me! |
| 14:13 |
bshum |
tspindler: Along the way, for those of us who weren't part of the original trial (me, for example, I'm such a slacker), I wonder if we could ask you to help set up another test in between now and then. |
| 14:13 |
abneiman |
10/15 should be OK with me |
| 14:13 |
yboston |
that date works for me |
| 14:13 |
bshum |
And we can do a dry run so to speak of the board procedures. |
| 14:14 |
tspindler |
bshum: i think i could squeeze a date in, I may just have to schedule it and hope it works |
| 14:14 |
rfrasur |
+1 |
| 14:14 |
bshum |
tspindler: That'd be fine, and I will hopefully find myself available this time around. |
| 14:14 |
tspindler |
how is the week of October 5 for a test run? |
| 14:15 |
bshum |
tspindler: Depends on the day of the week for me. |
| 14:15 |
rfrasur |
That Monday, Thursday, or Friday are fine. |
| 14:15 |
tspindler |
I could set up for Thursday, October 8 at 2PM EST if that works for a test for anyone |
| 14:15 |
bshum |
Thursday or Friday afternoon work for me |
| 14:15 |
bshum |
I think there's an academics meeting on that Thursday |
| 14:15 |
sherbertbc_ |
Mon or Fri |
| 14:18 |
tspindler |
rfrasur: +1 |
| 14:18 |
montgoc1 |
rfrasur: +1 |
| 14:18 |
|
maryj joined #evergreen |
| 14:19 |
bshum |
#info Pre-meeting practice for GoToWebinar to occur at 1:30 pm Eastern on October 15 prior to the regular EOB meeting. |
| 14:19 |
bshum |
Cool deal, thanks all, and hopefully we get some good feedback on how that next meeting's test goes via audio. |
| 14:19 |
bshum |
Anything further on that for now? |
| 14:19 |
rfrasur |
And tspindler, you send out the join link? |
| 14:19 |
tspindler |
rfrasur: yes, I'll do that |
| 14:19 |
rfrasur |
tspindler++ |
| 16:24 |
miker |
or not |
| 16:24 |
miker |
bshum++ # thanks |
| 16:25 |
|
jlitrell joined #evergreen |
| 16:44 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:45 |
kmlussier |
Huzzah! |
| 16:55 |
phasefx |
yay |
| 16:57 |
phasefx |
those unrecognized value "" for "ECHO"; assuming "none" warnings are also relatively new, and introduced with a change in psql |
| 09:21 |
kmlussier |
dbwells: Yes, they are. I just have the Default one set to True. |
| 09:22 |
kmlussier |
Thanks dbwells! While you're looking at it, I was thinking it might be better if the warning said "Voiding these bills may violate local policy by producing a negative balance." Our users like lots of clarity in their messages. :) |
| 09:24 |
* mmorgan |
is wondering about the use of the term "local policy" here. |
| 09:24 |
kmlussier |
dbwells: Ugh. Never mind! I just realized I loaded the wrong branch on the server. Sorry! |
| 09:26 |
kmlussier |
dbwells: Scratch that last comment. It is the correct branch. |
| 09:26 |
kmlussier |
This is what happens when kmlussier tests without coffee. |
| 09:26 |
mmorgan |
I agree with kmlussier - lots of clarity for users. |
| 09:26 |
mmorgan |
@coffee kmlussier |
| 09:26 |
* pinesol_green |
brews and pours a cup of Panama Esmeralda Mario Carnival, and sends it sliding down the bar to kmlussier |
| 09:27 |
mmorgan |
Maple cream? Wow. |
| 09:29 |
kmlussier |
mmorgan: For a limited time only! |
| 09:29 |
dbwells |
kmlussier: Are the menu options showing and hiding as expected? |
| 09:30 |
kmlussier |
dbwells: I'm testing that now. |
| 09:30 |
mmorgan |
You can always tell what season it is by looking at the coffee flavors available :) |
| 09:31 |
mmorgan |
Just my $.02 about the warning message, I'd find this clearer "Voiding these bills may produce a negative balance. Are you sure you wish to continue?" |
| 09:32 |
kmlussier |
dbwells: Yes. The void option is gone now that I've removed the void permission. |
| 10:55 |
jeff |
(but hasn't been able to mine enough tuits to have a useful contribution to the conversation at hand) |
| 11:01 |
jeff |
Though I should probably at least note that my dislike statement above is at least somewhat unclear / ambiguous. |
| 11:02 |
kmlussier |
jeff: Well, the voiding behavior doesn't change at all from what we currently do. Which is why I'm looking at ways to make sure libraries can keep their staff away from it while also not losing the ability to do things that they currently can do. |
| 11:06 |
dbwells |
kmlussier: Dyrcona: I probably won't have time to work on this more today. I think the current branch is highly functional and seems to be not breaking, so I'd like to see it pushed sooner rather than later. (This is not a statement about overall release-readiness, which I leave entirely up to Dyrcona.) Thanks for testing! |
| 11:07 |
|
RoganH joined #evergreen |
| 11:10 |
bshum |
miker: https://bugs.launchpad.net/evergreen/+bug/1483857 got marked fix committed, but I don't see a corresponding commit to master or a milestone assigned to the bug. |
| 11:10 |
pinesol_green |
Launchpad bug 1483857 in Evergreen "Web based staff client in house use barcode box clear" (affected: 2, heat: 10) [Undecided,Fix committed] |
| 11:28 |
jeff |
kmlussier: it's my understanding that currently it's frowned upon to push to master around/near release time without coordination with the RM. i could be wrong. |
| 11:28 |
bshum |
jeff: Huh? |
| 11:29 |
bshum |
Oh hmm.... |
| 11:29 |
kmlussier |
jeff: Ah, ok. But if it were another say, say next week, miker could just push those changes to master since he's reviewed and tested them, couldn't he? |
| 11:29 |
kmlussier |
Apologies for garbling that sentence, but y'all know what I mean. |
| 11:29 |
miker |
also, they haven't been pushed to webby for broader testing yet |
| 11:34 |
miker |
if 2.9 is cut later than today (but don't delay for those minor fixes alone, please!) then broader testing will be applied, and I will push them to master for good and all |
| 11:42 |
kmlussier |
dbwells / Dyrcona: I've been waiting to hear back from one other person to get a sense of how often the void option in Full Details is used. And it may be too late to give feedback if Dyrcona has already started release cutting. |
| 11:43 |
kmlussier |
dbwells / Dyrcona: My personal opinion right now is, to truly prohibit negative balances we we had hope to do, we will need to remove that void permission from our users. And when we remove that void permission, they will lose the ability to do something they previously could do. It's a regression. |
| 11:44 |
kmlussier |
My preference is that they don't lose any functionality when the .0 release is out. But I leave it in the hands of our fearless RM to make the final decision. |
| 12:37 |
miker |
if you don't use circ_mod much in other rules, that might do it |
| 12:38 |
dbs |
bshum: should make things a lot easier for people who want to tailor templates without worrying about breaking the embedded metadata, so would be worth it I think |
| 12:39 |
Bmagic |
miker: right now, we have about a 50/50 split of rules that mention circ mod and those that dont |
| 12:40 |
miker |
Bmagic: if the rule in question is the only one using that particular circ_mod, it still might be OK |
| 12:40 |
miker |
testing would tell, obv |
| 12:41 |
Bmagic |
right on |
| 12:42 |
Bmagic |
it would be neat if there was a mechanizm for "pickup library is NOT x" |
| 12:43 |
Dyrcona |
miker gmcharlt: I'm in favor of web staff client fixes being treated like normal bugs and have considered saying it would be OK to backport them to rel_2_9 once it is branched. |
| 12:55 |
miker |
I can be in a position soon ... in, say, 15min |
| 12:55 |
Dyrcona |
OK. I can wait. |
| 12:55 |
Dyrcona |
I'd prefer to have as much as possible in master before branching. |
| 12:56 |
miker |
Dyrcona: and, to be clear, I'd like to push the top 6 commits of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/sprint2-fixes ... the first 4 are from this morning, the next 2 are fixes that are widely tested |
| 12:57 |
Dyrcona |
OK. That works for me. |
| 12:58 |
miker |
where "widely" means "by more than the author, and don't break webby" |
| 12:59 |
Dyrcona |
:) |
| 12:59 |
Dyrcona |
Should I use Chrome when testing the web staff client? |
| 12:59 |
Dyrcona |
Or, do you want it to work with Firefox, too? |
| 13:00 |
miker |
both ideally, but chrome is moar better in general |
| 13:00 |
Dyrcona |
Thanks! That is what I thought. |
| 14:13 |
bshum |
Does anyone remember offhand what a hold status of -1 means? I know it's indicative of some sort of error failure, I just don't recall the exact nature of it. |
| 14:14 |
Dyrcona |
The hold is in an invalid state. |
| 14:14 |
Bmagic |
bshum: I had this question a few weeks ago...... now I forget what the answer was, lol. Apparently it was important. Let me look back |
| 14:14 |
jeff |
only displayed in the staff client, it's "something isn't what i expect" |
| 14:15 |
jeff |
it's set to "-1" at display time as a fall-through after several conditional tests. |
| 14:15 |
Dyrcona |
Typically happens when some field has or is missing a value that it shouldn't because of other values in the hold request. |
| 14:15 |
berick |
usually a mismatch between copy status and hold disposition |
| 14:22 |
bshum |
Okay, 2.7.8 is all set. But I'll wait to update the downloads page for now. |
| 14:43 |
kmlussier |
Dyrcona: I do have some changes I need to make to the 2.9 release notes. I think I'm done with the neg balance additions from today's branch, but I also need to add acknoledgements. I'll remove those bug fix release note entries at that time. |
| 14:43 |
Dyrcona |
OK. Works for me. |
| 14:44 |
* kmlussier |
will first grab the tea that is probably getting cold by now. :) |
| 14:51 |
jeffdavis |
dbwells: I was finally able to apply your fix for bug 1484989 on a test server. After applying the commit, lost transactions are being closed when the item is checked in and the fine balance hits zero, which is what we want. |
| 14:51 |
pinesol_green |
Launchpad bug 1484989 in Evergreen 2.8 "Fines are not calculating until after circulation is closed" (affected: 1, heat: 6) [Medium,Fix committed] https://launchpad.net/bugs/1484989 |
| 14:51 |
jeffdavis |
dbwells: However, that behavior still does not seem to be governed by the circ.lost.xact_open_on_zero setting, which is what we expected (i.e. the circs are closed even when that setting is true). |
| 14:52 |
jeffdavis |
I haven't replicated our original problem on a stock 2.8 install though. |
| 16:03 |
Bmagic |
yep |
| 16:03 |
pinesol_green |
[evergreen|Kathy Lussier] Additions to the 2.9 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c06390> |
| 16:03 |
Bmagic |
I reloaded the patron in a new tab just to make sure |
| 16:04 |
kmlussier |
Release note changes are pushed. One change I made to the acknowlegements is that we are thanking people for contributions to tests as well as code and doc patches. |
| 16:04 |
Bmagic |
I tested it on a non-lost circ, and it did increase the count |
| 16:04 |
Dyrcona |
kmlussier++ |
| 16:04 |
Bmagic |
kmlussier++ |
| 16:04 |
mmorgan |
kmlussier++ |
| 16:43 |
kmlussier |
As usual, when working on acknowledgements, it was great to see all the different types of organizations big and small that went into making this Evergreen release. A big y'all++ |
| 16:43 |
kmlussier |
And an even bigger Dyrcona++ |
| 17:08 |
|
mmorgan left #evergreen |
| 17:19 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:32 |
pinesol_green |
[evergreen|Remington Steed] Docs 2.9: Update and add detail for Holdings Import profile - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=584dfb9> |
| 17:46 |
pinesol_green |
[evergreen|Jason Stephenson] Porting 2.8.4->2.9.0 SQL upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=69bb3ce> |
| 17:48 |
pinesol_green |
[evergreen|Jason Stephenson] Forward port 2.9.0 translations. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d40524> |
| 18:13 |
Dyrcona |
Well, I hope that's that. |
| 18:16 |
pinesol_green |
[evergreen|Jason Stephenson] 2.9 Release notes creation and cleanup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d10f91> |
| 18:26 |
kmlussier |
Dyrcona++ |
| 23:14 |
bshum |
Well, maybe. |
| 23:15 |
kmlussier |
bshum++ |
| 23:16 |
bshum |
"And now his watch is ended." (almost, almost....) |
| 23:27 |
jeff |
what's the bar for "commissioned developments"? |
| 23:27 |
jeff |
oh, and is there a better method for me to help fix this typo than just mentioning it here? "individuals who contributed code, documentations patche and tests to this release" :-) |
| 23:27 |
jeff |
(first question is just one of curiosity, not thinking that there was an omission or anything) |
| 23:28 |
kmlussier |
jeff: Organizations that contracted for development work that made it into the release. |
| 23:29 |
kmlussier |
In the case of this release, we have organizations that paid for development through Equinox, Sigio, and Catalyst. |
| 23:30 |
bshum |
I think it covers the base of funding partners who don't get their names/organizations represented with the actual authoring/testing/signoff/committing. |
| 23:30 |
kmlussier |
Basically, it's a way to give credit to organizations that may not have the development staff to contribute code, but made one of the features happen through funding. |
| 23:33 |
kmlussier |
bshum: Did you already update the release notes with my feature? If not, can you fix my typo? |
| 23:33 |
bshum |
kmlussier: Already updated, but we can do another one... |
| 01:39 |
|
Mark__T joined #evergreen |
| 03:03 |
|
gsams joined #evergreen |
| 05:21 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:33 |
|
TaraC joined #evergreen |
| 07:32 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
rlefaive joined #evergreen |
| 09:00 |
Dyrcona |
I'm looking into LP 1494427. |
| 09:00 |
pinesol_green |
Launchpad bug 1494427 in Evergreen "Staff client refund option generates an error" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1494427 |
| 09:00 |
Dyrcona |
It looks like something quick I can do before the rest of my day gets swallowed whole by meetings. |
| 09:01 |
Dyrcona |
And one barcode shows up at least three times, think I'll test with that patron. |
| 09:06 |
|
mmorgan left #evergreen |
| 09:08 |
|
yboston joined #evergreen |
| 09:16 |
pinesol_green |
[evergreen|Kathy Lussier] lp1494427: Fix refund error - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4efea97> |
| 10:25 |
bshum |
When we touch the same table a couple times during the same major upgrade |
| 10:25 |
bshum |
Cause the minor upgrade scripts do stuff |
| 10:25 |
csharp |
well, it looks like we'll need to change the script so that it doesn't do that in the same transaction |
| 10:25 |
bshum |
Usually, only live testing reveals it, and then the RM can make necessary edits to the upgrade script |
| 10:26 |
csharp |
ok, so bug report? |
| 10:26 |
bshum |
And either combine necessary changes into one SQL update, or break it up into stuff inside and outside the main body transaction |
| 10:27 |
|
Christineb joined #evergreen |
| 11:12 |
Stompro |
mmorgan, does printing the list of holds work for you on your self checks(EG web based self check)? It doesn't work for me with a default setup. |
| 11:13 |
bshum |
Stompro: Do you have popups disabled? |
| 11:14 |
Stompro |
bshum, the other print lists work fine, printing list of items out and fines work. Popups are allowed. |
| 11:15 |
bshum |
Stompro: Do you have any sort of browser error logging? Maybe it could indicate if it's a specific failure somewhere in the execution |
| 11:15 |
* bshum |
hasn't tested hold printing lately |
| 11:15 |
Stompro |
bshum, thanks I'll enable the JS log and see what it says. |
| 11:17 |
bshum |
length of undefined |
| 11:17 |
bshum |
That's helpful... |
| 12:33 |
|
pmurray left #evergreen |
| 12:39 |
|
rlefaive joined #evergreen |
| 12:45 |
|
bmills joined #evergreen |
| 13:04 |
* mmorgan |
reads up. |
| 13:05 |
mmorgan |
Glad Stompro and bshum found the hold slip printing bug. It really hasn't been much of an issue for us for the reason Stompro mentioned. |
| 13:06 |
mmorgan |
Can anybody point me to some fairly concise guidelines for setting up credit card processing using paypal? |
| 13:08 |
mmorgan |
We have a training system set up with a paypal sandbox, but aren't having any success testing payments. |
| 13:14 |
kmlussier |
mmorgan: I thought there was a message on the mailing list that had a concise list of steps, but I don't see it now. |
| 13:14 |
kmlussier |
mmorgan: I once successfully used the paypal sandbox with Evergreen, but it was so long ago, I don't recall what I did. I remember I was a bit confused on the PayPal side of things. |
| 13:16 |
mmorgan |
kmlussier: Right now I'm a bit confused on both sides! ;-) |
| 13:36 |
|
Dyrcona joined #evergreen |
| 13:36 |
jeffdavis |
^ Noted here so that it's in the logs. I haven't reproduced on a stock EG install yet, so no LP bug so far. |
| 13:43 |
jeff |
jeffdavis: on the system where you're seeing this, is it affecting most/all bookbags, or just some/one? |
| 13:43 |
jeffdavis |
All the ones I've tested so far, but my testing pool has been fairly small. |
| 13:44 |
jeff |
seq scan on asset.copy -- ouch. |
| 13:46 |
jeffdavis |
The filter there is on two boolean columns though, so it seems like the solution isn't an index but reducing the number of rows scanned. |
| 13:49 |
|
maryj joined #evergreen |
| 14:03 |
jeffdavis |
csharp: Interesting! You folks are on PG 9.4, right? |
| 14:03 |
csharp |
9.3, currently |
| 14:03 |
jeffdavis |
ah nope, I see 9.3 in the bug :) |
| 14:03 |
csharp |
testing on 9.4 as we speak, though |
| 14:03 |
jeff |
jeffdavis: what are you guys on? |
| 14:04 |
jeffdavis |
we're 9.4 |
| 14:04 |
csharp |
jeffdavis: see the suggestions from miker in the last comment on the bug report - they didn't solve my issue, but may help yours |
| 14:04 |
jeffdavis |
csharp: I see miker suggested adjusting stats on one of the tables there, have you tried that? |
| 14:04 |
csharp |
heh - yep |
| 14:04 |
csharp |
they didn't solve the problem, so I let it go |
| 14:05 |
csharp |
actually, I haven't tested it since we purged most of our holds data |
| 14:05 |
csharp |
it's probably fixed |
| 14:07 |
csharp |
nope - stats are still borked for me on that query |
| 14:07 |
csharp |
it is faster, though |
| 14:07 |
miker |
jeffdavis: your modification looks like it's just joining call number before location. I wonder if the underlying json_query can just be adjusted to do that. where is the code for that query, if you know off hand? |
| 14:07 |
csharp |
in my case, it's vastly overestimating the number of rows |
| 14:09 |
jeffdavis |
miker: not sure yet - figuring that out is the next step on my todo list for that bug :) |
| 15:59 |
|
maryj joined #evergreen |
| 16:26 |
|
bmills joined #evergreen |
| 16:30 |
|
ericar joined #evergreen |
| 16:35 |
* kmlussier |
grabs the code from bug 1494544 to get a Sandbox set up for testing later this evening. |
| 16:35 |
pinesol_green |
Launchpad bug 1494544 in Evergreen "Void options in the billing UI allow negative balances to occur when they should be prohibited" (affected: 1, heat: 6) [Critical,Confirmed] https://launchpad.net/bugs/1494544 - Assigned to Dan Wells (dbw2) |
| 16:36 |
kmlussier |
dbwells++ |
| 16:37 |
|
Christineb joined #evergreen |
| 16:40 |
* kmlussier |
also grabs the code from bug 1340852 in the hopes of getting jlitrell's first contribution into Evergreen. :) |
| 16:40 |
pinesol_green |
Launchpad bug 1340852 in Evergreen "Copy Location Groups search not retaining original search params after searching" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1340852 |
| 16:53 |
jlitrell |
Huzzah! |
| 17:04 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:34 |
Bmagic |
Has anyone tackled sending automated emails to patrons on a regular basis showing how much to owe? I can't imagine an action trigger doing this. Any thoughts? |
| 17:35 |
Bmagic |
how much they* owe |
| 01:30 |
|
Mark__T joined #evergreen |
| 01:42 |
|
dac joined #evergreen |
| 04:38 |
|
book` joined #evergreen |
| 05:06 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:00 |
|
_bott_ joined #evergreen |
| 07:22 |
|
rlefaive joined #evergreen |
| 07:40 |
|
sarabee joined #evergreen |
| 11:26 |
bshum |
Stompro: That might be the case, I've honestly always used a workstation with our web-based selfchecks. |
| 11:26 |
bshum |
I can't recall if it's a library setting that forces you to register a workstation via the selfcheck |
| 11:26 |
bshum |
It might be. |
| 11:28 |
mmorgan |
Stompro: Just gave this a test on a training server, and the circulation got NULL as the workstation. |
| 11:29 |
Stompro |
mmorgan, thanks for testing it, I just want to get the facts right for what I'm going to add to the docs. |
| 11:29 |
mmorgan |
We also require a workstation for self check. |
| 11:30 |
mmorgan |
Stompro++ # getting the facts right! |
| 11:31 |
Stompro |
mmorgan, I'm not sure why you wouldn't set a workstation, but the default option is to not require a WS. Why would you want to remember that self check circs are the ones without a NULL WS for that location. |
| 11:50 |
jeff |
a new OpenILS::Application::Circ::Circulator object is either passed a circ_lib, or it gets its circ_lib from the user session's ws_ou, which defaults to the user's home_ou if there is no workstation associated with the user's session. That default behavior is part of open-ils.auth |
| 11:51 |
jeff |
As for "does anything in stock pass a circ_lib as an argument to one of the API methods that create Circulator objects to do their work?"... I didn't look. :-) |
| 11:51 |
Stompro |
jeff++ thanks |
| 11:52 |
mmorgan |
Stompro: Testing shows that the circ_lib in the transaction comes from the workstation, too :) |
| 11:56 |
bshum |
svn-- git++ |
| 11:56 |
bshum |
Why is this so hard??! |
| 11:57 |
Stompro |
mmorgan++ for testing things all the time. |
| 11:58 |
* mmorgan |
likes to get the facts right, too. |
| 11:58 |
jeff |
bshum: what are you struggling with? |
| 11:58 |
bshum |
jeff: Just trying to get an svn diff from two revisions to try seeing what's changed for a given file. |
| 15:32 |
mmorgan |
jhpringle: Bmagic: fwiw, our circ.lost.generate_overdue_on_checkin is not set. We aren't seeing the same problem. |
| 15:33 |
dbwells |
Actually, that commit may be unreleased, but it is committed for 2.8.4. |
| 15:33 |
mmorgan |
jihpringle, that is. Are any fines involved in your situation? |
| 15:34 |
jihpringle |
usually in the examples libraries have sent us but not in our tests |
| 15:34 |
Bmagic |
if there are bills that do not get voided as part of the checkin proceedure, then everything is fine. You just pay/void those bills later, and the circulation is closed and removed. Its only when the checkin proceedure voids ALL of the bills and the transaction should be closed, it's not closed |
| 15:35 |
jihpringle |
we can check out the item, set it to lost, and then checkin and reproduce the issue all in a couple minutes |
| 15:35 |
Bmagic |
jihpringle: Oddly enough, we had circ.lost.generate_overdue_on_checkin set to false the whole time, and have the issue, I changed it to true, and the bug went away |
| 15:37 |
Bmagic |
jeffdavis: she said it wasn't showing itself in 2.8. It's 2.8.1 and higher |
| 15:39 |
dbwells |
jeffdavis: can you try commit 4357ab325959f2ed48 and see if it helps? I am guessing this is already fixed under different symptoms. |
| 15:39 |
pinesol_green |
[evergreen|Dan Wells] LP#1484989 Don't close xacts with checkin-generated fines - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4357ab3> |
| 15:39 |
jeffdavis |
dbwells: yep, I will be testing that asap |
| 15:39 |
dbwells |
jeffdavis: looking forward to hearing back, thank you |
| 15:40 |
jeffdavis |
thanks for the pointer :) |
| 15:42 |
bshum |
dbwells: I'm following the discussion on bug 1494544 and I wonder, do you think it'd be hard to base display of the different buttons based on the actual settings used? |
| 15:42 |
pinesol_green |
Launchpad bug 1494544 in Evergreen "Void options in the billing UI allow negative balances to occur when they should be prohibited" (affected: 1, heat: 6) [High,Confirmed] https://launchpad.net/bugs/1494544 |
| 15:42 |
jeffdavis |
Bmagic: our stock test server is running 2.8.1 fwiw |
| 15:42 |
bshum |
Like if prohibit negative balances is engaged, don't display the void buttons. |
| 15:42 |
bshum |
Rather than basing it entirely on just permissions on the users. |
| 15:43 |
bshum |
I just worry about policing the permissions over use of the settings, which are a lot simpler to enact initially. |
| 16:08 |
kmlussier |
dbwells: Also, you're right about the ADJUST_BILLS permission allowing/disallowing the adjust to zero action. I thought I saw the word "void" in the message that appeared, but it was late at night. Must have been seeing things. |
| 16:09 |
kmlussier |
But it looks like the permission didn't make it into the seed data. |
| 16:09 |
* kmlussier |
will add that correction to the lp bug. |
| 16:09 |
* bshum |
probably tested everything using a superuser :( |
| 16:09 |
* bshum |
hates permissions |
| 16:10 |
dbwells |
kmlussier: great, thank you also for following up |
| 16:10 |
bshum |
Well I hate permission wrangling. |
| 16:10 |
kmlussier |
bshum: Well, then, you can just give Everything to all of your users and see what fun ensues. :) |
| 16:16 |
mmorgan |
kmlussier: Think I just fixed that. |
| 16:16 |
kmlussier |
mmorgan++ |
| 16:17 |
kmlussier |
Stompro++ # Moving good tips into the official docs. |
| 16:17 |
Bmagic |
dbwells: that patch fixes the checkin issue on our test machine |
| 16:17 |
mmorgan |
Stompro++ |
| 16:17 |
dbwells |
Bmagic: sweet, glad to hear it |
| 16:17 |
Bmagic |
dbwells++ mmorgan++ jihpringle++ bshum++ jeffdavis++ |
| 16:37 |
|
bmills joined #evergreen |
| 16:45 |
|
gdunbar joined #evergreen |
| 16:53 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:55 |
Dyrcona |
Ha ha! |
| 16:55 |
Dyrcona |
Now it is getting the xmlns attribrute in ever tag. |
| 16:56 |
Dyrcona |
You just /have/ to /love/ tests! |
| 16:57 |
Dyrcona |
Too late in the day to fix it, now. |
| 16:59 |
dbwells |
I looked at that a bit in the first round, and my feeling is that Dyrcona may be right about this being a change in the underlying XML library which is bubbling up. |
| 17:08 |
|
mmorgan left #evergreen |
| 17:16 |
phasefx |
jfyi, I fixed HTML escaping for the test output webifier, so we can actually see the xmlns stuff from the web page for that failed test |
| 17:18 |
pinesol_green |
[evergreen|Angela Kilsdonk] Docs: 2.9 Updates to OPAC documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f5140d5> |
| 17:22 |
pinesol_green |
[evergreen|Angela Kilsdonk] Docs: 2.9 Purchase Order Activation Progress Bar - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=23f8679> |
| 19:06 |
|
bmills joined #evergreen |
