| Time |
Nick |
Message |
| 02:02 |
|
ktomita joined #evergreen |
| 02:02 |
|
sseng joined #evergreen |
| 02:26 |
|
mtcarlson joined #evergreen |
| 04:11 |
|
mnsri joined #evergreen |
| 04:11 |
|
b_bonner joined #evergreen |
| 04:12 |
|
mtcarlson_away joined #evergreen |
| 04:42 |
|
b_bonner joined #evergreen |
| 04:42 |
|
mnsri joined #evergreen |
| 04:43 |
|
mtcarlson_away joined #evergreen |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:16 |
|
akilsdonk joined #evergreen |
| 08:27 |
|
Dyrcona joined #evergreen |
| 08:31 |
|
mrpeters joined #evergreen |
| 08:34 |
|
akilsdonk joined #evergreen |
| 08:40 |
|
Shae joined #evergreen |
| 08:42 |
|
finnx joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:45 |
csharp |
so... if one wanted to reduce the size of metabib.real_full_rec (currently 37GB) by deleting data from it, what is the best way to go about that? |
| 08:45 |
* csharp |
glances in eeevil 's direction ;-) |
| 08:46 |
eeevil |
csharp: one wouldn't :) ... you could cluster or vac-full, or reindex, if the "bloat query" says it's very bloated |
| 08:47 |
csharp |
yeah, bloat is an issue |
| 08:47 |
csharp |
however, my current concern is dwindling disk space on my reports replicas |
| 08:47 |
eeevil |
csharp: you could see if there are rows for deleted records and delete that, but I don't think you'll find any. that should get purged on delete |
| 08:47 |
csharp |
well, we have many rows for deleted records |
| 08:48 |
csharp |
680K deleted records from our bib cleanup a few years back |
| 08:48 |
csharp |
so those can be deleted without trouble? I'm looking for constraints for other tables, but don't see them |
| 08:49 |
eeevil |
if you aren't concerned about losing author/title/pub/isbn/etc on reports that pull data from those, you can remove that |
| 08:49 |
csharp |
ok cool |
| 08:49 |
csharp |
in my immediate instance, it's a test server we're using just for reports at the moment, so I'm willing to experiment |
| 08:49 |
eeevil |
historical reports (say, on circs from 2 years ago) will lose data |
| 08:49 |
csharp |
oh |
| 08:49 |
eeevil |
ah, yeah, for a test server I say "BURN IT ALL DOWN" |
| 08:50 |
eeevil |
but for production ... 37G is cheap, even on SSD, these days (IMNSHO ... I hate tossing data) |
| 08:51 |
csharp |
I don't like tossing data either... just looking for options ;-) |
| 08:51 |
csharp |
thanks |
| 08:58 |
|
akilsdonk_ joined #evergreen |
| 09:00 |
|
akilsdonk_ joined #evergreen |
| 09:28 |
|
kmlussier joined #evergreen |
| 09:28 |
jboyer-isl |
csharp: just out of curiosity, how often are vacuums run on your prod/reporter dbs? |
| 09:38 |
csharp |
jboyer-isl: I do VACUUM ANALYZE on the whole db each Sunday night |
| 09:38 |
csharp |
plus whatever autovacuum is doing |
| 09:43 |
jboyer-isl |
Not a lot to gain changing that I guess. I wondered because I think for a time our reporter was only being autovacuumed. On our last upgrade we started vacuum analyze-ing nightly for all dbs. |
| 09:45 |
csharp |
the weekly vacuum appears to keep bloat low |
| 09:50 |
|
tspindler joined #evergreen |
| 10:07 |
kmlussier |
tspindler: The problem you have with the default fiscal year is also happening at NOBLE. |
| 10:08 |
kmlussier |
So the MARC order record upload form appears to be defaulting to the calendar year instead of the default fiscal year set in acq.fiscal_year |
| 10:09 |
kmlussier |
Which is causing all sorts of problem when people forget to change the fiscal year, due to bug 1347090 |
| 10:09 |
pinesol_green |
Launchpad bug 1347090 in Evergreen "Uploading and activating orders with an inactive fund should not be possible" (affected: 2, heat: 12) [Medium,New] https://launchpad.net/bugs/1347090 |
| 10:11 |
|
finnx left #evergreen |
| 10:16 |
|
mllewellyn joined #evergreen |
| 10:18 |
|
jwoodard joined #evergreen |
| 10:21 |
|
akilsdonk joined #evergreen |
| 10:30 |
|
mjingle joined #evergreen |
| 10:44 |
|
remingtron_ joined #evergreen |
| 11:10 |
|
akilsdonk_ joined #evergreen |
| 11:14 |
|
vlewis joined #evergreen |
| 11:17 |
kmlussier |
mllewellyn/bshum: I know you use B&T a lot. I'm curious. Do your libraries send the po name in EDI messages? |
| 11:17 |
|
akilsdonk joined #evergreen |
| 11:17 |
tsbere |
I am not sure if this would be a good thing to add in, but I wrote it anyway: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/noimage_config |
| 11:18 |
kmlussier |
I'm seeing the po name in their messages now, but they say it's not coming through, so I'm wondering if they get the PO numbers from a different spot than Ingram does. |
| 11:19 |
dbs |
tsbere: looks like a good addition to me; for bonus points, dynamically generate an SVG with the first few title words & author name on the cover :) |
| 11:21 |
tsbere |
dbs: For MVLC I went this route for a placeholder for now, but for the community I hesitate to do something similar due to the "text in an image" issue: http://tomtrunk.mvlcstaff.org/opac/images/noimage_large.png |
| 11:21 |
tsbere |
Hence the "you need to provide your own" comments I believe I put in there ;) |
| 11:22 |
dbs |
tsbere: oh, yeah, avoiding the text-in-an-image thing by default would be good :) |
| 11:23 |
* tsbere |
considered circle with line through it type stuff in various colors, on and off of a logo, but came to the conclusion that people might put very different meanings on that kind of thing. Like "Not available in general" or something. |
| 11:24 |
phasefx |
question mark? |
| 11:24 |
tsbere |
phasefx: "We dunno, it may still be loading" jumped to mind for that. |
| 11:27 |
Dyrcona |
You could always let the browser provide its missing image image, but that will definitely raise questions. |
| 11:28 |
jeff |
and breaks caching. |
| 11:28 |
jeff |
which arguably the current "replace when onError indicates error" does also |
| 11:28 |
jeff |
though that... varies. |
| 11:28 |
bshum |
kmlussier: I am not sure what's in our EDI messages to B&T. I know that we don't do enriched EDI for all the accounts. The biggest library using B&T for us is Bridgeport and for A/V materials we don't process enriched EDI data because of special B&T needs. |
| 11:28 |
bshum |
Their books might have things in them. |
| 11:28 |
tsbere |
jeff: 404 with or without content doesn't change much on the caching front, to my knowledge. |
| 11:29 |
tsbere |
and either way this is still a 404 response as far as I know |
| 11:29 |
jeff |
tsbere: maybe i misread. |
| 11:29 |
* jeff |
re-reads |
| 11:29 |
kmlussier |
bshum: Yeah, we don't use enriched EDI either. But, for some of our libraries, the local PO# is required on the invoices to properly process them, so the PO name needs to be sent. |
| 11:30 |
bshum |
kmlussier: I think B&T also uses z3950 to look up specific copies to get the copy ID (which is a local customization we added once upon a time to our z3950 export holdings) |
| 11:30 |
tsbere |
jeff: All this does is provide an alternate errordocument, instead of blank.png, on 404 errors from jacket added content requests. And it is commented out by default on top of that. ;) |
| 11:30 |
tsbere |
jeff: Though the added content system may still be caching a "there was no jacket image" response in the background |
| 11:30 |
bshum |
I'm firing up my database connection to check out the template for PO JEDI, and I'll let you know what I find there. |
| 11:32 |
bshum |
kmlussier: It doesn't look like we enable INC_PO_NAME for the VENDOR_BT in our template |
| 11:32 |
bshum |
So I'm going with "no, we don't send that to them" |
| 11:32 |
kmlussier |
bshum: OK, thanks. |
| 11:37 |
jeff |
tsbere: no different from current methods with regard to client caching. i'll put my thoughts on that into a different bug. |
| 11:37 |
tsbere |
jeff: Not that I made a bug for this or anything yet. Just an "on a whim" branch for the moment ;) |
| 11:38 |
Dyrcona |
tsbere: I was going to suggest that make bugs for this and the content cafe xml post thing today, and add pullrequest tags. |
| 11:38 |
vlewis |
I need to set a default sort order search preference to sort bibs in Browse. I want to follow how the Advanced Search Default Pane sets adv_pane as an example. I'm trying to use js in a tt2 file but it isn't working. |
| 11:38 |
vlewis |
JSAN.use('OpenILS.data') |
| 11:38 |
vlewis |
data = new OpenILS.data(); |
| 11:38 |
vlewis |
data.init({'via':'stash'}); |
| 11:38 |
vlewis |
data.stash_retrieve(); |
| 11:39 |
vlewis |
Any suggestions? |
| 11:40 |
jeff |
vlewis: it would help to put the code you're working on in either a git working branch or post it to paste.evergreen-ils.org or gist.github.com (i recommend gist if there are multiple files) |
| 11:42 |
jeff |
vlewis: when you say it isn't working, are you getting errors? |
| 11:42 |
eeevil |
vlewis: I'm not sure I follow. browse is always ascii-betical sort (it's the only sort type that makes sense, because you're not looking at records but headings ... pubdate? relevance?), and there are backward and forward links. I don't think you can flip the sort, anyway |
| 11:42 |
jeff |
vlewis: and is this with authority browse, or shelf / call number browse? |
| 11:44 |
eeevil |
vlewis: IOW, what's the use case for z-a? |
| 11:45 |
jeff |
vlewis: also, i'm not certain you can use OpenILS.data and the stash from tpac, even in the staff client. |
| 11:45 |
mllewellyn |
kmlussier:yes, I believe the name is part of the EDI message. |
| 11:47 |
|
akilsdonk_ joined #evergreen |
| 11:48 |
mllewellyn |
kmlussier:I'm seeing it in the EDI message attached to the PO, but not in the EDI message body or the JEDI message body, so it's unclear to me what was transmitted. |
| 11:49 |
kmlussier |
mllewellyn: Based on what bshum said above, it sounds like it's not being sent for B&T. But you see it in the order response message? That's interesting. |
| 11:51 |
eeevil |
jeff / dbwells / Dyrcona / others-what-have-worked-on-tpac-and-friends: I'd like to draw attention to a new wishlist bug. I estimate about 3-5 days of actual work to get it done, and I'd like both feedback and assitance (if available): https://bugs.launchpad.net/evergreen/+bug/1347774 |
| 11:51 |
pinesol_green |
Launchpad bug 1347774 in Evergreen "Backend logic has leaked into the TPAC (and friends)" (affected: 1, heat: 6) [Wishlist,New] |
| 11:52 |
jeff |
eeevil: i'm in. |
| 11:53 |
mllewellyn |
kmlussier:sorry, no, not in the EDI or JEDI bodies of the message. Separated out and labeled as "Purchase Order", same as the outgoing EDI order. |
| 11:53 |
eeevil |
berick (who is not around to defend himself ;) ) and I looked into it the other day, and it seems there's maybe 30 uses of cstore, in various forms, and most are probably mechanical moves to an anon-pcrud service or json_query that can (should) be pushed to the backend pretty easily |
| 11:54 |
eeevil |
jeff: rock, thanks. I'm gathering tuits right now (none today, but wanted to get the request/proposal out early) |
| 11:54 |
mllewellyn |
kmlussier: this is the client view, so bshum probably sees more accurately from the database side. |
| 11:54 |
kmlussier |
mllewellyn: I see what you're saying now. |
| 11:55 |
kmlussier |
Yeah, it definitely isn't being sent then. I'm hoping it's just a simple tweak on their end to get the right PO# from our messages now that we're sending it. |
| 11:55 |
tsbere |
eeevil: In theory I have no complaints. I am not committing myself 100% because I haven't actually seen all of the issues you are vaguely referring to. ;) |
| 11:56 |
|
akilsdonk joined #evergreen |
| 11:57 |
mllewellyn |
kmlussier: question for you in the acq vein. One of my libraries accidentally cancelled a couple of POs, and I was able to reinstate them, their lineitems, deleted bibs and items, reset to "on-order" and removed the cancel_reason on all levels. But the original cancellation set the po encumbrance back to 0.00 and I can't figure out how to set it to the total again. Any ideas? |
| 11:57 |
tsbere |
eeevil: Too bad we can't specify a router for things to use. "EGCatLoader can only *use* things on the public router" would prevent issues like this from cropping up again later, right? |
| 11:58 |
eeevil |
tsbere: you can. by changing the client section of the opensrf_core.xml that mod_perl uses. but that's not the point -- the client code (mod_perl) should not be using private services |
| 11:59 |
mllewellyn |
kmlussier: we are transmitting the PO id. That's not sufficient? |
| 11:59 |
eeevil |
tsbere: and, indeed, that would be part of it -- make mod_perl use the gateway router in the default config, instead of the <opensrf> section |
| 11:59 |
eeevil |
<gateway> section, rather, containing the public-only router |
| 11:59 |
eeevil |
that's how it was before tpac, btw |
| 11:59 |
eeevil |
but tpac wanted access to json_query, which opened the door. now phonelist and others do the same |
| 12:00 |
dbwells |
eeevil: I agree it's an issue, and I'm game to helping where I can (though I'm not cetain you meant to include me and not some other db... fellow :) How do you envision dividing the work? |
| 12:00 |
eeevil |
dbwells: well, you were involved in the auth-proxy, yes? (am I misremembering?) |
| 12:01 |
dbwells |
eeevil: Yes, though I don't think I did the TPAC side. If memory serves, that is one of the overflow points, so I am glad to help with that. |
| 12:02 |
dbwells |
(or whatever else) |
| 12:02 |
tsbere |
eeevil: I was thinking more along the lines of "if the module could choose then we could have only those that need it do so" (whether or not the default is private or public being a different issue) followed by "when EGCatLoader doesn't need to, we switch it to public, and then we get failures instead of working code if we try and use private side calls without thinking in the future, thus ensuring we aren't on this topic a |
| 12:02 |
tsbere |
gain next year" |
| 12:02 |
eeevil |
also, I'm not asking for specific commitments (but I'll take them!) ... mainly buy-in (it's infrastructure) and sanity checking on the concept as a whole |
| 12:04 |
dbwells |
On second thought, maybe I did work that into TPAC. If so, I would admit that "get it working" was likely the only priority, since TPAC was all new to me back then. |
| 12:05 |
tsbere |
eeevil: I think I can get rid of at least one json_query |
| 12:05 |
kmlussier |
mllewellyn: hmmm...that's tricky. You were able to take a cancelled lineitem and set it back to on order in the client? |
| 12:05 |
tsbere |
with code I already wrote, even. <_< |
| 12:05 |
eeevil |
tsbere: if the mod_perl code is changed to use the gateway section, and then someone tries to use a private service in new code, their new code will break before it can even run ... not sure I'm seeing a risk. old EGC will use the <opensrf> section, new EGC will use the <gateway> section |
| 12:05 |
kmlussier |
mllewellyn: I think you would have to update the database directly to get the encumbrances back. |
| 12:05 |
dbwells |
I know complaints about spurious errors getting logged could be helped by some better middle-layer logic there. |
| 12:06 |
kmlussier |
mllewellyn: And, no, po id won't do it. The town needs the local PO number to process the invoice. We have a bunch of libraries with the same requirements, but they mainly deal with Ingram. |
| 12:06 |
eeevil |
tsbere: and, yes, any client-code json_query you can push to the back would be a win! |
| 12:07 |
tsbere |
eeevil: Let me re-phrase the mod_perl related "which router" comment: If we could have the module choose which router we could have the module determine if it needs private function access or not. Period. We then set EGC to "Public" mode (or maybe make Public default) and let other modules, as needed, decide they need private access. |
| 12:08 |
eeevil |
thanks, all, for taking a quick look. I (or berick) will update that bug with specific targets (grep finds them easily) and we can hungry-hungry-hippo them, if everyone's down for that |
| 12:08 |
tsbere |
eeevil: Then we don't accidentally open the door for EGC to use private again in the event that some other module does, in fact, need it for some reason |
| 12:09 |
dbwells |
eeevil: sounds good! |
| 12:09 |
eeevil |
tsbere: ah, I see, well, I'd like to completely disallow any mod_perl code from talking to a private service. sorry if that wasn't clear. if a frontend thing needs backend access, it'll need a public service to publish a method exposing that ... that's the idea |
| 12:09 |
eeevil |
"no more wire hangers. EVER!" :) |
| 12:09 |
tsbere |
eeevil: On the subject of removing a json_query, though: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/addedcontent_by_id_tpac - Note that this doesn't remove the fact that the AddedContent module still has the equiv query kicking around in a mod_perl context, though. |
| 12:10 |
mllewellyn |
kmlussier:I used SQL in the database to bring back the cancelled POs, lineitems, bibs, etc. But I can't figure out how the encumbrance links to the po in the database. |
| 12:10 |
Dyrcona |
eeevil: Do these concerns extend to CStoreEditor? I've always considered it a client sort of thing, but don't know if that was the original intention. |
| 12:11 |
eeevil |
Dyrcona: indeed they do, but(!) that would be transparent for non-authentication stuff, global search/retrieve. |
| 12:11 |
eeevil |
Dyrcona: specifically, that's what the anonymous-mode pcrud stuff would cover |
| 12:12 |
jeff |
eeevil: /c |
| 12:12 |
kmlussier |
mllewellyn: my sources here tell me it links to the lineitem. Hold on...I can dig a little further. |
| 12:12 |
jeff |
er. |
| 12:12 |
eeevil |
cstore editor would just use a pcrud personality (already possible) inside anything loaded by EGCatLoader (and friends) |
| 12:12 |
jeff |
apparently before clearing my screen i had intended to address something to eeevil. :P |
| 12:12 |
eeevil |
:) |
| 12:13 |
|
akilsdonk_ joined #evergreen |
| 12:14 |
mllewellyn |
kmlussier:thanks |
| 12:16 |
Dyrcona |
eeevil: I assume you want this to extend to something like NCIPServer and SIPServer? |
| 12:20 |
eeevil |
Dyrcona: ideally, yes, but I'd certainly accept that as a second step. they shouldn't be any more difficult than (and /should/ be easier) than the mod_perl |
| 12:20 |
eeevil |
s/than// |
| 12:23 |
Dyrcona |
I am not opposed, but I think this is going to more than a 3-5 day thing. :) |
| 12:23 |
|
akilsdonk joined #evergreen |
| 12:25 |
Dyrcona |
eeevil: Another question: Is OpenILS::Application::AppUtils considered public or private in this scheme? |
| 12:29 |
eeevil |
Dyrcona: that thing is decidedly back-end-ish. it basically only talks to storage and cstore directly. that said, there are a few things, like check_user_session, that are frontendy. (note, too, the name of the module ... it says "Application" right in the middle) |
| 12:30 |
Dyrcona |
eeevil: Yeah, but I never got the decoder ring in the mail. :) |
| 12:30 |
eeevil |
heh |
| 12:30 |
eeevil |
well, there's WWW, and Application ... they shouldn't mix |
| 12:31 |
eeevil |
I notice that most of the use of $U is for things like simplereq. that's not inherently bad |
| 12:31 |
eeevil |
(in the WWW stuff, I mean) |
| 12:31 |
Dyrcona |
I'm thinking about "client" software like SIPServer and NCIPServer which may or may not run under mod_perl. |
| 12:31 |
eeevil |
sure |
| 12:32 |
Dyrcona |
Is the recommendation there to stick to OpenSRF::AppSession? |
| 12:32 |
eeevil |
it's /my/ recommendation ;) ... |
| 12:32 |
Dyrcona |
That's good enough for me. |
| 12:33 |
Dyrcona |
eeevil: On an unrelated note, did you see what I shared on G+ last night? I mentioned you so hopefully you'd get a notification. It's about whisky. |
| 12:33 |
eeevil |
there are lots of niceties in AppUtils ... is_true, simplereq (but that's basically replaced by ->gather(1)), basic_opac_copy_query, event_equals |
| 12:33 |
eeevil |
all that is fine client-side |
| 12:33 |
eeevil |
Dyrcona: I didn't! /me looks |
| 12:34 |
eeevil |
but, we should split AppUtils into front and back chunks, prob |
| 12:34 |
dbs |
mllewellyn: when you say "I used SQL in the database to...", that really warms my heart :) |
| 12:34 |
Dyrcona |
OK. I started using CStoreEditor and AppUtils in NCIPServer. I can easily change those bits, though. |
| 12:35 |
Dyrcona |
As for splitting AppUtils, I agree. Some of the methods there are really handy. |
| 12:35 |
bshum |
dbs++ mllewellyn++ |
| 12:36 |
Dyrcona |
eeevil: Count me in. I can with high probability even help with code. |
| 12:36 |
eeevil |
Dyrcona++ |
| 12:36 |
* eeevil |
stashes the whisk[e]y video for later... |
| 12:38 |
bshum |
berick++ # make_release patch worked for me. I'll push it and then finish testing this 2.7.0-alpha tarball and get it up to Lupin |
| 12:41 |
dbs |
eeevil: so $hours = $self->editor->retrieve_actor_org_unit_hours_of_operation($lib_id); |
| 12:41 |
dbs |
in EGCatLoader/Library.pm -- that's considered "bad"? |
| 12:41 |
* eeevil |
consults idl... |
| 12:42 |
* dbs |
isn't absolutely clear on where the lines are supposed to be drawn; maybe some docs on the "Developing TPAC" front would help as part of that effort. |
| 12:42 |
pinesol_green |
[evergreen|Bill Erickson] LP#1334693 make_release optional -j <osrf_js_path> - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ff25ed5> |
| 12:43 |
eeevil |
dbs: no, that will magically work under my proposal. an anon-mode pcrud will allow search/retrieve where the <retrieve> action has no perm requirements in the idl |
| 12:43 |
dbs |
okay |
| 12:46 |
eeevil |
dbs: and, $self->editor->retrieve_actor_usr($id) will work fine, if you have a sess cookie (or the like), and have perms for that user (or are that user, and we add owning_user="id" to aou) |
| 12:47 |
eeevil |
dbs: for context re owning_user, see: https://bugs.launchpad.net/evergreen/+bug/1254918 (and http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1254918-combined-pcrud-perms-and-fund-filter ) |
| 12:47 |
pinesol_green |
Launchpad bug 1254918 in Evergreen "rendering the fund drop-down in the line batch update controls can be slow" (affected: 6, heat: 30) [Medium,Fix committed] |
| 12:47 |
eeevil |
(my commit on that) |
| 13:04 |
mllewellyn |
dbs:you gave me my start. |
| 13:04 |
mllewellyn |
dbs++ |
| 13:05 |
kmlussier |
@praise dbs |
| 13:05 |
* pinesol_green |
dbs can run a report without assistance |
| 13:05 |
bshum |
How appropriate :) |
| 13:12 |
csharp |
@praise add Shall I compare $who to a summer's day? $who is more lovely and more temperate. |
| 13:12 |
pinesol_green |
csharp: The operation succeeded. Praise #6 added. |
| 13:15 |
Dyrcona |
@praise 6 csharp |
| 13:15 |
* pinesol_green |
Shall I compare csharp to a summer's day? csharp is more lovely and more temperate. |
| 13:15 |
kmlussier |
Nice! I like that praise csharp. |
| 13:17 |
|
remingtron__ joined #evergreen |
| 13:17 |
|
collum joined #evergreen |
| 13:17 |
Dyrcona |
Just in case you didn't know you can choose the praise you give. |
| 13:18 |
Dyrcona |
@praise 4 kmlussier |
| 13:18 |
* pinesol_green |
the upgrade came off brilliantly, and it's all because of kmlussier |
| 13:19 |
kmlussier |
:) |
| 13:19 |
bshum |
@dessert 5 kmlussier |
| 13:19 |
* pinesol_green |
grabs some of mllewellyn's Cupcakes for kmlussier |
| 13:19 |
Dyrcona |
And, looks like we'll be updating production on the 10th of August. |
| 13:20 |
Dyrcona |
We just made a branch and loaded it on training for our members to look at. |
| 13:21 |
Dyrcona |
It |
| 13:21 |
Dyrcona |
oops |
| 13:26 |
|
akilsdonk joined #evergreen |
| 13:28 |
bshum |
Remind me, did we put the test builds to the left or right of the current stables on the downloads page usually? |
| 13:28 |
bshum |
I want to say to the right so that latest stable is always at the left |
| 13:28 |
bshum |
But I can't quite recall |
| 13:36 |
eeevil |
bshum: right, I'm pretty certain |
| 13:38 |
bshum |
eeevil: Thanks, just checking. I'm going to edit up the page in a moment to put up the 2.7 files. |
| 13:38 |
bshum |
I suppose at the same time, we can remove 2.4 since that series is ended. |
| 14:00 |
|
Wyuli joined #evergreen |
| 14:05 |
|
_bott_ joined #evergreen |
| 14:08 |
bshum |
gmcharlt: Since I was poking at Wordpress, I updated it to the latest release and then also updated all the themes and plugins too. |
| 14:08 |
gmcharlt |
bshum++ |
| 14:13 |
jeff |
bshum++ |
| 14:14 |
bshum |
I think I broke the google search widget, I'm fixing it. |
| 14:16 |
* Dyrcona |
wonders if he should be concerned about an email from edi_fetcher.pl with about 17 lines of this: Use of uninitialized value $li_id in concatenation (.) or string at /usr/local/share/perl/5.14.2/OpenILS/Application/Acq/EDI.pm line 650. |
| 14:16 |
bshum |
There we go |
| 14:23 |
dbs |
mllewellyn++ # you kept rolling! |
| 14:26 |
Dyrcona |
So, looks like that message means the vendor sent a file with 17 line items that have undefined ids. |
| 14:26 |
Dyrcona |
vendors-- |
| 14:27 |
* jeff |
is still bitter about "here, have some XML with raw control characters -- and you'd darn well better respond, or i'll just send you the same thing over and over again until you do!" |
| 14:28 |
Dyrcona |
Don't s'pose there is anything that I can do about that. |
| 14:28 |
jeff |
bitter might not be the right word. |
| 14:28 |
jeff |
dunno. |
| 14:29 |
kmlussier |
Hmm...C/W MARS once had an issue where the vendor was sending invoices combining titles ordered through EDI with titles not ordered through EDI. I can't recall which vendor it was, but maybe it's the same issue. tspindler, do you remember which vendor it was? |
| 14:29 |
Dyrcona |
jeff: You should have just sent them the NCIP LookupVersion response every time. It's perfectly legit. |
| 14:31 |
jeff |
Dyrcona: yup. i've been working to confirm the MVNR, or "minimum valid NCIP response" ;-) |
| 14:31 |
Dyrcona |
jeff: Just pick a random problem and send a problem response. :) |
| 14:31 |
jeff |
since in this case the initiator cares Not One Bit about if the request was successful or not |
| 14:32 |
Dyrcona |
Or better, yet, firewall them out. (But I know that is not really an option.) |
| 14:32 |
|
krvmga joined #evergreen |
| 14:33 |
krvmga |
dontcha just hate it when some thing is working right and then, for no discernable reason stops working right? |
| 14:33 |
krvmga |
http://bark.cwmars.org/eg/opac/advanced |
| 14:33 |
jeff |
Dyrcona: have you found yourself wanting to maintain state on NCIP requests external from Evergreen? For things like detecting / ignoring / fixing violations of a request state machine, such as an ItemShipped with no ItemRequested, etc? |
| 14:34 |
krvmga |
in my config.tt2, i've got the adv_break => 1 to break the line of boxes into two rows |
| 14:34 |
krvmga |
it was working, suddenly it's not. i can't see why. |
| 14:34 |
Dyrcona |
jeff: No, I haven't. |
| 14:34 |
Dyrcona |
jeff: I also thought the check for duplicate message in iNCIPit was a bit odd. |
| 14:34 |
jeff |
Dyrcona: iNCIPit used to have that basic "ignore duplicate messages" bit, but 1) it broke things like LookupUser and 2) the "write request to file" method of duplicate detection didn't work without a shared filesystem |
| 14:35 |
Dyrcona |
; |
| 14:35 |
Dyrcona |
:) |
| 14:35 |
jeff |
Dyrcona: i started to look into "use memcached or something else and exclude LookupUser" but then received direction from MCLS that the duplicate detection was no longer needed and caused problems, so I just removed it. |
| 14:36 |
Dyrcona |
jeff: My thought when I saw it was "this is totally unnecessary." |
| 14:37 |
Dyrcona |
jeff: We have a rather restricted message set to support in NCIPServer as a start. More will likely be added later, I'm sure. |
| 14:37 |
tsbere |
krvmga: I find myself wondering what you are expecting compared to what you configured |
| 14:41 |
krvmga |
tsbere: what i configured was for the boxes to appear in three rows |
| 14:41 |
krvmga |
now they appear stacked |
| 14:41 |
kmlussier |
Dyrcona: I'm looking at https://bugs.launchpad.net/evergreen/+bug/1172373, which leads me to believe Evegreen should now be able to handle an invoice with a mix of EDI and non-EDI lineitems. So whatever caused your error probably isn't what I first thought. |
| 14:41 |
pinesol_green |
Launchpad bug 1172373 in Evergreen 2.4 "Acq: In EDI invoices, avoid taking reference to PO too seriously" (affected: 3, heat: 18) [Medium,Fix released] |
| 14:41 |
tsbere |
krvmga: In particular, I suspect you are missing the float:left in your style.css |
| 14:41 |
tsbere |
krvmga: Which is, obviously, not a config.tt2 thing ;) |
| 14:42 |
krvmga |
checking |
| 14:45 |
krvmga |
looked through style.css.tt2 and find lots of float:left |
| 14:45 |
Dyrcona |
kmlussier: My error is coming from process_parsed_msg, which doesn't appear to have been touch by the code on that bug. |
| 14:45 |
tsbere |
krvmga: What about on .adv_filter_block and .adv_filter_block_item specifically? |
| 14:45 |
krvmga |
checking |
| 14:46 |
krvmga |
tsbere: yes, both have float:left |
| 14:49 |
jboyer-isl |
krvmga: They all have id=adv_filter_block_etc. Try changing that to class=adv_filter_block_etc. |
| 14:49 |
* tsbere |
was just noticing that |
| 14:50 |
tsbere |
krvmga: I don't know why your search.tt2 file had that change made, but it will break a lot more than just that ;) |
| 14:50 |
krvmga |
tsbere: neither do i since i didn't do it. |
| 14:50 |
krvmga |
looking now |
| 14:55 |
|
Wyuli joined #evergreen |
| 14:55 |
krvmga |
tsbere: should id=''adv_chunk also be changed to class='adv_chunk? |
| 14:55 |
krvmga |
or only filter_block and filter_block_item? |
| 14:57 |
tsbere |
krvmga: I would compare it to a stock version and see what has been changed |
| 14:57 |
krvmga |
tsbere: i had no customized search.tt2 -- this is the search.tt2 that came with our 2.5 installation |
| 14:57 |
tsbere |
krvmga: In general, changing *any* class= to id= in any of the tt2 files is probably a bad thing in a customization, but so would changing things that are supposed to be id= to class= |
| 14:59 |
krvmga |
tsbere: at any rate, changing adv_filter_block and adv_filter_block_item from id to class fixed the problem. |
| 14:59 |
tsbere |
krvmga: In that case I don't know why it is that way in 2.5, in master it is class= in the right places. And I don't ever run numbered releases myself or normally follow their progress. |
| 15:02 |
|
hbrennan joined #evergreen |
| 15:08 |
bshum |
Maybe it's WCAG stuff? |
| 15:08 |
bshum |
From 2.6+ |
| 15:08 |
* bshum |
doesn't know anything and should read scroll back further. Ignore me. |
| 15:12 |
krvmga |
tsbere++ |
| 15:12 |
krvmga |
jboyer-isl++ |
| 15:57 |
gmcharlt |
@librarian |
| 15:57 |
pinesol_green |
gmcharlt: Management:16, Cataloging:12, Acquisitions:11, Reference:14, Circulation:13, Systems:8, Research:9, Custodial:17 |
| 15:58 |
gmcharlt |
time for me to administer an army of mops, a la the Sorcerer's Apprentice! |
| 15:58 |
bshum |
Oh great, thanks gmcharlt. Now that song is in my head.... |
| 15:59 |
gmcharlt |
just think of earworm distribution as a specialization of readers' advisory |
| 16:05 |
|
Shae_ joined #evergreen |
| 16:28 |
|
tspindler left #evergreen |
| 17:23 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:23 |
|
kmlussier left #evergreen |
| 17:24 |
|
mmorgan left #evergreen |
| 17:55 |
|
akilsdonk joined #evergreen |
| 18:10 |
|
mrpeters left #evergreen |
| 18:15 |
|
shadowspar joined #evergreen |
| 19:20 |
|
mrpeters joined #evergreen |
| 19:30 |
|
mjingle joined #evergreen |
| 19:53 |
|
Dyrcona joined #evergreen |
| 19:54 |
|
mjingle joined #evergreen |
| 19:57 |
|
mjingle left #evergreen |
| 20:32 |
|
mtcarlson joined #evergreen |
| 21:06 |
|
gsams joined #evergreen |
| 21:50 |
|
akilsdonk joined #evergreen |
