| Time |
Nick |
Message |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 08:12 |
|
Dyrcona joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:44 |
|
_adb joined #evergreen |
| 08:46 |
|
kmlussier joined #evergreen |
| 08:54 |
|
bos20k joined #evergreen |
| 08:58 |
|
dbwells joined #evergreen |
| 10:08 |
|
jvwoolf joined #evergreen |
| 10:27 |
kmlussier |
I never noticed that the xul client's view holds screen can show holds by requesting library, not just by pickup library. |
| 10:29 |
* mmorgan |
actually never noticed that either. In defense, requesting library is not a particularly useful field for us. |
| 10:30 |
kmlussier |
mmorgan: That's what I was wondering. It's not in the web client, but if it's never used, it's probably not worth filing a bug. |
| 10:33 |
mmorgan |
Might be useful for systems that have some restrictions on sharing resources, but I'm just guessing. |
| 10:33 |
Dyrcona |
I'd say let the one who misses it open the bug. |
| 10:36 |
|
ohiojoe_ joined #evergreen |
| 10:47 |
Dyrcona |
Grr. Launchapd.... |
| 10:47 |
Dyrcona |
I filed the bug under OpenSRF, but added that it also affects Evergreen, and Lp redirected me to the Evergreen bug link.... Not what I expected. |
| 10:48 |
Dyrcona |
Lp 1725317 |
| 10:48 |
pinesol_green |
Launchpad bug 1725317 in OpenSRF ""XML stanza is too big" still possible with chunking and bundling" [Undecided,New] https://launchpad.net/bugs/1725317 |
| 11:00 |
pinesol_green |
[evergreen|Bill Erickson] LP#1656036 Webstaff dynamic page titles - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0d050c0> |
| 11:06 |
kmlussier |
gmcharlt: Would object to me backporting bug 1715423 to 3.0? It looks like it's only been merged to master. |
| 11:06 |
pinesol_green |
Launchpad bug 1715423 in Evergreen "Web Client: patron ID values not shown in patron summary" [Low,Fix committed] https://launchpad.net/bugs/1715423 |
| 11:16 |
* kmlussier |
makes an executive decision and backports it. |
| 11:20 |
Dyrcona |
heh |
| 11:24 |
* Dyrcona |
tries to gather more log messages for failures that he thinks are related to chunking and bundling. |
| 11:27 |
Dyrcona |
I'd be a bit circumspect in backporting web staff client fixes to 2.12, but that's me. |
| 11:27 |
Dyrcona |
I suppose if they merge cleanly, then they should be OK. |
| 11:28 |
kmlussier |
Dyrcona: In general, I've been backporting them if they merge cleanly. Or if the merge conflict seems minor. |
| 11:28 |
kmlussier |
But I just came across one that I've decided isn't worth the trouble. |
| 11:28 |
Dyrcona |
kmlussier: I don't think I'd bother if there's any conflict at all, not worth the effort. |
| 11:28 |
Dyrcona |
:) |
| 11:29 |
kmlussier |
Well, since 2.12 was the pilot period for the web client and we said we would try to fix bugs as people found them, I feel compelled to keep those bug fixes going in as long as we can. |
| 11:30 |
Dyrcona |
OK. |
| 11:42 |
miker |
Dyrcona: huh, yeah... the gateways are not chunking large messages |
| 11:43 |
* miker |
just looked at the new bug |
| 11:44 |
Dyrcona |
I have an acq issue that I think is the same thing. I can add the logs if you like, or wait to test a fix. |
| 11:45 |
* Dyrcona |
is still gathering the log information and likely won't have it all together until Monday, anyway. |
| 11:45 |
miker |
Dyrcona: if you can past the logs, that'd be good. I've got a small itch in the back of my mind re the router, now... |
| 11:46 |
miker |
and I certainly won't have a fix ready before monday... |
| 11:46 |
miker |
*post |
| 11:46 |
Dyrcona |
I have a find running through the logs on the syslog server for the invoice id, then I'll have to sort what is related to the acq bug and go back and find more relevant log entries. |
| 11:47 |
Dyrcona |
It's interesting how many different objects get the same id number, and how often a certain string of numbers shows up in a larger number. :) |
| 11:48 |
miker |
"interesting" ... |
| 11:49 |
miker |
btw, I have a theory on why the thread trace keeps changing |
| 11:50 |
|
bos20k joined #evergreen |
| 11:50 |
* mmorgan |
waits for the theory... |
| 11:50 |
miker |
I think it's inc-ing where it shouldn't somewhere in the send() stack |
| 11:51 |
Dyrcona |
OK. |
| 11:51 |
Dyrcona |
That has bugged me, but I've never looked into it. |
| 11:57 |
berick |
kmlussier++ # bug 1656036 -- i was on the fence about backporting that one too. |
| 11:57 |
pinesol_green |
Launchpad bug 1656036 in Evergreen "Web based staff client needs tab details on the tab label" [Medium,Fix committed] https://launchpad.net/bugs/1656036 |
| 11:59 |
kmlussier |
berick: I have some follow-up bugs I want to submit related to that one, but I agreed with your comment that we should get the base in there and then tweak individual interfaces where we can. |
| 11:59 |
berick |
kmlussier: yeah, lots of titles need setting... |
| 12:00 |
|
khuckins joined #evergreen |
| 12:45 |
|
krvmga joined #evergreen |
| 12:51 |
|
khuckins_ joined #evergreen |
| 13:03 |
|
kmlussier joined #evergreen |
| 13:23 |
|
khuckins__ joined #evergreen |
| 13:33 |
|
yboston joined #evergreen |
| 13:46 |
|
sandbergja joined #evergreen |
| 14:19 |
|
Dyrcona joined #evergreen |
| 14:22 |
miker |
berick: do you recall if, when an XMPP message bounces because the recipient is gone, the entire message, along with an error about the delivery failure, is send to the original sender? |
| 14:23 |
miker |
recent-ish documentation suggests it should not be, but I seem to recall the body being inside an <error> element |
| 14:25 |
berick |
miker: that sounds very familiar. i know there's an error element. and there is to/from info. don't know if the actual body is present, though. |
| 14:26 |
berick |
see if I can find an evidence of that.. |
| 14:34 |
berick |
no evidence in the C code of using the body of a bounce/error message. it just inspects the error codes. doesn't mean it's not there, of course. |
| 14:37 |
hbrennan |
Is the On Shelf Pull List (Circulation > Pull List for Hold Requests) an action trigger function? |
| 14:37 |
kmlussier |
@coin |
| 14:37 |
pinesol_green |
kmlussier: heads |
| 14:40 |
csharp |
hbrennan: I think so - at least one of the variants is controlled by A/T |
| 14:40 |
hbrennan |
:) |
| 14:40 |
hbrennan |
I can't seem to ever find the A/T I'm looking for unless it's on the first page |
| 14:41 |
csharp |
sec... |
| 14:41 |
hbrennan |
csharp++ |
| 14:42 |
csharp |
should be called "Holds Pull List" (id 35 in our DB) |
| 14:42 |
hbrennan |
csharp: Thanks! |
| 14:42 |
hbrennan |
Upgraded to 3.0.0 Wednesday :) |
| 14:42 |
hbrennan |
Picking up the pieces now |
| 14:42 |
kmlussier |
hbrennan / csharp: I was trying to remember which pull list uses an action trigger. |
| 14:44 |
csharp |
hbrennan++ # pioneering for the rest of us |
| 14:44 |
kmlussier |
hbrennan: Found it. Print Full Pull List is the one using the action trigger. http://markmail.org/message/f6ghfoqnlrvqvtny |
| 14:44 |
kmlussier |
hbrennan++ indeed |
| 14:45 |
csharp |
we broke down the options a few years ago: https://pines.georgialibraries.org/tip-pull-lists |
| 14:45 |
kmlussier |
hbrennan: Is it going fairly smoothly so far? |
| 14:46 |
hbrennan |
Thanks! |
| 14:46 |
hbrennan |
So far so good |
| 14:46 |
hbrennan |
I think things broke because we moved the whole database so we could test it out before. |
| 14:47 |
hbrennan |
Emails were being generated yesterday for courtesy notices, but getting stuck because some piece of Outlook was different |
| 14:47 |
hbrennan |
Just those types of issues |
| 14:47 |
|
mmorgan joined #evergreen |
| 14:47 |
hbrennan |
Staff (besides me) haven't had any trouble |
| 14:53 |
kmlussier |
hbrennan: Are people using the web client or are they still using the xul client? |
| 14:54 |
hbrennan |
Xul client for now. About half our staff is out this week |
| 14:54 |
hbrennan |
I haven't trained anyone on Webby yet |
| 14:54 |
hbrennan |
but oh is it nice to see our data in the web client! |
| 14:56 |
kmlussier |
:) |
| 15:06 |
hbrennan |
Stuck cron job fixed and now notices are flowing normally equinox++ |
| 15:52 |
miker |
berick: oh, sorry, I didn't mean before that we used it, just that I recall the ejabberd behavior being that an undeliverable message contains the original body along with (perhaps inside of) the error element |
| 16:03 |
berick |
miker: yeah, i gotcha, I just didn't have a solid answer. i was hoping to find a case where we used the error body as evidence it exists, but not seeing any. |
| 16:04 |
|
Christineb joined #evergreen |
| 16:07 |
berick |
miker: looks like returning the <body> is optional and should not be relied on |
| 16:07 |
berick |
https://xmpp.org/rfcs/rfc6120.html#stanzas-error-rules |
| 16:08 |
berick |
The entity that returns an error stanza MAY include the original XML sent so that the sender can inspect and, if necessary, correct the XML before attempting to resend (however, this is a courtesy only and the originating entity MUST NOT depend on receiving the original payload). |
| 16:08 |
berick |
but again that doesn't mean it's not there |
| 16:09 |
miker |
aye ... I suspect that in the case I care about, ejabberd is sending the body back |
| 16:09 |
berick |
which I assume is the real question (for chunking, etc.) |
| 16:09 |
berick |
yeah, probably |
| 16:09 |
miker |
since it's a simple delivery issue, and it's got the data handy |
| 16:09 |
berick |
yeah |
| 16:49 |
|
Jillianne joined #evergreen |
| 16:53 |
kmlussier |
Have a nice weekend #evergreen! |
| 17:01 |
|
mmorgan left #evergreen |
| 17:25 |
|
jvwoolf left #evergreen |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:30 |
|
khuckins_ joined #evergreen |
