| Time |
Nick |
Message |
| 02:12 |
|
jeff joined #evergreen |
| 02:12 |
|
jeff joined #evergreen |
| 02:47 |
paxed |
bshum: looking at 502f93ac it would've been nice if my branch for bug 491712 were incorporated at the same time. :P |
| 02:47 |
pinesol_green |
[evergreen|Ben Shum] TPAC: Add format icon back to search results - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=502f93a> |
| 02:47 |
pinesol_green |
Launchpad bug 491712 in Evergreen "ALT text for format icons on search results page is always in English" (affected: 2, heat: 10) [Undecided,Triaged] https://launchpad.net/bugs/491712 |
| 03:30 |
|
kollex joined #evergreen |
| 05:25 |
|
kollex left #evergreen |
| 06:24 |
|
Guest74226 joined #evergreen |
| 06:28 |
|
jeff___ joined #evergreen |
| 06:32 |
|
jeff___ joined #evergreen |
| 06:59 |
|
timf joined #evergreen |
| 07:00 |
|
jeff___ joined #evergreen |
| 07:13 |
|
jeff___ joined #evergreen |
| 07:24 |
|
jeff joined #evergreen |
| 07:24 |
|
jeff joined #evergreen |
| 07:35 |
|
jboyer-isl joined #evergreen |
| 07:43 |
|
rjackson-isl joined #evergreen |
| 07:56 |
csharp |
@quote random |
| 07:56 |
pinesol_green |
csharp: Quote #41: "<phasefx> when you guys stab me later, make sure it's with a double-dagger" (added by gmcharlt at 05:23 PM, January 07, 2013) |
| 08:00 |
|
jeff joined #evergreen |
| 08:15 |
|
Dyrcona joined #evergreen |
| 08:16 |
|
jeff joined #evergreen |
| 08:16 |
|
jeff joined #evergreen |
| 08:27 |
bshum |
paxed: That's weird.... My memory tells me that I remember that bug from during the time we were poking at mobile TPAC (which is when that commit happened) but obviously nothing came of it. |
| 08:28 |
bshum |
Clearly my memory is wrong. I'll try taking a look at that later this morning if I can. |
| 08:29 |
|
akilsdonk joined #evergreen |
| 08:36 |
Dyrcona |
MySQL-- |
| 08:37 |
jboyer-isl |
Dyrcona: But, the slashdots! |
| 08:38 |
jboyer-isl |
Aw, my t-e-h was autocorrected. :/ |
| 08:38 |
Dyrcona |
No referential integrity unless you use a specific table type, and of course, my client's web host doesn't have that table type available. |
| 08:38 |
Dyrcona |
heh. |
| 08:39 |
Dyrcona |
And somehow, someone managed to "orphan" 4 maintenance agreements by deleting the invoices that they should be attached to. |
| 08:40 |
Dyrcona |
Erm, that's even more peculiar.... |
| 08:40 |
Dyrcona |
Oh well, it's off topic here. |
| 08:40 |
jboyer-isl |
Maybe that's good in this case? Are these clients the type to dutifully follow the helpful instructions that some Dbs give? "That didn't work, try adding CASCADE" |
| 08:41 |
Dyrcona |
jboyer-isl: There are supposed to keep the fingers in das pockets und waschen das blinkenlights when it comes to the database. |
| 08:42 |
Dyrcona |
jboyer-isl: Looks like somehow, you can add a maintenance agreement without there actually being an invoice. |
| 08:42 |
jboyer-isl |
Sounds excellent. |
| 08:42 |
Dyrcona |
Oh well. I only discovered that incidentally while looking into why an invoice "disappeared." |
| 08:44 |
Dyrcona |
I should propose an overhaul of the code. |
| 08:44 |
Dyrcona |
It's current best practices as of about 2000, when I started working on it. |
| 08:44 |
jboyer-isl |
Viking Funeral sounds like a plan. |
| 08:45 |
Dyrcona |
One of the libraries it uses is deprecated and slated for removal in the next version of PHP and it could really take advantage of some HTML 5 features. |
| 08:45 |
|
mrpeters joined #evergreen |
| 08:45 |
Dyrcona |
Oh well, back to work on Evergreen stuff. |
| 08:46 |
Dyrcona |
Of course, I think they're hosted on CentOS, so no danger of getting PHP updated any time soon. :) |
| 08:48 |
|
dddtest_378e1 joined #evergreen |
| 08:49 |
jboyer-isl |
Whenever I hear of CentOS I can only think of the time someone in Tuttle, Oklahoma threatened to report them to the FBI them because a website went down. Makes me laugh every time. http://www.theregister.co.uk/2006/03/24/tuttle_centos/ |
| 08:50 |
|
mmorgan joined #evergreen |
| 08:50 |
jeff |
I think less-amusing things when I hear CentOS |
| 08:51 |
jeff |
All the pain of RHEL, with none of the support. |
| 08:53 |
|
Shae joined #evergreen |
| 08:55 |
|
kbeswick joined #evergreen |
| 08:55 |
Dyrcona |
jeff++ |
| 08:57 |
Dyrcona |
@quote add jeff: All the pain of RHEL, with none of the support. |
| 08:57 |
pinesol_green |
Dyrcona: The operation succeeded. Quote #69 added. |
| 08:57 |
mrpeters |
how could someone pull this off? http://pastie.org/8442590 isn't it one label per lib? |
| 08:57 |
mrpeters |
this had to be someone dropping a rule and inserting them or something, right? |
| 08:58 |
Dyrcona |
mrpeters: I'd check if the rule still exists in the database, but that is what it looks like. |
| 08:59 |
mrpeters |
it does, because when i try to migrate in some new volumes i hit the dupe key error |
| 08:59 |
mrpeters |
i would have thought someone would have gotten the error when they put the rule back on though |
| 08:59 |
Dyrcona |
Looks like it wasn't there for two days in May at least. |
| 09:00 |
Dyrcona |
No. Integrity rules aren't usually retroactive. |
| 09:00 |
mrpeters |
yeah, agreed |
| 09:00 |
mrpeters |
oh, no? ok cool that makes sense then |
| 09:00 |
Dyrcona |
It depends though, if it is an index that must be unique, I think the index fails to create. |
| 09:00 |
mrpeters |
we're talking about asset_call_number_label_once_per_lib yeah? |
| 09:00 |
Dyrcona |
Yes, believe so. |
| 09:01 |
|
dddtest_4038a joined #evergreen |
| 09:01 |
Dyrcona |
If its an on insert or update trigger, it won't be retroactive. |
| 09:01 |
mrpeters |
gotcha |
| 09:01 |
mrpeters |
well time to do some cleanup i suppose! |
| 09:02 |
|
ericar joined #evergreen |
| 09:02 |
csharp |
jboyer-isl: wow - just reading that Tuttle article - wild! |
| 09:03 |
mrpeters |
oh good god, this goes deep |
| 09:03 |
mrpeters |
57,285 duplicate CN labels at various branches |
| 09:03 |
mrpeters |
who in the world did these migrations |
| 09:04 |
Dyrcona |
mrpeters: Alpha G? |
| 09:04 |
mrpeters |
^^^ think so |
| 09:04 |
Dyrcona |
It sounds like their MO, drop constraints and insert stuff. |
| 09:04 |
csharp |
jeez |
| 09:05 |
mrpeters |
ugh |
| 09:05 |
mrpeters |
what a shame |
| 09:05 |
mrpeters |
a simple 8 hour migration just turned into a lot of work |
| 09:06 |
Dyrcona |
They always do. |
| 09:06 |
jboyer-isl |
csharp: I had 22 years in computer magicks! Don't tell me my website is an operating system! |
| 09:06 |
mrpeters |
i knew this one was going way too smoothly |
| 09:06 |
Dyrcona |
There's no such thing as a simple migration. |
| 09:08 |
* Dyrcona |
often thinks of going back to the easy stuff: 3-D engines, games... |
| 09:08 |
rjackson-isl |
Hopefully my simple migration over the weekend is just that! :-) |
| 09:09 |
Dyrcona |
Not bloody likely. ;) |
| 09:09 |
rjackson-isl |
fingers and toes crossed... |
| 09:09 |
mrpeters |
hah you've run your system well rjackson-isl you shouldnt have anything like this to fear |
| 09:10 |
Dyrcona |
rjackson-isl: What ILS is the data coming from? |
| 09:10 |
rjackson-isl |
mrpeters - you should remember the time I merged record AFTER creating the call number entries.... OUCH |
| 09:10 |
rjackson-isl |
It is Follett |
| 09:10 |
rjackson-isl |
the initial extract and load went smoothly |
| 09:10 |
rjackson-isl |
data is pretty clean for a change |
| 09:10 |
mrpeters |
we all make mistakes rjackson-isl, you're a pro at migrations now i know it |
| 09:10 |
Dyrcona |
I have no experience with data from a Follett system. |
| 09:11 |
mrpeters |
this one was SUPER clean, it came from an excel spreadsheet haha |
| 09:11 |
Dyrcona |
hah |
| 09:11 |
rjackson-isl |
I liked the ones we did from DBase! |
| 09:11 |
mrpeters |
BSLW did some nice conversion to MARC, deduped against OCLC and we got some awesome records out of it |
| 09:11 |
mrpeters |
it was just a matter of a simple SQL script to create items and I was done....am done....except for the CN collisions |
| 09:12 |
rjackson-isl |
I think mrpeters had the most fun with ISL data though! ;-) |
| 09:12 |
mrpeters |
no, honestly, that migration wasnt bad at all |
| 09:12 |
mrpeters |
it was the big bad scary monster but when it came down to it it was very straight forward |
| 09:13 |
mrpeters |
we had to have gmcharlt write us some enhancements to extract_holdings but other than tht it was smooth sailing |
| 09:13 |
mrpeters |
wow, this problem goes back to 9/2009 |
| 09:13 |
rjackson-isl |
I was along for the ride on that one - trying to keep up! |
| 09:14 |
mrpeters |
well you should still have all of my scripts, and if you don't I do and can send them to you |
| 09:19 |
paxed |
Q: we've got Dewey-like classification numbers in 084a, and the numbers can contain a dot. there's apparently no way for me to search for exact value in that field? |
| 09:20 |
mrpeters |
hmmm...wasn't alpha g |
| 09:20 |
jeff |
mrpeters: what error are you encountering trying to insert those call numbers that you pasted? they don't seem to violate asset_call_number_label_once_per_lib, since they're all on different records. |
| 09:20 |
mrpeters |
ERROR: duplicate key value violates unique constraint "asset_call_number_label_once_per_lib" |
| 09:20 |
mrpeters |
DETAIL: Key (record, owning_lib, label, prefix, suffix)=(8356, 116, E BOURGEOIS, -1, -1) already exists. |
| 09:21 |
jeff |
i only see that once in the paste you pasted. |
| 09:21 |
Dyrcona |
I hadn't noticed, but they are on different records. |
| 09:22 |
Dyrcona |
That is still really sloppy, but what can you expect? |
| 09:22 |
senator |
paxed: there's a way |
| 09:22 |
jeff |
put another way, the data in your paste does not conflict with itself in a asset_call_number_label_once_per_lib sense, so it seems to be conflicting with data that is already present in the table. |
| 09:23 |
bshum |
Or it's something in the way the new data is being loaded. |
| 09:23 |
senator |
paxed: step 1: look in config.metabib_field and either modify the xpath field for the row where field_class = 'identifier' and name = 'bibcn' to include 084a, or make a new similar looking row just for 084a |
| 09:24 |
senator |
paxed: step 2: delete all rows from config.metabib_field_index_norm_map where field = <id of that field you just touched in step 1> |
| 09:25 |
senator |
paxed: step 3: reingest bibs or contrive to do a focused reingest specific to the identifier|bibcn field (or new field, if you chose to create a new row in step 1) |
| 09:25 |
senator |
that would do it |
| 09:25 |
paxed |
senator: thanks, i'll try that |
| 09:26 |
jeff |
You'd then need to perform your search from Advanced Search -> Numeric Search, selecting the identifier field that you modified/created. |
| 09:26 |
bshum |
The word "reingest" makes me feel queasy every time I see it now... :( |
| 09:26 |
jeff |
(iiuc) |
| 09:27 |
senator |
jeff++ right |
| 09:27 |
Dyrcona |
bshum: Like a cow, chewing cud.... |
| 09:27 |
jeff |
i was playing with a query that let me see (focused on a specific cmf) what records needed to be reingested... |
| 09:29 |
bshum |
"No I'm from Iowa, I only live in outer space." |
| 09:29 |
paxed |
i guess that would also let us search for exact match in 084a in the expert search? |
| 09:30 |
Dyrcona |
Gotta love it when a custom script uncovers a bug in Evergreen. |
| 09:30 |
jeff |
paxed: that probably wouldn't have any effect on how expert search on 084a works for you now. |
| 09:30 |
paxed |
jeff: hm. :/ |
| 09:31 |
bshum |
Expert search is special. |
| 09:33 |
paxed |
another question: afaics, setting OUS ui.patron.edit.au.*.show to false doesn't actually do what i thought it would do, that is, it still shows the field in patron reg. |
| 09:34 |
paxed |
at least when it comes to the prefix/title and suffix fields, haven't tested with others. |
| 09:37 |
bshum |
I thought there were different settings for registration vs. editing |
| 09:39 |
paxed |
i don't think so. |
| 09:40 |
paxed |
register.js has orgSettings['ui.patron.edit.' + fmcls + '.' + fmfield + '.show'] |
| 09:41 |
tsbere |
paxed: Note that the orgSettings are populated further up in the file, and other hardcoded entries may be able to override |
| 09:41 |
jeff |
yeah. other than setting required=show, it doesn't seem to do much. i'm not seeing where not setting it to show will hide it. |
| 09:42 |
jeff |
hardcoded required='required' in the tt template will override. |
| 09:42 |
jeff |
i might be missing a css trick that would hide when required isn't set. |
| 09:42 |
* jeff |
looks |
| 09:42 |
|
mllewellyn joined #evergreen |
| 09:43 |
paxed |
well, anyway, to my mind setting *.show to false means the field is not shown. perhaps this is a bug. |
| 09:43 |
jeff |
yeah, register.css doesn't contain the string "show". i'm thinking this is smelling like a bug. |
| 09:44 |
tsbere |
paxed/jeff: The org settings are one-way. "True" does stuff. "False" doesn't. require trumps show, which trumps suggest, and hardocded values count as a minimum for a number of reasons |
| 09:44 |
tsbere |
paxed/jeff: And no, it isn't a bug |
| 09:44 |
paxed |
illogical. |
| 09:44 |
bshum |
People have tried arguing that "false" should do something before. There's other bug tickets like that for other YAOUS to my recollection. |
| 09:44 |
bshum |
Patches welcome? |
| 09:44 |
jeff |
tsbere: what is the purpose of setting any of the "show" org settings, in that case? |
| 09:45 |
bshum |
"Showing a field makes it appear with required fields even when not required." |
| 09:45 |
bshum |
From the description |
| 09:45 |
tsbere |
jeff/paxed: "Required" in particular, on the hardcoded front, usually represents an actual DB level "not null" requirement. "show" is for non-required thing you want to show when in "required only" mode. Suggest is for the next level down. |
| 09:46 |
paxed |
so, if i actually want to _hide_ a field ... i can't do it via YAOUS |
| 09:46 |
jeff |
thus, "show" is stronger than suggest, but doesn't set the dijits to require a value. "show only required fields" will show the required and the "show" fields. |
| 09:46 |
tsbere |
yes |
| 09:46 |
|
akilsdonk_ joined #evergreen |
| 09:47 |
paxed |
at the very least, the *.show is misnamed. |
| 09:47 |
jeff |
paxed: you can do it with css, but be careful not to end up in a situation where you have invalid data in the hidden field which then prevents a save. |
| 09:48 |
tsbere |
jeff: We run into *that* alot because we hide the username field to avoid staff-fights over usernames. <_< |
| 09:48 |
paxed |
lovely. |
| 09:48 |
jeff |
*cringe* |
| 09:48 |
tsbere |
and now I have to go install a router |
| 09:48 |
jeff |
tsbere: enjoy! |
| 09:49 |
paxed |
i'd argue folding the *.show and *.require into one int-value setting instead of two bools, if the bools do not matter. |
| 09:50 |
jeff |
something like where 1 = show in 'required' and 2 = show in 'required' and really require a value? |
| 09:50 |
paxed |
*shrug* |
| 09:50 |
jeff |
sorry, where "in 'required'" means "in the 'show only required fields' view" |
| 09:51 |
paxed |
anything else but "false" == "nevermind, i don't matter, but i'm here just to confuse things" |
| 09:51 |
jeff |
yeah. |
| 09:52 |
|
ericar joined #evergreen |
| 09:54 |
paxed |
jeff: shall i file a bug, or will you do it? |
| 09:54 |
jeff |
paxed: go ahead. |
| 09:54 |
|
test621613 joined #evergreen |
| 09:57 |
jeff |
i'm not sure i like the idea of org setting values being magic ints or even bitmasks, but i think the current situation could be improved. |
| 09:58 |
jeff |
might be best to phrase the bug as wishlist wanting an org setting method for hiding fields. |
| 09:58 |
|
dddtest_efece joined #evergreen |
| 09:58 |
jeff |
i think it's a reasonable desire, and thought that's what the org settings were there for, until i looked at the code and tsbere clarified the intent. |
| 10:00 |
eeevil |
how about: show=true, display with required; show=false, do not show at all; show=null, default from template |
| 10:01 |
paxed |
that sounds like i would've expected it to work. |
| 10:01 |
jeff |
eeevil: yep. works for me. |
| 10:02 |
* Dyrcona |
grumbles something about cstore. |
| 10:02 |
jeff |
while i think it's safe to assume that the user object read from the database can be written back as-is, I think it would be worth adding logic to disable any dijit validation when show=false, to prevent the hidden-but-invalid-to-dojo situation. |
| 10:04 |
jeff |
Glancing at the current list of org settings that register.js pays attention to, I don't see any that would be hazardous to hide from a technical standpoint, though it might be silly to completely hide some, like active and barred. |
| 10:05 |
|
yboston joined #evergreen |
| 10:06 |
|
RoganH joined #evergreen |
| 10:06 |
eeevil |
ARG! UNCUDDLED BRACES! THE GOGGLES, THEY DO NOTHINK! |
| 10:07 |
paxed |
ok, bug 1246339 it is. |
| 10:07 |
pinesol_green |
Launchpad bug 1246339 in Evergreen "Add YAOUS for hiding Patron Reg fields" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1246339 |
| 10:08 |
jeff |
hah. paxed++ for adding the comments that i was about to copy-paste in. |
| 10:09 |
paxed |
well, i missed some |
| 10:12 |
|
dddtest_98daa joined #evergreen |
| 10:12 |
eeevil |
a followup thought on jeff's suggestion, IMO that should be a !important separate css rule that keeps certain fields from hiding. not completely fool proof, but at least they'll have to actively thwart the intent, and with a comment in the code we can even point a finger at them from the past! |
| 10:12 |
jeff |
heh |
| 10:13 |
* eeevil |
pastes that into the bug |
| 10:13 |
jeff |
i'm fine with a library deciding to hide active / barred if they so choose. it's a valid decision if they don't use those fields. |
| 10:14 |
jeff |
and the org settings are not free-form. i don't see any listed in register.js that are "things will break if you try to hide this" |
| 10:14 |
jeff |
(again, assuming we add logic that ensures that hidden fields don't have validation rules that are then impossible to correct issues with in the now-hidden field) |
| 10:15 |
jeff |
eeevil: or did i miss something in what you were thining in your !important css rule idea? |
| 10:15 |
paxed |
finns aren't hung up on titles or suffixes, like americans. (i guess titles/prefix madness is inherited from germans...) |
| 10:15 |
paxed |
no-one here goes around saying there's doctor so-and-so, or they're Foonen Jr. |
| 10:16 |
paxed |
nor are those used in print, really. |
| 10:16 |
Dyrcona |
Herr Doktor Dunkleschwarz! |
| 10:16 |
paxed |
this is what prompted the "can we hide those silly fields?" |
| 10:16 |
jeff |
paxed: yes. use css. ;-) |
| 10:17 |
eeevil |
jeff: I count it as very likely that the org setting retrieval will eventually be replaced with a loop over the list of fields on the various objects, instead of a hard list. at that point, we'll have to invent a "don't hide" mechanism, so my thought was to just do it now at the template level to have something in place for the future. |
| 10:17 |
paxed |
jeff: ehheh. there's these *.show settings that we set to "false", you know? :P |
| 10:18 |
jeff |
paxed: i know. :-) |
| 10:21 |
jeff |
eeevil: another option would be to not add coust entries for those fields, but i'll bet we'll run into a "we want to be able to set show=true on this field but it should never be hidden". |
| 10:21 |
jeff |
so i think i just talked myself out of that pretty quickly. |
| 10:22 |
eeevil |
jeff: right, also, folks can add YAOUS types by hand, and if its /not/ a hard list, the magic will start working on those fields |
| 10:23 |
Dyrcona |
Never mind that garbage. I just want cstore to stop crashing. |
| 10:23 |
csharp |
@hate reports |
| 10:23 |
pinesol_green |
csharp: But csharp already hates reports! |
| 10:23 |
csharp |
@hate reports more |
| 10:23 |
pinesol_green |
csharp: But csharp already hates reports more! |
| 10:23 |
csharp |
@hate reports even more |
| 10:23 |
pinesol_green |
csharp: The operation succeeded. csharp hates reports even more. |
| 10:23 |
paxed |
*snrk* |
| 10:24 |
jeff |
enumerating the fields into an array and sending that off for org setting retrieval... even if most fields don't have corresponding coust, that probably is an acceptable approach. |
| 10:24 |
eeevil |
Dyrcona: what's going on |
| 10:25 |
jeff |
csharp: joint talk proposal, "moving PINES reporting to JasperReports Server"... now we just need a more clever name... |
| 10:25 |
csharp |
ha! |
| 10:25 |
csharp |
"How jeff talked csharp off the ledge" |
| 10:31 |
|
ningalls joined #evergreen |
| 10:31 |
eeevil |
csharp: is there any update to be had on the reports friendly-ification from a couple years ago? |
| 10:32 |
csharp |
eeevil: still in committee atm, but the committee is narrowing in on a final req doc ;-) |
| 10:33 |
Dyrcona |
eeevil: I'm putting a paste together. |
| 10:33 |
eeevil |
csharp: cool. the plan is to have that live atop the existing framework? or to write a new SQL engine? (or put it on top of jasper? that'd be cool...) |
| 10:33 |
csharp |
eeevil: right now it's planning to live atop of the existing framework |
| 10:33 |
|
kbutler joined #evergreen |
| 10:34 |
jeff |
aiui, it's a frontend for runnning some common reports -- making the end-user "run the reports i usually run" easier/faster |
| 10:34 |
csharp |
jeff: exactly |
| 10:36 |
eeevil |
gotcha. thanks for the update, and I await the patches! |
| 10:36 |
dbs |
Hmm. Does anyone want me to talk about anything? I could do something like "Structured library data, part two: Evergreen is kicking butt and taking names" but not sure how broad that value is. |
| 10:36 |
* csharp |
would attend that |
| 10:37 |
eeevil |
dbs: I'd come to that, esp if there are examples in the wild of the structured data doing (facilitating) cool things |
| 10:37 |
paxed |
hmm.. is it just me, or are some of the facets in two lines now (the facet and the count on separate lines) - this seems to occur when there's a triple-digit number |
| 10:41 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "eeevil: Why does Evergreen hate me so?" (177 lines) at http://paste.evergreen-ils.org/32 |
| 10:41 |
dbs |
paxed: sounds right to me. total box is 15 em, inner box is 14em, left is 12em, that only leaves 2 em for the count |
| 10:41 |
dbs |
"right" as in "yes, sounds broken" |
| 10:42 |
RoganH |
dbs: I'd attend the structured data presentation. I enjoyed your last one. |
| 10:42 |
paxed |
dbs: why not put the count in a span and move it inside the div of the facet? |
| 10:45 |
dbs |
paxed: I dunno. Try it and submit a patch? |
| 10:46 |
dbs |
RoganH / eeevil / csharp -- thanks, that's reassuring :) |
| 10:48 |
dbs |
paxed: I think the long ago design goal was to try and keep the facet column at a fixed width with the count aligned at the top of each facet. |
| 10:48 |
dbs |
So if you can do that more robustly, while still allowing ultra-long facets to wrap and handling facet counts of 3, 4, or 5 digits, cool! |
| 10:48 |
eeevil |
Dyrcona: /somebody/ read the camel book all the way through ... yay for END blocks! ;) |
| 10:49 |
Dyrcona |
And __DATA__ blocks! |
| 10:49 |
jeff |
better than sigalrm handlers with no calls to alarm()... |
| 10:52 |
|
gordiev joined #evergreen |
| 10:53 |
jeff |
__DATA__ |
| 10:53 |
jeff |
@@ file1.txt |
| 10:53 |
jeff |
This is file1.txt |
| 10:53 |
jeff |
This is line two. |
| 10:53 |
jeff |
@@ file2.txt |
| 10:53 |
pinesol_green |
jeff: Zoia knows how to make fusilli. |
| 10:53 |
pinesol_green |
jeff: Mr. Spock: Something fascinating just happened. |
| 10:53 |
jeff |
this is file2! |
| 10:53 |
jeff |
abuse of __DATA__ or not, I'm torn. |
| 10:54 |
Dyrcona |
eeevil: One difference from yesterday, and I think this might be it, I am fleshing the record in the call number. I'll bet the failing function expects an id. |
| 10:56 |
jeff |
that's what the logs look like to me. i expect one of the methods called by one of your methods needs to be taught to detect a fleshed object and essentially unflesh. |
| 10:56 |
Dyrcona |
Yeah. that must be it BibCommon::title_is_empty. |
| 10:57 |
jeff |
i was trying to figure out where you were passing a record as an id, but you aren't... your fleshing is resulting in something else doing it. :-) |
| 10:57 |
Dyrcona |
I call AssetComm::delete_copy to get the AssetCommon::remove_empty_objects. |
| 10:57 |
eeevil |
Dyrcona: so ... yep |
| 10:57 |
Dyrcona |
The latter calls BibCommon::title_is_empty. |
| 10:57 |
jeff |
also, is that grabbing all undeleted copies at a circ lib, with fleshed records? |
| 10:58 |
Dyrcona |
Yes, sir, it is, and it streams results! |
| 10:58 |
Dyrcona |
only about 12,400 of them. |
| 10:58 |
Dyrcona |
They only have about 12,400 undeleted copies. |
| 10:59 |
Dyrcona |
So, it looks like BibCommon::title_is_empty is the logical place to put the check for an object. |
| 10:59 |
eeevil |
Dyrcona: grab the bib off the volume if you need the bre object and then $vol->record($record->id) it |
| 11:00 |
Dyrcona |
eeevil: I think the better fix is to modify title_is_empty to prevent someone else getting bit with the same situation. |
| 11:00 |
Dyrcona |
I really only need to flesh bre to get rmsr in the same go. |
| 11:00 |
jeff |
win 11 |
| 11:01 |
jeff |
grr |
| 11:05 |
Dyrcona |
$rid = $rid->id() if (ref($rid)); #easy peasy... |
| 11:08 |
Dyrcona |
"They're off and running at Rockingham!" |
| 11:11 |
* tsbere |
finds it very difficult to install and test a router when the internet connection it is supposed to connect to isn't there |
| 11:11 |
|
mceraso joined #evergreen |
| 11:16 |
csharp |
could someone test something for me? log into the staff client, search the catalog, click on a record to bring up details, then hover on Add to My List and select an existing list |
| 11:17 |
csharp |
for me that creates an internal server error and a log message very similar to that reported in bug |
| 11:17 |
csharp |
bug 1060953 |
| 11:17 |
pinesol_green |
Launchpad bug 1060953 in Evergreen 2.3 "Internal Server Errors with "large" bookbags in TPAC" (affected: 2, heat: 14) [High,Fix released] https://launchpad.net/bugs/1060953 |
| 11:17 |
* bshum |
is happily showing how to IRC for mceraso (his new coworker) |
| 11:17 |
csharp |
mceraso: welcome! |
| 11:17 |
Dyrcona |
mceraso: Howdy! |
| 11:18 |
mrpeters |
welcome, mceraso |
| 11:21 |
RoganH |
mceraso: welcome to the den of iniquity |
| 11:21 |
jeff |
eeevil++ |
| 11:21 |
jeff |
mceraso: greetings! |
| 11:25 |
mceraso |
Hi everyone! Glad to be here and hoping to learn as much as I can! |
| 11:27 |
|
akilsdonk joined #evergreen |
| 11:28 |
dbs |
mceraso++ |
| 11:44 |
bshum |
csharp: That error sounds familiar actually. It's some weird redirect problem |
| 11:44 |
bshum |
But I can't replicate it at the moment. |
| 11:45 |
bshum |
Oh, record details, bleh |
| 11:45 |
bshum |
Yeah I see it. |
| 11:45 |
csharp |
woohoo! |
| 11:45 |
csharp |
reproducible_errors++ |
| 11:48 |
|
smyers_ joined #evergreen |
| 11:49 |
bshum |
csharp: http://pastie.org/8443017 is the apache error I get in my logs |
| 11:49 |
bshum |
From performing that action to try adding straight to my list from record details in the client |
| 11:49 |
csharp |
yep - that's it |
| 11:50 |
csharp |
bshum++ |
| 11:50 |
bshum |
csharp: If you want to file a bug, I'll +1 it |
| 11:50 |
bshum |
Err, "me too" for it |
| 11:51 |
csharp |
btw, I see senator 's question on bug 1052941: https://bugs.launchpad.net/evergreen/+bug/1052941/comments/4 - tmccanna and I have the same question |
| 11:51 |
pinesol_green |
Launchpad bug 1052941 in Evergreen 2.3 "The new Add to My List menu options don't work in TPAC in the Staff Client" (affected: 2, heat: 10) [Medium,Fix released] |
| 11:52 |
Dyrcona |
In my defense, the new My List menus were never really meant to work in the staff client. |
| 11:52 |
dbs |
Could just hide them in staff client mode |
| 11:52 |
bshum |
Eh, and the question does get replied to in further comments along with "open a new ticket if we desire it to behave differently" |
| 11:53 |
csharp |
Dyrcona: yeah - a cataloger reported the issue - it hadn't occurred to us that staff would be using them from within the client either |
| 11:53 |
dbs |
Two lines of TT2 |
| 11:53 |
csharp |
I have a feeling that we'd get mobbed by catalogers if we disabled it |
| 11:53 |
dbs |
Consider it a first step towards a web-based staff client. "Just log into a browser and munge your bookbags" |
| 11:54 |
csharp |
bshum: yeah - I was considering opening a bug on it |
| 11:54 |
dbs |
"We have disabled this functionality while we work on a fix for it." |
| 11:54 |
dbs |
... 7 years later ... |
| 11:54 |
csharp |
exactly ;-) |
| 11:54 |
dbs |
Seriously though, better to hide it rather than have it dangling there broken. |
| 11:55 |
Dyrcona |
Heh... I forgot to "unredacted" the credentials in the script I pasted earlier before saving it. |
| 11:55 |
bshum |
Oh what, I totally do not remember this "Locate Z39.50 matches" option in bookbags |
| 11:59 |
csharp |
bug 1246385 created - feel free to add your comments about disabling it |
| 11:59 |
pinesol_green |
Launchpad bug 1246385 in Evergreen "internal server error when adding an item to a list from within staff client" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1246385 |
| 11:59 |
* Dyrcona |
gives Z39.{whatever} the hairy eyeball. |
| 12:09 |
bshum |
csharp: For note, that bug only happens for me if it's from the record details |
| 12:09 |
bshum |
From results, it works the way the past bug fix handles |
| 12:09 |
bshum |
So I guess it's an incomplete bug fix in that it didn't fix both result and record |
| 12:10 |
|
netden joined #evergreen |
| 12:10 |
|
kbeswick joined #evergreen |
| 12:11 |
bshum |
Err wait, I'm confused by all these bug numbers |
| 12:11 |
bshum |
Nevermind me |
| 12:25 |
|
dMiller_ joined #evergreen |
| 12:45 |
|
dMiller__ joined #evergreen |
| 12:49 |
|
jammin joined #evergreen |
| 12:58 |
|
stevenyvr2 joined #evergreen |
| 13:01 |
|
smyers__ joined #evergreen |
| 13:15 |
|
RobertL_ joined #evergreen |
| 13:16 |
RobertL_ |
Hi. Anyone knows Evergreen supports Xpath 2.0? |
| 13:27 |
|
gsams joined #evergreen |
| 13:30 |
tsbere |
RobertL_: Where are you dealing with Xpath? |
| 13:32 |
RobertL_ |
for the metabib fields in MARC Search/Facet Fields window |
| 13:33 |
|
akilsdonk_ joined #evergreen |
| 13:34 |
RobertL_ |
well, actually, ignore me. I don't think 2.0 would have helped me neither |
| 13:35 |
Dyrcona |
For the logs: Evergreen itself doesn't support a particular version of XPath, since it doesn't implement an XPath evaluator. |
| 13:35 |
jeff |
To the best of my knowledge, the postgresql xml functions dealing with xpath are xpath 1.0. |
| 13:36 |
Dyrcona |
The version of XPath supported would depend on what is supported by PostgreSQL (jeff beat me to it) as well as the version of libxml you are using. |
| 13:36 |
Dyrcona |
And possibly other XML libraries used by Evergreen. |
| 13:37 |
eeevil |
we use libxml (and friends) as the baseline. that's xpath 1.0 |
| 13:37 |
eeevil |
we use xml::simple to parse opensrf.xml, but that's really immaterial to your purposes |
| 13:37 |
RobertL_ |
good to know for future reference. Thanks |
| 13:47 |
|
hbrennan joined #evergreen |
| 13:48 |
|
mjingle joined #evergreen |
| 14:06 |
|
frank_____ joined #evergreen |
| 14:07 |
frank_____ |
hi all, I continue having problems with the place hold option in EG 2.4.2, I can´t get the pull list yet |
| 14:11 |
|
kmlussier joined #evergreen |
| 14:15 |
|
mrpeters joined #evergreen |
| 14:19 |
|
gerson joined #evergreen |
| 14:32 |
jammin |
Howdy, we're looking to implement online payments via the OPAC, but am wallowing through PCI DSS matters as we wish to retain our current certification. |
| 14:33 |
jammin |
Looking for some details on the underpinnings of how those payments are handled currently, to determine what that means for us in that regard. |
| 14:33 |
hbrennan |
Wish I could help with that. We're just not there yet |
| 14:34 |
jammin |
I'm also aware of current development for adding Stripe as an option. |
| 14:37 |
jammin |
I think that Evergreen does not store card data from those transactions (whether in DB or in logs), but would like to confirm that. |
| 14:38 |
jammin |
I don't know whether Evergreen processes or transmits that data or not (I'm using terms right from the standards there), and need to confirm either way on that. |
| 14:39 |
|
akilsdonk joined #evergreen |
| 14:40 |
jammin |
It looks like it probably does... I can see parts of payment form being rendered, and the presence of some perl modules that are likely involved (business::onlinepayment::paypal/authorize.net for example). |
| 14:41 |
jammin |
But looking at paypay & authorize.net there are versions of their services where the forms live on their servers, and the processing/transmitting happens within their environment, not ours. |
| 14:43 |
jammin |
The exact methods being used are hugely different in terms of PCI DSS... so I need to confirm exactly what is happening there. |
| 14:48 |
jammin |
Here's the bit in lauchpad concerning Stripe: https://bugs.launchpad.net/evergreen/+bug/1227871 |
| 14:48 |
pinesol_green |
Launchpad bug 1227871 in Evergreen "Support credit card payments through Stripe, nicely avoiding PCI concerns" (affected: 2, heat: 14) [Undecided,New] |
| 14:50 |
jeff |
jammin: when using a processor such as Authorize.net, current Evergreen is handling the cardholder data, and thus your PCI DSS burden is higher than it would be if you were using the upcoming Stripe support. |
| 14:51 |
jammin |
jeff: thank you! that's exactly what I needed to know on that part. |
| 14:52 |
jeff |
jammin: all of this needs a disclaimer of i am not a PCI DSS auditor :-) |
| 14:52 |
jammin |
jeff: anything on storage in DB or logs? I came across an IRC log from long long ago that mentioned they were in logs at that point, but looked like steps being taken to use dummy numbers or simply not log them instead. |
| 14:52 |
jeff |
jammin: with Authorize.net, there's the SIM method where they host the payment form, and there's the AIM method where you post the cardholder data to them. Evergreen uses AIM. |
| 14:52 |
jammin |
jeff: of course, understood. :) |
| 14:53 |
jeff |
We have a set of scripts that we use to process payments with SIM (dating to before Evergreen had credit card support) |
| 14:54 |
jeff |
Others have used similar -- I think HMMPL had some php scripts against Authorize.net, but I don't recall if they used SIM or AIM. |
| 14:55 |
jammin |
jeff: got it on AIM vs SIM, it did look like probably AIM (if using that perl module, the docs for that said AIM). I did read what you were saying about SIM at the time, wasn't sure if some form of that ended up in Evergreen or not. |
| 14:56 |
jeff |
I have not personally audited for the presence of cardholder data in logs/db, but if you find issues, please open a security bug (being sure to check the correct option for 'this is a security bug') at http://bugs.launchpad.net/evergreen -- |
| 14:56 |
jammin |
jeff: absolutely |
| 14:59 |
jammin |
jeff: it looks like paypal has an equivalent to AIM called payflow link. they also have something in payflow pro called "transparent redirect", intended to ease PCI DSS demands: https://www.paypalobjects.com/webstatic/en_US/developer/docs/pdf/paypal_transparent_redirect.pdf |
| 15:01 |
jeff |
With regard to adding support for either Authorize.net or PayPal's hosted forms, there is not currently support in Evergreen itself, but patches are always welcome. :-) |
| 15:01 |
jammin |
jeff: it is specifically mean to address this issue, I have no idea if the current implementation makes use of it or not. |
| 15:02 |
jammin |
jeff: Ha... I can cook up some Perl, but touching anything important is a scary proposition. :) |
| 15:03 |
jeff |
Sorry, I didn't follow your last message -- I was trying to state that support for neither of the two "someone else hosts the payment form" options is built into Evergreen currently. |
| 15:03 |
jeff |
(er, the message before last now) |
| 15:04 |
jammin |
Yep, got that. |
| 15:08 |
jammin |
Basically the paypal payflow pro "transparent redirect" looks like a method where the merchant server (our Evergreen) generates the form for the customer's (patron's) browser, but the form posts directly to paypal, and their data never touches our server. Sounds a little bit like Stripe from what I can tell, actually. |
| 15:09 |
jboyer-isl |
jammin: I've spent some time looking at the CC options, and currently only the last 4 of the card number are stored in the database (though that can be changed by adding a trigger to always null it out, etc.) |
| 15:09 |
jboyer-isl |
As you mentioned, I don't believe they hit the logs anymore. |
| 15:12 |
jboyer-isl |
Having worked with the stripe code (but not having time to test it properly, or sign off on it. :,( ) I'd say that's definitely a great option, once it's in. |
| 15:13 |
csharp |
okay - I'm having a srfsh syntax problem - and I know a lot of it is that I never use JSON for anything so I don't know the syntax... I'm trying 'request open-ils.actor open-ils.actor.user.transaction.fleshed.retrieve.authoritative {"authtoken", "xact_id"}' |
| 15:13 |
csharp |
the error is "Expected colon after hash key; didn't find it" |
| 15:13 |
jboyer-isl |
Also, as for the "transparent redirect" form, Stripe doesn't exactly work that way. The sensitive data is transfered by a javascript file downloaded from Stripe, then a token is inserted into your form, and the non-sensitive data is posted to Evergreen to actually do the billing. |
| 15:13 |
csharp |
I pulled this command from the logs |
| 15:14 |
jammin |
jboyer-isl: thanks, that helps too. although even if the stored number is only last 4, that is something I'll have to consider. |
| 15:14 |
Dyrcona |
csharp: I don't think you want the braces in srfsh. |
| 15:14 |
jboyer-isl |
csharp: you probably want "authoken" {"xact_id": ID} |
| 15:15 |
Dyrcona |
where "authtoken" is the token you get back from logging in |
| 15:15 |
jammin |
jboyer-isl: having the option to go completely null with it would be a good thing |
| 15:16 |
Dyrcona |
csharp: if that doesn't work, try "authtoken, ID" no quotes. |
| 15:16 |
jammin |
jboyer-isl: not writing it to db at all, unless there is some compelling reason for it |
| 15:17 |
Dyrcona |
retrieves usually don't need json objects, but I usually do this sort of thing from Perl. |
| 15:17 |
dbwells |
csharp: for that API, no JSON necessary, I think, just two args: request open-ils.actor open-ils.actor.user.transaction.fleshed.retrieve.authoritative "AUTH_TOKEN_HERE", "XACT_ID_HERE" |
| 15:17 |
jboyer-isl |
That's certainly my preference. (CC type may be useful for disputes at the desk, but certainly not numbers) |
| 15:18 |
csharp |
dbwells: Dyrcona: that was it - thanks |
| 15:18 |
dbwells |
csharp: well, the two args are technically JSON, but just strings :) |
| 15:19 |
jboyer-isl |
csharp: oops. Listen to Dyrcona and dbwells. But for reference, if you're writing JSON, it's { "field": "value", "field2": "value2"} That's why it was whining about a colon. |
| 15:20 |
jammin |
jboyer-isl: in the course of this I've had to become familiar with PCS DSS requirements in general... even SAQ C (required if our server is touched) is quite an onerous bit of security theater. good practices mixed in with a bit of "wow, really?" |
| 15:22 |
jeff |
jammin: that meshes with my experience. |
| 15:22 |
jboyer-isl |
jammin: Yeah, just hitting level 4 at my last job for one of those swipe terminals was obnoxious. That's as much as I hope to ever have to mess with it. |
| 15:22 |
jammin |
jboyer-isl: SAQ D (required if any data at all is stored) I don't even wanna think about |
| 15:23 |
jboyer-isl |
"The entrance to the secure enclave requires a mission impossible style tightrope ride. Also, 2 keys." |
| 15:23 |
jammin |
jboyer-isl: lol |
| 15:23 |
Dyrcona |
One of which is hidden under the doormat. ;) |
| 15:24 |
Dyrcona |
The other is in a bus station locker in Cleveland, OH. |
| 15:24 |
jboyer-isl |
:D |
| 15:26 |
jammin |
jboyer-isl: two keys kept in separate secure enclaves each in turn requiring two keys, one of which will be retained by your auditor, and made available on demand for a "reasonable fee". |
| 15:29 |
jammin |
Dyrcona: The exact bus station locker location shall be kept in the bottom of a locked filing cabinet in a disused lavatory, in an unlit, stairless cellar. Guarded by leopards. |
| 15:29 |
dbwells |
grabbing 0846 |
| 15:29 |
Dyrcona |
jammin: With a sign on the door saying "KEEP OUT" :) |
| 15:30 |
jammin |
Dyrcona: Aye. :) |
| 15:31 |
|
smyers_ joined #evergreen |
| 15:32 |
jammin |
Seriously ya'll, thanks... I think I know most of what I need to know to answer everybody else's questions now. Holding out a little hope of discovering the paypal method does make use of the transparent redirect thing... but not exactly optimistic about it. |
| 15:34 |
jammin |
Tried hunting for it by starting with the forms and following how they post & any code called, but my template toolkit fu is weak. |
| 15:35 |
jboyer-isl |
jammin: As far as I'm aware, all of the current built-in OPAC CC options require the full number be passed from the Evergreen server to the processors. |
| 15:36 |
jammin |
jboyer-isl: cool, thanks. ultimately using business::onlinepayment::paypal or business::onlinepayment::authorize.net I presume? |
| 15:37 |
csharp |
I have pulled out JSON objects with the query I was using above - returns copy, record, circ, and transaction objects - I'm interested in matching those up via the fieldmapper in a table or spreadsheet - does anybody have tools to do something like that? |
| 15:37 |
jammin |
jboyer-isl: Not only that, but the last four digits of the cc number are saved to DB. Yikes. |
| 15:37 |
pinesol_green |
[evergreen|Mike Rylander] Respect source XML subfield order during overlay - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7c4f575> |
| 15:37 |
pinesol_green |
[evergreen|Dan Wells] Stamping 0846: overlay subfield order fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ab68544> |
| 15:38 |
csharp |
(this is all because there are too many transactions to retrieve in the UI and the patron wants proof of why they owe so much) |
| 15:38 |
jboyer-isl |
jammin: Well, I think the last 4 are considered less sensitive by the requirements, but I'm not certain about that. |
| 15:38 |
jeff |
csharp: i'd recommend using sql, not srfsh. others may have better advice. |
| 15:38 |
jeff |
csharp: or at least different advice. :-) |
| 15:39 |
csharp |
that's probably better anyway |
| 15:39 |
jeff |
csharp: how many transactions are you dealing with that the UI is not an option? |
| 15:39 |
csharp |
106 |
| 15:39 |
csharp |
apparently that's a breaking point for us |
| 15:39 |
Dyrcona |
The UI has a very low threshold for pain. |
| 15:39 |
jeff |
drat. |
| 15:39 |
csharp |
well, on windows ~75 |
| 15:39 |
jammin |
jboyer-isl: They are, but the fact that anything at all is stored completely moves one from any other category all the way to requiring the full SAQ D enchilada. |
| 15:39 |
csharp |
I'll try SQL |
| 15:40 |
jammin |
jboyer-isl: I think. I just read a lot of this for the first time this week. :) |
| 15:40 |
csharp |
I just have a hard time pulling the tables back together in meaningful ways, though the JSON objects provide clues ;-) |
| 15:40 |
Dyrcona |
SQL would work. I'd maybe use Perl and fleshed cstore queries. |
| 15:41 |
jboyer-isl |
jammin: I didn't think it was that bad, but I've not had to deal with this for about a year+, so I wouldn't trust my memory. |
| 15:46 |
jammin |
jboyer-isl: sure looks like it to me. every chart & document says "No electronic storage of Card Holder Data" for anything but SAQ D. They don't differentiate between sensitive vs nonsensitive portions of the data in any other context other than "yes, storing card holder data". |
| 15:48 |
jammin |
jboyer-isl: under SAQ D is where they get into what parts to store or not, which parts are considered sensitive (requiring complete hashing or non-storage, etc) or not. |
| 15:56 |
jboyer-isl |
jammin: Oh. That's no good then. Best to take their money and forget you ever saw them, heh. :D |
| 15:59 |
jeff |
csharp: for starters, try reporting on money.materialized_billable_xact_summary joined with money.billable_xact and (for circ billings) asset.copy and asset.call_number and reporter.materialized_simple_record. |
| 16:00 |
jeff |
or, mmbxs, mbx, acp, acn, and rmsr. :-) |
| 16:01 |
jeff |
s/mbx/mbt/ actually |
| 16:01 |
jeff |
...because it's also money.billable_transaction |
| 16:01 |
jeff |
so close. |
| 16:03 |
mrpeters |
my memory is hazy, but isn't there some magic spell for refreshing opac visibility of newly created items? i've got a few in an available status with opac_visible true, good call number to item linkage, visible copy_location, but no results in TPAC |
| 16:03 |
paxed |
grouped patrons do not show up in OPAC in any way, correct? |
| 16:03 |
bshum |
There is... something I think |
| 16:04 |
mrpeters |
bshum: i think so too, i just can't find it |
| 16:04 |
bshum |
paxed: Not with TPAC, I think. |
| 16:04 |
mrpeters |
refresh copy visiblity function or something keeps ringing in my head, but |
| 16:07 |
dbs |
mrpeters: asset.refresh_opac_visible_copies_mat_view |
| 16:07 |
dbs |
thanks to the power of psql "\df asset.<tab><tab>" |
| 16:08 |
mrpeters |
awesome, thank you |
| 16:09 |
csharp |
jeff: thanks |
| 16:12 |
|
mjingle joined #evergreen |
| 16:15 |
bshum |
yboston: You remember how we talked once about adding back some of the newbie steps for the READMEs to make it somewhat easier for new folk to install OpenSRF/Evergreen? |
| 16:15 |
bshum |
I'm really thinking that's a good idea. Now that I'm re-teaching someone else how to do it. |
| 16:16 |
bshum |
Might be something I tinker with more in the coming weeks. |
| 16:18 |
paxed |
perhaps a shell script to automate the install - that seems to be one of the first things any eg dev does, create their own install script. |
| 16:20 |
|
mrpeters left #evergreen |
| 16:21 |
dbs |
Or of course the Koha way: "apt-get install koha-common". There's a lot to be said for that. |
| 16:21 |
* dbs |
has never created his own install script, fwiw. |
| 16:21 |
csharp |
you can always try our debs at http://archive.georgialibraries.org |
| 16:22 |
dbs |
csharp++ |
| 16:22 |
Dyrcona |
csharp++ |
| 16:23 |
bshum |
Well, easy sure. But that's not the point of teaching the process. |
| 16:23 |
bshum |
Well, not in this case. |
| 16:23 |
eeevil |
dbwells: your replace-subfield troubles surely stem from the fact that we don't really replace, we remove+add ... I know the trouble all too well. my kingdom for a tuit! |
| 16:23 |
dbs |
bshum: man, you sound like a librarian now. "No, we have to _teach_ them how to use the search interface!" |
| 16:23 |
csharp |
bshum: agreed |
| 16:23 |
Dyrcona |
Though I prefer Debian distros lately, I have edited a RPM description file/script in the past. |
| 16:24 |
* dbs |
has created and maintains some RPM packages for Fedora, just too many dependencies left to package to finish off the job for Evergreen. |
| 16:24 |
Dyrcona |
I could look into adding a deb-pkg target in the Makefiles. |
| 16:25 |
Dyrcona |
Someone pass the bag of tuits! ;) |
| 16:25 |
bshum |
dbs: Hehe |
| 16:25 |
Dyrcona |
eeevil obviously doesn't have it, so who has hidden it? |
| 16:25 |
bshum |
dbs++ |
| 16:26 |
dbwells |
eeevil: yes, that is certainly half of it, but there seems to be something else. When I replace *all* the subfields, it just dies and says "Field XXX must have indicators (use ' ' for empty indicators)..." (where XXX is the real field number). |
| 16:26 |
csharp |
hmm - getting "osrf_settings_host_value: NULL config pointer; looking for config_context "/IDL"" when running the offline-blocked-list.pl script |
| 16:26 |
csharp |
I assume there's an opensrf change that accounts for that issue, since the perl script hasn't been altered in a couple of years |
| 16:27 |
Dyrcona |
csharp: My first thought would be to make sure that you're configured properly. |
| 16:27 |
Dyrcona |
And, you used opensrf_core.xml for the bootstrap? |
| 16:27 |
dbwells |
eeevil: I had an older version of MARC::File::XML installed, so I was getting errors in the old SAX.pm, but I just updated to latest, and still get errors, now in XML.pm. Just trying to determine now if the error is in our code, or in MARC::File::XML. |
| 16:27 |
csharp |
yessir |
| 16:28 |
eeevil |
dbwells: not a situation where you can replace the whole field? (no subfild list in the rule, I mean) |
| 16:28 |
bshum |
csharp: Hmm, my offline-blocked-list.pl works fine... |
| 16:28 |
bshum |
csharp: What version of opensrf are you testing with? |
| 16:28 |
* Dyrcona |
used the wrong file the other day and got a message, but forgot what it was exactly. |
| 16:28 |
* dbs |
hopes someone will test out bug #1242999 given the effort he put into rudimentary pgTAP tests |
| 16:28 |
pinesol_green |
Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 6) [High,Confirmed] https://launchpad.net/bugs/1242999 |
| 16:28 |
csharp |
may be a genasys bug |
| 16:29 |
dbs |
Given that the community has invested in the QA effort, we should really consider requiring pgTAP tests for db-changing bugs |
| 16:30 |
bshum |
csharp: Oh, that I couldn't comment on :) |
| 16:30 |
csharp |
bshum: yeah - it's okay - if I can rule out genasys, I'll be back ;-) |
| 16:30 |
csharp |
thanks for confirming |
| 16:30 |
bshum |
csharp: Well, fwiw, I'm running on OpenSRF master and the command to run offline block list is still going without issues |
| 16:31 |
bshum |
Just finished, no errors. |
| 16:31 |
Dyrcona |
This reminds me that I had an idea for a branch to make --localhost unnecessary with osrf_control. |
| 16:31 |
dbwells |
eeevil: I was obviously just turning knobs, so to speak, and seeing what happened. I make no promises for the realistic-ness of my tests :) That said, there are certainly cases where you might want to replace one or two subfields, but you can't necessarily predict whether those will be the *only* subfields. |
| 16:34 |
eeevil |
dbwells: gotcha. worth an lp bug, then, certainly |
| 16:37 |
csharp |
duh - it helps if opensrf is running |
| 16:38 |
csharp |
okay - I'll take that as a sign that I need to quit for the day :-) |
| 16:39 |
bshum |
Heh |
| 16:40 |
bshum |
mmorgan: Interesting tidbit with https://bugs.launchpad.net/evergreen/+bug/1185985/comments/4 |
| 16:40 |
pinesol_green |
Launchpad bug 1185985 in Evergreen 2.4 "Error in bill2.js, tally_all(); TypeErrorL bill.transaction is undefined" (affected: 5, heat: 24) [Medium,Confirmed] |
| 16:40 |
bshum |
mmorgan++ |
| 16:40 |
bshum |
Now I wish we had an org unit for staff to use |
| 16:41 |
Dyrcona |
bshum: You don't have an org unti for central site? |
| 16:41 |
mmorgan |
Noticed that just by chance - playing with the ou settings for our central site "library" (a handy thing to have) |
| 16:41 |
Dyrcona |
unit, even. |
| 16:43 |
|
dMiller_ joined #evergreen |
| 16:44 |
bshum |
Dyrcona: Nah, we never got around to adding one. |
| 16:46 |
bshum |
Maybe I'll do that tonight |
| 16:46 |
bshum |
And add stuff like marking us invisible and not a pickup lib |
| 16:50 |
hbrennan |
csharp++ (for helping me with an off topic mailing list problem) |
| 16:51 |
csharp |
happy to help! |
| 16:51 |
jammin |
Thanks again everybody, have to bail for a meeting... |
| 16:52 |
|
jammin left #evergreen |
| 16:56 |
Dyrcona |
bshum: We've always had one, even on Horizon. |
| 16:56 |
bshum |
Dyrcona: I think we used to have one in Horizon too. We just didn't carry it over with us to Evergreen. |
| 17:02 |
|
kbeswick_ joined #evergreen |
| 17:15 |
|
dddtest_6b2b5 joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 18:03 |
frank_____ |
Hi, Is there a place where I could update the default mfhd marc template? |
| 18:46 |
|
Dyrcona joined #evergreen |
| 18:46 |
Dyrcona |
I don't expect anyone to answer, but here goes.... |
| 18:47 |
Dyrcona |
I'm curious if anyone actually uses the money.* views in example.reporter-extension.sql. |
| 18:48 |
Dyrcona |
Also, if I'd made changes to money.billing that affect those views, should I update the definitions in example.reporter-extension.sql. |
| 18:48 |
Dyrcona |
Finally, there are f |
| 18:48 |
Dyrcona |
fm_IDL.xml entries that reference these views. |
| 18:52 |
Dyrcona |
I guess the real trick would be to create or replace them only if they exist. |
| 19:02 |
csharp |
Dyrcona: yes, we use them, but that's probably not a surprise ;-) |
| 19:03 |
csharp |
any updates you make to accommodate them to your changes would be greatly appreciated! |
| 19:16 |
Dyrcona |
csharp: OK. I'll update them only if they exist. |
| 19:17 |
Dyrcona |
It looks like the main ones are going to lose the check for not bill.voided because voided is going away and being replaced by a new payment type. |
| 19:35 |
Dyrcona |
Fortunately, anyone running this upgrade script will already be on PostgreSQL 9.0+, so a DO$$ ... END$$ block works nicely. |
| 19:36 |
Dyrcona |
csharp++ # for being on IRC and confirming my suspicions |
| 19:37 |
|
jeff_ joined #evergreen |
| 19:58 |
hbrennan |
I'm assisting someone setting up a weeding helper report, and would like to show Current Year Circs, Previous Year Circs, along with title info. Haven't figured out a way to get anything except for Total Circs. |
| 19:59 |
|
jeff___ joined #evergreen |
| 19:59 |
hbrennan |
Does anyone run a report like that? |
| 20:01 |
hbrennan |
I need to start thinking of my questions earlier in the day.... |
| 20:11 |
gsams |
hbrennan: I' |
| 20:11 |
hbrennan |
You've got my attention :) |
| 20:11 |
gsams |
hbrennan: I've only ever been able to get that sort of information through separate reports |
| 20:12 |
gsams |
Let me see if I can get the last report I've used for that sort of info |
| 20:12 |
hbrennan |
You mean one report for current year circs, and another report for previous year circs? |
| 20:12 |
gsams |
yes |
| 20:12 |
hbrennan |
ahh, well that would be better than where we're at |
| 20:12 |
hbrennan |
I didn't get trained on Reports so I don't use the module, but the person making the report says he can't find anything except totals |
| 20:13 |
gsams |
I rarely get the chance to help out on this channel, but when I see something I can help with I jump at it. I've been running a lot of reports lately |
| 20:13 |
hbrennan |
Same here! |
| 20:13 |
gsams |
It takes some creative engineering of sorts |
| 20:13 |
hbrennan |
I have been asked to help with a lot of reports lately |
| 20:13 |
hbrennan |
we're 6+ months on Evergreen now and the time as come to figure them out |
| 20:14 |
gsams |
It's a complex reporting system, but it is very dynamic because of that. |
| 20:15 |
gsams |
You want Circ ID under Circulation |
| 20:15 |
gsams |
You'll get the options of Count, Count Distinct, and Raw Data with that |
| 20:15 |
gsams |
I've used Count Distinct |
| 20:15 |
|
jeff___ joined #evergreen |
| 20:16 |
|
jeff___ joined #evergreen |
| 20:16 |
gsams |
The next thing is to set a filter for time |
| 20:16 |
gsams |
We've been using Check Out Date/Time as a date with the between operator |
| 20:17 |
gsams |
this allows you to specify the time period you want to get circulations for |
| 20:17 |
hbrennan |
And then just run that twice with different dates |
| 20:17 |
gsams |
bingo! |
| 20:17 |
hbrennan |
Sweet! |
| 20:17 |
hbrennan |
Thanks |
| 20:17 |
gsams |
no problem, I'm happy to help |
| 20:18 |
hbrennan |
gsams++ for helping, and for being here while the world series is happening :) |
| 20:18 |
gmcharlt |
heh |
| 20:18 |
hbrennan |
Two more hours of work up here in Alaska |
| 20:18 |
gsams |
I'm her for about 2 more hours myself, down in Texas |
| 20:18 |
hbrennan |
Ah good. I'm not alone |
| 20:19 |
gsams |
Let me know if you have any other issues with that, I'm currently creating reports like a mad man down here. |
| 20:20 |
hbrennan |
I'll be sure to get it tested soon and I'll get back to you to take advantage of that report brain if I need to |
| 20:28 |
bshum |
hbrennan: I'm pondering your question to the general list about getting some sort of hold report filtered to copy locations and I don't think this would be possible with the staff client reporting. |
| 20:28 |
bshum |
hbrennan: My thinking is that most holds generally target bib records (title holds), so there isn't an exact and tight match to any given copy. At least not 100% of the time. |
| 20:29 |
hbrennan |
We usually only have one copy of something so it doesn't really matter |
| 20:30 |
bshum |
In SQL, I figured it'd be easy to write a query that said something like, count holds targeting bibs that have items in X copy location. |
| 20:30 |
hbrennan |
I actually found a doc you wrote bshum |
| 20:30 |
hbrennan |
I just need to learn SQL |
| 20:30 |
bshum |
Oh those are the scariest kinds |
| 20:31 |
hbrennan |
right after I get CCNA certified... |
| 20:31 |
hbrennan |
It looks useful! |
| 20:31 |
hbrennan |
I just need to find an extra few dozen hours a week for studying |
| 20:32 |
gsams |
heh, I'm currently studying for CIW database design specialist cert for school right now, I understand trying to find a few dozen extra hours |
| 20:32 |
gsams |
I'm basically up against the wall for testing at this point |
| 20:34 |
bshum |
hbrennan: http://pastie.org/8444266 for fun |
| 20:35 |
bshum |
I just wrote that from memory, so I haven't actually tested it to see how it would fare... might need additional tweaking |
| 20:35 |
hbrennan |
I am a psychology major, now diving into It |
| 20:36 |
hbrennan |
I'm 400 pages into Part 1 of the CCNA book |
| 20:36 |
hbrennan |
Thanks bshum++ |
| 20:36 |
hbrennan |
SQL seems to me very much like HTML |
| 20:37 |
hbrennan |
it looks insane when you first look at it, but if you know even a little bit the mystery is gone |
| 20:38 |
bshum |
I'm already thinking of caveats, like maybe only looking for active holds (not suspended ones) |
| 20:39 |
bshum |
In our consortium, I think we just let people place their own holds on acquisitions items |
| 20:39 |
bshum |
And once the item becomes active, it goes to fill whoever placed their holds first, or whatnot. |
| 20:39 |
hbrennan |
Yeah, problem is with us it could be months and months before the item is active |
| 20:40 |
hbrennan |
The processors often get pulled away for other duties |
| 20:42 |
hbrennan |
So, in general, if something can't be reported on in Evergreen, it is probably still possible with SQL? |
| 20:42 |
bshum |
It just depends on what you're trying to report on. |
| 20:42 |
hbrennan |
SQL seems like a magic process where almost anything can be known |
| 20:43 |
bshum |
I call almost all the reports I see a version of the truth. |
| 20:43 |
bshum |
Or outright lies :D |
| 20:43 |
hbrennan |
It's like a translation of a translation? |
| 20:48 |
hbrennan |
Ha. SQL for Dummies just arrived at our library |
| 20:48 |
hbrennan |
Maybe it's a sign |
| 20:55 |
|
mjingle joined #evergreen |
| 21:06 |
|
dbs_ish joined #evergreen |
| 21:07 |
dbs_ish |
hbrennan: you might find http://coffeecode.net/archives/263-Introducing-SQL-to-Evergreen-administrators,-round-two.html useful |
| 21:07 |
hbrennan |
Oh yes, thank you |
| 21:09 |
hbrennan |
Since the only thing I see using SQL for currently is Evergreen, I really want to focus on what I learn being useful to EG |
| 21:09 |
hbrennan |
dbs_ish++ and dbs++ since that's who you usually are |
| 21:10 |
hbrennan |
I am dishing out the karma points today. I'm lucking out on help |
| 21:11 |
gsams |
dbs++, my resources grow yet again |
| 21:12 |
dbs_ish |
happy to help! give bibliomation and COOL some pros too, they supported the development of a lot of that material |
| 21:16 |
gsams |
hbrennan: I should probably make more use of LinkedIn than I do honestly, but at least I'm there! |
| 21:16 |
hbrennan |
Gosh and it's in epub too. Now I have some new bedtime reading material |
| 21:17 |
hbrennan |
Yeah I know, me too. I still don't get what it's really good for (unless you like shopping for new jobs constantly), but I've found a use for it |
| 21:17 |
|
RBecker joined #evergreen |
| 21:18 |
hbrennan |
If I can make it to a second Evergreen conference it will help make reintroductions less awkward |
| 21:18 |
gsams |
It's an excellent use for it in my opinion, I'll have to keep that in mind |
| 21:18 |
gsams |
My boss and I should be attending next year's conference, I'll be wearing the hat most likely |
| 21:18 |
hbrennan |
Almost everyone who's active in Evergreen is there |
| 21:19 |
hbrennan |
You won't be the only one with a hat like that :) |
| 21:20 |
gsams |
I hope not, it's a classy hat! |
| 21:20 |
gsams |
rather, I hope I'm not the only one |
