Time |
Nick |
Message |
01:32 |
|
Mark__T joined #evergreen |
01:35 |
|
gdunbar joined #evergreen |
05:11 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
07:09 |
|
rlefaive joined #evergreen |
07:53 |
kmlussier |
Looks like that test has been failing since Saturday. |
08:05 |
jeff |
The have and want are equivalent, but the want has more explicit namespaces. |
08:05 |
jeff |
either that or i just compared the same thing. |
08:08 |
jeff |
Nope, I compared correctly. :-) |
08:08 |
|
mrpeters joined #evergreen |
08:08 |
jeff |
Also worth noting is that the test script isn't excaping XML output from tests. |
08:12 |
|
ericar joined #evergreen |
08:15 |
|
rjackson_isl joined #evergreen |
08:27 |
|
ericar joined #evergreen |
08:35 |
jeff |
"excaping"? oof. |
08:39 |
|
Dyrcona joined #evergreen |
08:42 |
|
mmorgan joined #evergreen |
08:46 |
Dyrcona |
<sarcasm>Yay for smart quotes in MARC records!</sarcasm> |
08:52 |
|
rlefaive joined #evergreen |
08:52 |
|
maryj joined #evergreen |
08:52 |
Dyrcona |
Well, that's neat. Somebody sent an actual email to opensrf-commits. |
08:59 |
csharp |
in webby, in the Z39 import interface, when I select Edit then Import, it's only showing the LDR field - can someone else confirm? |
08:59 |
csharp |
importing from OCLC, if that makes a difference |
09:01 |
phasefx |
csharp: confirmed |
09:07 |
Dyrcona |
I don't think I could get the z39.50 import to work the last time I tried, but that was long before the RC release. |
09:08 |
Dyrcona |
phasefx gmcharlt miker: If you'd like the latest sprint2 changes in before 2.9.0 final, that can be arranged if you point me at a branch before Monday. |
09:09 |
* Dyrcona |
runs off to finish setting up NCIPServer in production and then to test half-open connection fixes. |
09:09 |
gmcharlt |
Dyrcona: thanks, that is very generous of you! |
09:09 |
csharp |
phasefx: thanks |
09:09 |
gmcharlt |
we'll get a branch put together |
09:10 |
csharp |
that would totally rock |
09:11 |
csharp |
PINES would love to be able to offer a mostly-working web client to libraries willing to be on a "live beta" before next summer reading |
09:11 |
gmcharlt |
csharp: does it work for LC? |
09:11 |
csharp |
didn't check - I'll do so now |
09:12 |
csharp |
gmcharlt: same behavior |
09:12 |
csharp |
if cache-clearing or anything like that needs to happen between tests, just let me know ;-) |
09:13 |
|
yboston joined #evergreen |
09:17 |
|
rlefaive joined #evergreen |
09:19 |
|
rlefaive joined #evergreen |
09:23 |
gmcharlt |
csharp: so, I've pushed a fix to the collab/gmcharlt/webstaff-sprint branch |
09:23 |
gmcharlt |
now that sprint2 is about to enter the formal testing phase, webby itself will get updated at 5 p.m. every day |
09:24 |
gmcharlt |
(though there may be occassional earlier updates) |
09:38 |
miker |
I'm happy to drop that update in place for testing |
09:39 |
miker |
(but 5pm is the only guarranteed update time for webby going forward) |
09:39 |
miker |
as gmcharlt says |
09:39 |
|
collum joined #evergreen |
09:46 |
bshum |
kmlussier: Looking over at bug 1494427 and I wonder if we shouldn't edit bills2.js and remove the var entirely for staff.patron.bills.handle_refund.confirm_message |
09:46 |
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:47 |
bshum |
Since it only appears the one time in that file and it just seems to be grabbing the translated string from the properties file. |
09:47 |
bshum |
But otherwise doesn't seem to use it. |
09:49 |
* bshum |
double checks |
09:51 |
kmlussier |
bshum: Yes, that's what I was thinking yesterday. Remove that bit and then not re-add it to the xul file. But I kept thinking there was a reason it was there. |
09:52 |
phasefx |
Dyrcona: did you reply to Rigoberto? |
09:52 |
Dyrcona |
Actually, I didn't. |
09:52 |
phasefx |
I'll do it |
09:52 |
Dyrcona |
Thanks. |
09:52 |
kmlussier |
bshum: I could create a branch sometime today that does that, though. |
09:57 |
csharp |
miker: if you go ahead and put the change in, I'll test it immediately |
09:57 |
csharp |
gmcharlt: thanks! |
09:57 |
miker |
csharp: did so right after I said I wouldn't mind ;) |
09:58 |
csharp |
:-) cool - I'll do so now |
09:58 |
miker |
status: WORKSFORME, btw |
09:58 |
gmcharlt |
csharp: as a general note - webby sets a 10-minute expiration all files it serves |
09:58 |
|
rlefaive joined #evergreen |
09:58 |
csharp |
ah - there we goo |
09:59 |
csharp |
gmcharlt: good to know |
09:59 |
csharp |
I can confirm the editor is loading now when importing from OCLC |
09:59 |
gmcharlt |
groovy |
10:05 |
Dyrcona |
csharp++ gmcharlt++ |
10:08 |
Dyrcona |
Heh. So to test something on my dev machine, I process a hold that is in transit for me and then check the book out to myself. |
10:08 |
Dyrcona |
Less than 5 minutes later, a co-worker shows up at my office with the book in hand. |
10:17 |
gmcharlt |
heh |
10:22 |
remingtron |
Anyone know what happens if you place a hold on a multi-part record and keep "All Parts" selected? |
10:22 |
bshum |
Sigh, parts... |
10:22 |
remingtron |
working on documentation for that feature |
10:23 |
bshum |
I believe that generally, that option will lead to a title hold being created? |
10:23 |
bshum |
That targets all the non-part copies. |
10:23 |
bshum |
That might be mixed in with copies with parts attached. |
10:24 |
bshum |
Otherwise, selecting a specific part will only target those copies with the part attached to them. |
10:25 |
bshum |
In our consortium, we modified our part hold selector to drop that option, because we found it... complicated... to explain. So it's parts or bust for us :( |
10:25 |
remingtron |
so it doesn't request all the parts, but just *any* of the parts/copies? |
10:25 |
bshum |
remingtron: It doesn't request all parts or any parts. It behaves like a normal title hold and doesn't target any copy with parts at all. |
10:26 |
remingtron |
ah, thanks for clarifying |
10:26 |
remingtron |
bshum++ |
10:26 |
bshum |
The label is misleading in my opinion. |
10:26 |
remingtron |
I agree, should be relabeled |
10:26 |
remingtron |
maybe to "All other"? |
10:26 |
remingtron |
hm, not sure how to express the behavior in such an option |
10:26 |
bshum |
But double check with a parts champion, like kmlussier. Just in case I have a warped understanding.... :\ |
10:27 |
remingtron |
bshum: good advice, thanks |
10:27 |
* bshum |
holds back from giving parts negative karma... and nearly dies from the pain. |
10:28 |
mmorgan |
bshum++ # resisting |
10:28 |
mmorgan |
remingtron: We have changed the label in the dropdown menu to "Complete Set" |
10:28 |
bshum |
remingtron: Yeah, we've tried coming up with better labels for that option, but failed. :( |
10:28 |
jeff |
"complete sets" |
10:28 |
jeff |
hah |
10:28 |
mmorgan |
:) |
10:29 |
jeff |
jinx! |
10:29 |
jeff |
though if you've set it that way long ago, not much of a "jinx" |
10:29 |
jeff |
(we don't currently use parts) |
10:29 |
mmorgan |
We've had it set that way for a while now. |
10:29 |
remingtron |
mmorgan: does that mean your copies with no parts attached just happen to be complete-set copies? |
10:30 |
remingtron |
mmorgan: we don't use parts yet either, so I'm not familiar with how many ways it could be used |
10:31 |
mmorgan |
remingtron: The convention we have is if one of our libraries is barcoding the complete set of a title, it doesn't get a part. |
10:31 |
remingtron |
I'm wondering if "complete set" captures the essence of the feature or if some libraries might use it differently |
10:31 |
mmorgan |
If another library splits it up under multiple barcodes, parts should be assigned. |
10:31 |
mmorgan |
We mostly changed the label because of DVD sets. |
10:32 |
remingtron |
mmorgan: okay, thanks for explaining |
10:32 |
|
miker joined #evergreen |
10:33 |
mmorgan |
Though "Complete set" seemed pretty generic to cover other materials, too. |
10:34 |
remingtron |
it's making sense now. Either a copy is a piece of the whole, or it is the whole. No other sensible option I can think of. |
10:34 |
jeff |
part of documenting can be recommending how to use a given feature like parts. |
10:34 |
jeff |
of course, nothing prevents off-label use, but... |
10:35 |
|
Christineb joined #evergreen |
10:35 |
remingtron |
jeff: agreed! Once you try explaining something, it brings up all sorts of questions. |
10:35 |
* mmorgan |
agrees with jeff. Examples are always helpful. |
10:36 |
|
Shae joined #evergreen |
10:39 |
remingtron |
mmorgan++ jeff++ |
10:41 |
|
gdunbar joined #evergreen |
10:45 |
remingtron |
yboston++ #committing lots of docs stuff yesterday, including from other authors |
10:48 |
|
akilsdonk joined #evergreen |
11:11 |
kmlussier |
Reading up... |
11:12 |
kmlussier |
Looks like mmorgan has explained the "All Parts" option well, so I have nothing to add. |
11:12 |
kmlussier |
mmorgan++ |
11:32 |
|
rlefaive joined #evergreen |
11:57 |
|
bmills joined #evergreen |
12:00 |
|
jihpringle joined #evergreen |
12:00 |
Bmagic |
We changed the tt2 file to say "Choose a part" instead of "All parts" |
12:12 |
pinesol_green |
[evergreen|Remington Steed] Docs 2.9: Remove JSPAC references and screenshots - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7750085> |
12:42 |
|
bmills joined #evergreen |
13:41 |
|
rlefaive joined #evergreen |
14:26 |
kmlussier |
dbwells++ #Auto-generating barcodes. I learned something new about Evergreen today. :) |
14:27 |
kmlussier |
@dessert |
14:27 |
* pinesol_green |
grabs some Cannoli for kmlussier |
14:30 |
Dyrcona |
@coffee kmlussier |
14:30 |
* pinesol_green |
brews and pours a cup of Kenya Ndaroini Microlot, and sends it sliding down the bar to kmlussier |
14:30 |
Dyrcona |
To go with the cannoli. |
14:30 |
kmlussier |
Dyrcona: Thank you! |
14:31 |
Dyrcona |
Speaking of learning something new/first times: I used git add --patch for the first time today to break my working changes into 3 separate commits. |
14:36 |
jeff |
my fingers default to git add -p |
14:38 |
kmlussier |
dbwells: I'm pretty sure the adjust permission didn't get in. I did some testing last night, and removing the void permission prevented the account from adjusting a bill to zero. |
14:40 |
dbwells |
kmlussier: Thanks for letting me know. I'm itching to get in there again and see what's what, but I've got other obligations today. Monday looks more hopeful, or maybe over the weekend if I can't sleep :) |
14:42 |
Stompro |
remingtron++ that was an epic doc update. |
14:44 |
|
gdunbar joined #evergreen |
14:46 |
kmlussier |
dbwells: I imagine this time of year is busy for you. |
14:58 |
Bmagic |
Is there a known issue in the 2.8 versions where checkin lost items leave the item in the patron's "other/special circluations" ? We do not have the "circ.lost.xact_open_on_zero" setting set |
14:58 |
bshum |
Not that I can think of off the top of my head. |
14:59 |
bshum |
But billing changes were made in 2.8, and maybe something's shuffled oddly. |
14:59 |
|
jboyer-isl joined #evergreen |
14:59 |
bshum |
That said, I haven't heard anything like that in our system |
14:59 |
bshum |
Which also does not have that setting set. |
14:59 |
Bmagic |
would anyone mind running this scenario on a dev machine? Checkin a lost item and see if it goes off the patron's other/special |
14:59 |
Bmagic |
EG > 2.8 |
14:59 |
* bshum |
feels like we talked about this already |
15:00 |
Bmagic |
you and me? |
15:00 |
bshum |
Maybe it was hopkinsju_ |
15:00 |
bshum |
Or maybe it was you |
15:00 |
jboyer-isl |
cd |
15:00 |
* mmorgan |
remembers a recent discussion also. |
15:00 |
bshum |
Yeah, I thought mmorgan was there too |
15:01 |
bshum |
And we couldn't replicate the issue |
15:01 |
Bmagic |
darn |
15:03 |
Bmagic |
also, it only happens when there are no bills |
15:04 |
Bmagic |
when the only bill is the lost bill, 0 overdues |
15:05 |
Bmagic |
and the checkin voids the lost bill (the only bill) |
15:06 |
Dyrcona |
The bill was already paid? |
15:06 |
Bmagic |
no |
15:07 |
bshum |
Do you guys void the bill on item return? |
15:08 |
Bmagic |
yes, we void on return |
15:08 |
Bmagic |
at least in this scenario |
15:14 |
Bmagic |
I do get this |
15:14 |
Bmagic |
open-ils.circ.checkin.override: Use of uninitialized value in pattern match (m//) at /usr/local/share/perl/5.14.2/OpenILS/Application/Circ/Circulate.pm line 2409. |
15:17 |
Bmagic |
I see a line in the logs showing where it's not setting the xact_finish date (it needs to set the xact_finish to clear it out of the UI) |
15:21 |
pinesol_green |
[evergreen|Remington Steed] Docs: New screenshots for Conjoined Items section - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a67caae> |
15:22 |
mmorgan |
Bmagic: Did you say you had the code from lp 1331174 on your production server? |
15:22 |
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 |
15:22 |
Bmagic |
yep |
15:22 |
Bmagic |
this has crossed my mind |
15:22 |
mmorgan |
I haven't been able to complete testing successfully on kmlussier's servers. |
15:22 |
Bmagic |
I dont see any lines here that affect checkin |
15:24 |
mmorgan |
So you checkin, and that voids the Lost charge, right? |
15:25 |
Bmagic |
yes it does void the lost charge |
15:25 |
Bmagic |
which brings the transaction to 0 |
15:25 |
Bmagic |
and should* update xact_finish=now() but it doesnt |
15:25 |
jihpringle |
but the item still shows under other, right? |
15:25 |
Bmagic |
right, stays in the other/circulation section |
15:25 |
jihpringle |
we have the same problem on 2.8 |
15:25 |
mmorgan |
Bmagic: were there overdue fines paid on the transaction? |
15:26 |
Bmagic |
no overdue fines at all |
15:26 |
Bmagic |
just a single charge for the lost item, and it's voided upon checkin, but fails to close the transaction after the void |
15:27 |
Bmagic |
jihpringle: oh really? |
15:27 |
jihpringle |
we can reproduce on our live system but not on our server running stock 2.8 |
15:27 |
Bmagic |
what version is your live system? |
15:28 |
jihpringle |
2.8.1 |
15:28 |
jihpringle |
so far we've narrowed it down to being related to the library setting circ.lost.generate_overdue_on_checkin |
15:29 |
jihpringle |
a) If circ.lost.generate_overdue_on_checkin is TRUE or FALSE, the circ is closed and disappears from Items Out.b) If circ.lost.generate_overdue_on_checkin is NOT SET AT ALL, the circ is NOT closed and remains visible in Items Out. |
15:29 |
Bmagic |
wait, it doesn't have the issue on 2.8.1 but it does on 2.8 stock? |
15:29 |
jihpringle |
no, it has the issue on 2.8.1 but not on stock 2.8 |
15:29 |
Bmagic |
jihpringle: that is good intel, let me try that |
15:30 |
jihpringle |
we haven't found a reason for it behaving differently between stock 2.8 and our live server so if you find anything please let us know |
15:30 |
dbwells |
Bmagic: jihpringle: It could be another side-effect fixed by commit 4357ab325959f2ed48 |
15:30 |
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:31 |
dbwells |
That commit changed where the circ is inspected for close-worthiness, so it has a good chance of making a difference. |
15:32 |
jihpringle |
thanks, I'll get our techs to take a look |
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:36 |
Bmagic |
jihpringle: did you report a bug for this? |
15:37 |
jeffdavis |
I haven't been able to replicate the issue jihpringle mentions on stock 2.8 so far, so no, not reported in LP yet. |
15:37 |
jeffdavis |
Haven't been able to narrow it down to any customizations on our end either though. It's a stubborn one. |
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. |
15:43 |
bshum |
I can add a comment to the bug with that thought. |
15:43 |
bshum |
Just wonder if it's harder/easier, better/worse |
15:44 |
dbwells |
bshum: Yes, I am hoping for eventually a belt and suspenders type solution :D |
15:46 |
dbwells |
bshum: the perms are there to simply ensure we are controlling what actually happens, but I've also got checks for the settings in place. It looks like it'll work. |
15:46 |
bshum |
dbwells: For sure, cool deal. |
15:50 |
Bmagic |
bug 1484989 isn't in 2.8.1 |
15:50 |
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 |
15:50 |
bshum |
Bmagic: Right, it says 2.8.4 as the milestone target. |
15:51 |
bshum |
So... next week if we stay on schedule. |
15:51 |
Bmagic |
so, not sure how that would be affecting our bug. Or are you saying it will fix the bug? |
15:51 |
|
jlitrell joined #evergreen |
15:52 |
dbwells |
Bmagic: yes, I think it will fix the bug |
15:52 |
Bmagic |
I see, I was confused for a second. That sounds good |
15:52 |
Bmagic |
I'll cherry pick it and see what happens |
15:55 |
|
maryj joined #evergreen |
15:59 |
Stompro |
bmills, can I bug you about your self check setup/presentation? |
16:00 |
bmills |
@Stompro sure thing! |
16:00 |
pinesol_green |
bmills: You probably want hard-boiled eggs. |
16:00 |
bmills |
possibly.. |
16:01 |
Stompro |
bmills, can you give me some hints on how you got printing working with openkiosk? |
16:01 |
Stompro |
bmills, I'm working on that right now but I'm not sure where to start with paper sizes, margin settings, etc. |
16:01 |
* bshum |
whistles to himself as he looks up the names of files |
16:02 |
Stompro |
bmills, we are using Star TSP100 (143), which I think was mentioned in your presentation. But you also mentioned issues with getting printing working. |
16:03 |
Stompro |
bmills, was it you or Mielissa that was using openkiosk? |
16:03 |
Stompro |
*Melissa* |
16:04 |
bmills |
Stompro: let me dig back through the old notes just for a second |
16:05 |
bshum |
Stompro: bmills: http://markmail.org/message/afpbqigftln5eb54 |
16:05 |
bshum |
Wait, bad link, doh. |
16:06 |
bshum |
No, it's in there. |
16:06 |
bshum |
It's just buried deeper in the replies |
16:06 |
bshum |
You're looking for printer_* lines out of the prefs.js file |
16:07 |
Stompro |
bshum, Thanks... gah, those are recent, sorry I didn't remember reading them. |
16:07 |
bshum |
What we did was cheat and set up a printer using Firefox's GUI configs, and then copying over the relevant lines to the OpenKiosk file. |
16:08 |
kmlussier |
Just catching up on the negative balance discussion, and +1 to displaying the button based on the prohibit negative balance setting. Thanks dbwells for following up. |
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:10 |
bshum |
kmlussier: Maybe I will do that! |
16:10 |
dbwells |
ha |
16:11 |
dbwells |
bshum: "The Purge: Library Edition" |
16:12 |
bmills |
Stompro: we had tried using openkiosk but i remember it not working out for some reason. i think mceraso also encountered that. but it looks like bshum got it figured out. hood river is using the BlockSite and PublicFox addons currently and receipt printing is working out well using the templates from the presentation https://goo.gl/2DyyQs |
16:14 |
mmorgan |
Stompro: bmills: Here's the self check station doc I put together. See the printer config at the bottom. It was bshum that led me to the openkiosk printer stuff: https://docs.google.com/a/noblenet.org/document/d/1CEk8yV2ZyVkLNSCVJnmhzggHrMIUekJoq1G1oEO-yxg/edit?usp=sharing |
16:15 |
mmorgan |
bshum++ |
16:15 |
kmlussier |
mmorgan: We need to request permission to view it. |
16:16 |
Stompro |
bmills++,bshum++,mmorgan++ thanks for all the assistance. I'll see if I can get some of these tips into the official docs. |
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 |