| Time |
Nick |
Message |
| 01:29 |
|
pinesol_green` joined #evergreen |
| 01:31 |
|
berick joined #evergreen |
| 01:33 |
|
DPearl joined #evergreen |
| 04:57 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:33 |
|
robbat2 joined #evergreen |
| 07:33 |
|
robbat2 joined #evergreen |
| 08:19 |
|
ericar joined #evergreen |
| 08:20 |
|
akilsdonk joined #evergreen |
| 08:29 |
|
mrpeters joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:54 |
bshum |
dbs: I think the demo site must be some earlier 2.5 (it has responsive TPAC, so it's at least 2.5.0) |
| 08:54 |
bshum |
But yes, agree that more up to date demo sites would be nice. |
| 08:56 |
|
kbeswick joined #evergreen |
| 08:59 |
jeff |
I don't think that there's currently a feature that allows a skin to chroot its view of users for login/auth -- pondering if it would be useful or not. |
| 09:01 |
bshum |
dbwells: I'm going to add a 2.6 series in Launchpad and move milestones over to it. Also adding a milestone for 2.6.0 proper so that folks can target final bug fixes for that. |
| 09:04 |
dbwells |
bshum: I'd be happy to take care of that if you wish |
| 09:05 |
bshum |
dbwells: Actually I guess you probably should handle the bug closing, retargeting, etc. with that LP account (which I'll figure out from you later how to use) |
| 09:05 |
bshum |
I just finished moving the 2.6 milestones to be applied to the 2.6 series at least |
| 09:05 |
dbwells |
bshum: right, no problem. I'll do it right now. |
| 09:06 |
|
Dyrcona joined #evergreen |
| 09:08 |
dbs |
bshum: you're right, 9f7b95cdaf7d7e went into 2.5.3. So demo.evergreencatalog.com is 2.5.2 or earlier |
| 09:08 |
pinesol_green` |
[evergreen|Dan Scott] TPAC: Use indexed subfields only in author search links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9f7b95c> |
| 09:08 |
bshum |
dbs: 2.5.0 if http://demo.evergreencatalog.com/gateway?service=open-ils.actor&method=opensrf.open-ils.system.ils_version is to be believed |
| 09:09 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Possible 0877 breakage" (18 lines) at http://paste.evergreen-ils.org/47 |
| 09:09 |
Dyrcona |
bshum: Have you seen the above? ^^ |
| 09:09 |
bshum |
Dyrcona: Yes, that happened to me. |
| 09:09 |
|
yboston joined #evergreen |
| 09:10 |
Dyrcona |
bshum: Did you figure it out? |
| 09:10 |
bshum |
Dyrcona: What I found was that local definitions were breaking things in browse for some reason. I never did get to the bottom of that with eeevil. |
| 09:10 |
bshum |
We had an added author entry that was also for browse and something in the xpath or such was breaking the indexing process. |
| 09:11 |
bshum |
I think I set it aside in my testing by making it not a browse entry for the moment and then things proceeded as expected. So something in how I defined a local index broke things. |
| 09:11 |
Dyrcona |
I'll check. We probably have a similar situation. |
| 09:11 |
bshum |
Though i'm not 100% sure why. |
| 09:11 |
bshum |
I think it was a combination of explicit marcxml definition vs. mods32 stuff |
| 09:11 |
Dyrcona |
I don't recall adding browse search definitions. As I recall, the one that I tried adding never worked. |
| 09:11 |
bshum |
And the browse-xpath entry borked something |
| 09:12 |
* dbs |
wonders if phasefx's live testing script could be repurposed to also leave a running system at dev.evergreencatalog.com at the end; and set up not just master, but also current stable for demo.evergreencatalog.com |
| 09:13 |
Dyrcona |
Heh. My laptop just updated "libmagic1." I wish it really lived up to the name. :) |
| 09:16 |
|
Guest37989 joined #evergreen |
| 09:17 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Only browse_xpath we added" (3 lines) at http://paste.evergreen-ils.org/48 |
| 09:17 |
Dyrcona |
That's the only custom one that I see we've added for browse. |
| 09:18 |
bshum |
That's basically what I found too, I think |
| 09:18 |
bshum |
http://irc.evergreen-ils.org/evergreen/2014-03-28#i_82325 |
| 09:19 |
bshum |
eeevil probably got busy and we didn't finish our conversation about which part of it was broken. Other than it being broken. |
| 09:19 |
Dyrcona |
We added that originally for a facet definiton, IIRC. You might have mentioned that above. |
| 09:20 |
Dyrcona |
Ah, well. Yours is different. |
| 09:20 |
bshum |
Yes. |
| 09:21 |
Dyrcona |
You're using marcxml and trying to get the name-part that comes from MODS. |
| 09:21 |
Dyrcona |
Mine is using MODS the whole way. |
| 09:21 |
bshum |
That's definitely different then. |
| 09:21 |
bshum |
Hmm |
| 09:22 |
Dyrcona |
I'm not sure, but I doubt your definition works at all. |
| 09:23 |
* bshum |
shrugs |
| 09:24 |
bshum |
I added it so long ago at the request of catalogers. Presumably they might have said something if the searches didn't turn up hits... |
| 09:24 |
bshum |
But it wouldn't surprise me. |
| 09:25 |
Dyrcona |
I am going to add checking for the roleTerm[text() = "creator"] to see if that fixes it. |
| 09:26 |
dbs |
anyone mind if I drop demo.ils.edoceo.com from http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers#community_demo_servers? It has been "coming soon" since at least November. |
| 09:26 |
|
dluch joined #evergreen |
| 09:26 |
bshum |
dbs: +1 to removing it |
| 09:27 |
Dyrcona |
I don't mind. |
| 09:27 |
Dyrcona |
:) |
| 09:28 |
jeff |
remove. easy to re-add later, if it comes around. |
| 09:29 |
dbs |
Gone |
| 09:30 |
* dbs |
notes that http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers has said demo.evergreencatalog.com is "running 2.5.0" for quite a while. duh. dbs-- |
| 09:30 |
Dyrcona |
bshum: Well, that doesn't help. |
| 09:30 |
Dyrcona |
My xpath now looks like this: //mods32:mods/mods32:name[mods32:role/mods32:roleTerm[text()='creator']] |
| 09:34 |
Dyrcona |
bshum: bug or not? |
| 09:42 |
bshum |
Dyrcona: Might be worth creating a bug for it. People who have custom definitions that aren't quite right (for whatever unknown reason) will have troubles attempting the upgrade to 2.6 I think. |
| 09:43 |
Dyrcona |
bshum: Will do. I've tried messing with the xpath to no avail. I'm going to disable the browse_field on that entry and see what happens. |
| 09:45 |
Dyrcona |
Well, that doesn't help, either. |
| 09:46 |
bshum |
That's strange... disabling browse_field and removing the browse_xpath allowed me to move forward. |
| 09:46 |
bshum |
I think |
| 09:46 |
* bshum |
doubts himself now. |
| 09:47 |
|
akilsdonk_ joined #evergreen |
| 09:49 |
* eeevil |
returns from camping |
| 09:50 |
eeevil |
bshum: sorry, I thought we were on the same page. what Dyrcona was saying earlier this morning is correct, you choose one format and all xpath is based on that |
| 09:51 |
eeevil |
the main xpath field constrains the universe of what that definition cares about, and the various blah_xpath fields further whittle that down (though they don't need a namespace in the xpath -- it uses the "default namespace" as defined by XPath) |
| 09:54 |
eeevil |
so you might have, say, xpath=//*[@tag=245] and facet_xpath=//*[contains("abpn",@code)] ... that would index all subfields for search, but just title, subtitle, part, and number for the facet |
| 09:57 |
|
RoganH joined #evergreen |
| 10:02 |
Dyrcona |
bshum: I think I must have a customized stock entry that is causing my problem and not this one that we added. |
| 10:03 |
bshum |
eeevil: That makes sense. Thanks for the rundown. |
| 10:05 |
bshum |
Dyrcona: How I ultimately found the culprit metabib entry was adding some raise notice statements to that function that remaps things to let me know exactly which one was being attempted. |
| 10:06 |
bshum |
I've never messed with any of the default metabib entries for our system as far as I know. |
| 10:06 |
Dyrcona |
bshum: Got a git branch or a patch for that? It would be most helpful to not duplicate work. |
| 10:07 |
Dyrcona |
I think we might have changed one or two, but my memory is fuzzy. I'll have to compare with the stock entries in 950.*.sql or wherever. |
| 10:07 |
bshum |
Dyrcona: Unfortunately no, I was just messing with the function's definition directly in my pgadmin window and learning how to apply the raise statements. |
| 10:07 |
Dyrcona |
bshum: NP. Just thought I'd ask. |
| 10:07 |
bshum |
I don't think I have that anymore because we blew away that test system already :( |
| 10:08 |
Dyrcona |
I am going to run another browse ingest and capture all of the output to a file. |
| 10:08 |
Dyrcona |
Then, I'll know if it is every record or just some records. |
| 10:08 |
Dyrcona |
Maybe I'll try adding the raise statements beforehand. |
| 10:09 |
Dyrcona |
Might as well, eh? |
| 10:09 |
bshum |
I think I added a raise statement to let me know which record ID was being worked on for any given attempt to add new browse entries. |
| 10:09 |
bshum |
And then I figured out how to add a raise statement to show which attribute or such |
| 10:10 |
bshum |
But it was late |
| 10:10 |
bshum |
My brain is fuzzy |
| 10:13 |
bshum |
I think I got the idea when I saw there were already a few commented out RAISE statements in the existing function. |
| 10:22 |
Dyrcona |
@blame Search |
| 10:22 |
pinesol_green` |
Dyrcona: 14 found: #10: "everything was going great until $who came along", #11: "$who musta been an Apple employee.", #12: "$who is NOT CONNECTED TO THE NETWORK!!!", #13: "$who must eat cottage cheese!", #14: "$who forgot to give the gerbils their...", #15: "$who 's bugfix broke my feature!", #2: "It's all $who's fault!", #3: "Your failure is now complete, $who.", #4: "It really IS $who's fault!", (1 more message) |
| 10:22 |
Dyrcona |
Hah... |
| 10:23 |
Dyrcona |
I was trying to blame "search" and not search blame. :) |
| 10:32 |
dbs |
Man, SLiMS is kicking our butts with their landing page: http://slims.web.id/landing/ |
| 10:32 |
dbs |
SLiMS++ :) |
| 10:33 |
|
dluch joined #evergreen |
| 10:44 |
Dyrcona |
bshum: Just fyi, the raise notice does point to my field 1001 being the problem. |
| 10:44 |
Dyrcona |
more raise notices in biblio.extract_metabib_field_entry are in order. |
| 10:45 |
Dyrcona |
As for SLiMS, how many ILS projects does the world need? |
| 10:46 |
jboyer-isl |
Dyrcona: One less than emacs plugins, one more than notepad replacements. |
| 10:46 |
Dyrcona |
jboyer-isl: But that adds up to infinity! |
| 10:47 |
dbs |
Dyrcona: apparently foss4lib.org is tracking 18 now. But SLiMS has been around for quite a while. |
| 10:48 |
|
ckolasinski joined #evergreen |
| 10:48 |
Dyrcona |
dbs: This is the first that I have heard of it, but I don't get out much. |
| 10:50 |
jboyer-isl |
As software gets easier to write the number of projects in any category approaches infinity. (As does the number of categories; just at a slower rate.) |
| 10:53 |
dbs |
First stable release was November 2007. But mostly visible inside Indonesia. |
| 10:59 |
gmcharlt |
dbs: not sure I agree that the landing page is all that great -- it takes time to load, most of the apparently clickable areas don't function, and you have to hunt to find the link to the "real" website (http://slims.web.id/web/) |
| 11:00 |
gmcharlt |
on the other hand, I do like how it puts grabbing the software top and center |
| 11:00 |
berick |
https://bugzilla.mozilla.org/show_bug.cgi?id=594502 *sigh* |
| 11:00 |
pinesol_green` |
Mozilla bug 594502 in General "Method for accepting certificates for secure WebSockets connections (wss://)" [Enhancement,Unconfirmed: ] - Assigned to nobody |
| 11:00 |
* berick |
refreshes memory on importing CAs |
| 11:02 |
|
atlas__ joined #evergreen |
| 11:07 |
Dyrcona |
jboyer-isl: I'm not so sure that software is getting easier to write, not well anyway. |
| 11:09 |
jboyer-isl |
It's certainly not easier to write well. But things like "best-guess" typing and languages without pointers (or well-hidden pointers) make it /look/ easier, which also leads to the problem. "How hard can this be to write an X? I'll show them how it's done!" |
| 11:10 |
Dyrcona |
bshum eeevil : Messing around with biblio.metabib_extract_field_entry shows me that our metabib fields with ids 8 and 1001 are getting nothing for browse text and sort value. I'll keep digging. |
| 11:10 |
jboyer-isl |
That's one of the reasons I dislike languages like perl and php. Static typing is (literally) the most basic thing you can do to sanity check code, and they threw it away! |
| 11:11 |
Dyrcona |
jboyer-isl: I liken it to building bridges and us not knowing what we're doing, yet. I'm sure that for the first 60 or so years that human built bridges, most of them collapsed with alarming frequency. ;) |
| 11:12 |
jboyer-isl |
Dyrcona: Definitely. Except I think it was longer than 60 years. :D |
| 11:12 |
Dyrcona |
jboyer-isl++ |
| 11:14 |
Dyrcona |
I say 60 because that's roughly how long we've really been trying to do software on a large scale. |
| 11:14 |
jeff |
berick: sent you a recommendation on an inexpensive ssl cert. comes down (at least a little bit) to how much you value your time and the time of your testers, and down to "am i going to ask testers to give me the keys to their browser for all sites" :-) |
| 11:18 |
Dyrcona |
Interesting, I don't think we've modified the Personal Author config.metabib_field. |
| 11:18 |
berick |
jeff++ |
| 11:28 |
jboyer-isl |
jeff, berick, others: StartCom offers "real" SSL certificates for free at https://www.startssl.com/ . There are some limitations (obviously), but they should work. |
| 11:28 |
jboyer-isl |
All major browsers accept them currently, so if you're willing to put in the time, sec exceptions could be done away with entirely. |
| 11:29 |
|
kmlussier joined #evergreen |
| 11:29 |
jboyer-isl |
For instance, you can't have wildcard certs, and if you want the higher level of trust (can't remember the name off hand) those aren't free. |
| 11:30 |
bshum |
For awhile, we used startssl's wildcard SSL cert |
| 11:30 |
|
edoceo joined #evergreen |
| 11:30 |
bshum |
And then one day, we ended up with horrible system issues |
| 11:30 |
bshum |
Ultimately we diagnosed it to a bad cert chain issue |
| 11:31 |
bshum |
When we asked startcom to help us, they were kind of... unhelpful |
| 11:31 |
bshum |
So we stopped using them. |
| 11:31 |
jeff |
i use startcom's startssl certs in some places, but they just aren't suitable for every circumstance, and now that an inexpensive cert is $11/yr instead of $59/yr, I tend to recommend that first. |
| 11:31 |
bshum |
But yes, for a free quick start, not a bad place to go. |
| 11:31 |
|
mcooper joined #evergreen |
| 11:31 |
jcamins |
jeff: where do you get your $11/year certificates? |
| 11:32 |
jeff |
jcamins: namecheap has geotrust rapidssl certs for $10.95/yr |
| 11:33 |
jcamins |
jeff: good to know. Especially since they're my registrar. |
| 11:33 |
jl- |
we use wildcard from comodo |
| 11:33 |
jl- |
namecheap |
| 11:37 |
Dyrcona |
Heh. |
| 11:37 |
Dyrcona |
For true security, delete your CAs. |
| 11:37 |
Dyrcona |
Write down the ids of the certs a site gives you. |
| 11:42 |
jboyer-isl |
Ooh, last I looked the cheapest was around $100. I'll definitely keep namecheap in mind. (Never used startssl; just seen it mentioned a few times.) |
| 11:49 |
jeff |
technically you can get cheaper single-year certs from namecheap, but it would require dealing with a company that i don't like, mostly due to their telemarketing practices. :-) |
| 11:57 |
|
atlas__ joined #evergreen |
| 12:13 |
|
Christineb joined #evergreen |
| 12:58 |
|
mllewellyn joined #evergreen |
| 13:00 |
|
atlas__ joined #evergreen |
| 13:13 |
Dyrcona |
So, it appears that after 0877, browse indexing blows up records without authors in the mods transform. |
| 13:15 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Browse for author falls down, goes boom." (50 lines) at http://paste.evergreen-ils.org/49 |
| 13:16 |
Dyrcona |
Notice the <namepart/> bit. |
| 13:22 |
|
atlas__ joined #evergreen |
| 13:29 |
bshum |
Yay, my code4lib book has arrived! |
| 13:30 |
bshum |
Dyrcona: Well that's... special. |
| 13:30 |
jeff |
good news: i created a git repo for this 3m sorter utility. |
| 13:30 |
jeff |
bad news: no commits yet. :P |
| 13:31 |
jeff |
but there's a useful README and such, so there's that. |
| 13:32 |
jl- |
is the bib_tag in the database something like a collection/respository name? |
| 13:33 |
eeevil |
Dyrcona: huh ... is there a 1xx in the marc? |
| 13:35 |
Dyrcona |
eeevil: Indeed there is: <datafield tag="100" ind1="1" ind2=" "><subfield code="a">:</subfield></datafield> |
| 13:35 |
Dyrcona |
The record ingests just fine in production but fails in training and development where we've upgraded. |
| 13:36 |
Dyrcona |
I'm not so sure that 0877 is the culprit now, but something else since 0848. |
| 13:36 |
eeevil |
do you have an error message, maybe in the pg log? (sorry if I missed that) |
| 13:37 |
jl- |
btw., vufind is creating a new logo and tagline, feel free to vote if you know vufind: https://www.surveymonkey.com/s/RXBJ9BB |
| 13:38 |
Dyrcona |
eeevil: From metabib.reingest_field_entry? |
| 13:39 |
Dyrcona |
I get this when calling the function in psql on that record: http://paste.evergreen-ils.org/47 |
| 13:39 |
eeevil |
Dyrcona: I guess? which ever statement is failing when it hits that record |
| 13:39 |
eeevil |
ah! ok |
| 13:39 |
Dyrcona |
I am going to check the 100 in production, just for sanity's sake. |
| 13:40 |
eeevil |
yeah, that 100 is ... bogus |
| 13:40 |
eeevil |
I mean, we can protect against NULLs in value and sort_value, but that's easily argued "bad data" ... of course, it's marc, so I'm being redundant |
| 13:41 |
jl- |
anyone care to explain the \set bib_tag '''BIB TAG''' ? it will set bib_tag for each record.. is that for a collection or repository or library ? :) |
| 13:41 |
Dyrcona |
eeevil: Something changed, though, 'cause the record looks the same in production. This is likely to bite others. |
| 13:42 |
eeevil |
Dyrcona: indeed. I'll amend: we /should/ protect ... ;) |
| 13:42 |
* eeevil |
whips up a branch |
| 13:42 |
Dyrcona |
:) |
| 13:49 |
pastebot |
"eeevil" at 64.57.241.14 pasted "easy peasy?" (13 lines) at http://paste.evergreen-ils.org/50 |
| 13:54 |
Dyrcona |
eeevil: We have a winner! |
| 13:54 |
|
artunit joined #evergreen |
| 13:55 |
eeevil |
Dyrcona: k. you got an LP already? if not, I'll create one and toss this up |
| 13:55 |
Dyrcona |
eeevil: No, I didn't make a bug, yet. |
| 13:55 |
eeevil |
on it |
| 13:56 |
dbs |
For further win, add a pgtap test that triggers the problem (until the fix goes in, natch) |
| 13:56 |
|
hbrennan joined #evergreen |
| 13:56 |
eeevil |
dbs: this is a good point. Dyrcona, do you think you could do that? |
| 13:57 |
phasefx |
jeff: tsbere: do either of you know how to configure a staff client for a "silent" install? |
| 13:58 |
Dyrcona |
eeevil dbs: I don't usually use concerto, but I could add a record from our collection that triggers it. |
| 13:58 |
tsbere |
phasefx: What kind of silent install are you looking for? |
| 13:58 |
dbs |
Dyrcona: yeah, for a pgtap test you could just insert the record directly as part of the test. No need to rely on concerto |
| 13:58 |
eeevil |
Dyrcona: that, or forcing in a record shaped like this one at id=-2, say, and watching it blow up |
| 13:59 |
phasefx |
tsbere: the only context given to me was for "automated background installation", but I can solicit more info |
| 14:00 |
tsbere |
phasefx: Look into passing /S to the installer, if my memory is correct. If that doesn't work I can google the information. |
| 14:00 |
phasefx |
tsbere: thanks man |
| 14:01 |
Dyrcona |
dbs: I'll look into inserting the record. I recall seeing another test that does that. |
| 14:03 |
|
Wyuli joined #evergreen |
| 14:04 |
tsbere |
phasefx: I think that /autoupdate, /noautoupdate, /permachine, /nopermachine, and /developer are also accepted (when the client was built with those options) |
| 14:06 |
dbs |
Pg/t/regress/lp1242999_unbreak_new_encode.pg may be what you're looking for :) |
| 14:07 |
eeevil |
Dyrcona: a branch to base your tap test on: working/user/miker/lp1303940-browse-hates-null |
| 14:07 |
Dyrcona |
dbs && eeevil Thanks to you both. |
| 14:09 |
dbs |
eeevil is in my head |
| 14:10 |
eeevil |
dbs: it's very cold, but polite, in here |
| 14:11 |
jl- |
uhm, so about that bib_tag in the database for each record.. what is it? |
| 14:11 |
eeevil |
jl-: I confess, I have no idea what you are describing... |
| 14:11 |
jl- |
makes 2 of us |
| 14:13 |
eeevil |
oh! hah... that just pins the bib id of the records in that test dataset |
| 14:13 |
phasefx |
tsbere: invoking the installer works with /S, not sure if we can build an installer with that behavior enabled by default, but maybe /S to the installer will suffice. thanks man |
| 14:13 |
tsbere |
phasefx: I believe we could make it do so by default |
| 14:14 |
tsbere |
would require editing the nsi file, though |
| 14:14 |
eeevil |
well, no it doesn't do what I said |
| 14:15 |
tsbere |
phasefx: specifically, add "SetSilent silent" to the beginning of .onInit, I believe, in windowssetup.nsi |
| 14:16 |
phasefx |
tsbere: ah ha! thanks man *8) |
| 14:16 |
* tsbere |
isn't sure that is the best idea and prefers the /S option |
| 14:16 |
* phasefx |
nods |
| 14:16 |
eeevil |
it looks to be used for constructing the last_xact_id. you can ignore that, unless you want to be able to use that to identify batches of records that you use marcxml_import() to pull in |
| 14:18 |
jl- |
eeevil: correct, but in my case it's not a test dataset I'm using it to load our university bibs |
| 14:20 |
eeevil |
jl-: so ... what's your question. last_xact_id is used for optimistic locking in the normal workflow. it can also do double duty as a way to identify records that came into the system in batch. you can ignore it, or use it, but it's just an opaque string, insofar as the software is concerned... does that help? |
| 14:20 |
jl- |
eeevil: yes, so it might be useful in the database, but it has no functionality in the frontend? |
| 14:22 |
jl- |
see the example here: http://paste.debian.net/92250 |
| 14:22 |
jl- |
with just one record |
| 14:22 |
jl- |
of course I have ~200k following |
| 14:28 |
Dyrcona |
jl-: Note what eeevil said about "optimistic locking in the normal workflow." If a user has a record open while something else changes it in the background, the staff client won't save the user's changes if the last_xact_id has changed in the meantime. |
| 14:29 |
Dyrcona |
jl-: It's particular value is usually unimportant. |
| 14:31 |
jl- |
Dyrcona: in my case I'm planning ahead, we don't have any users. I'm running test-migrations |
| 14:32 |
Dyrcona |
jl-: I understand. We're telling you what that field is used for. Basically, it doesn't matter what you put into it at the start. |
| 14:33 |
Dyrcona |
jl-: I did something like IMPORT-{UNIX_timestamp} during our migration. |
| 14:37 |
|
RoganH joined #evergreen |
| 14:40 |
jeff |
select count(*) from asset.opac_visible_copies where copy_id is null; |
| 14:40 |
jeff |
count | 12272 |
| 14:40 |
jeff |
i'm not sure i understand that. |
| 14:42 |
dbs |
jeff: copyless 856 $9 records? |
| 14:43 |
jl- |
alright thanks |
| 14:45 |
|
jihpringle joined #evergreen |
| 14:47 |
jeff |
dbs: apparently not. same count for the query SELECT COUNT(*) FROM asset.opac_visible_copies aovc WHERE aovc.copy_id IS NULL AND NOT EXISTS (SELECT 1 FROM asset.call_number acn WHERE acn.label = '##URI##' AND acn.record = aovc.record); |
| 14:49 |
|
kmlussier joined #evergreen |
| 14:53 |
dbs |
wow, asset.cache_copy_visibility() sure is a complex trigger function these days |
| 14:57 |
jeff |
yeah, yet on a quick scan i don't see where it could result in what i'm seeing. |
| 14:57 |
jeff |
which means it's likely 1) old code that did it that's no longer present or 2) odd manual update or 3) i'm missing something else :-) |
| 14:57 |
jeff |
where 3) is hopefully always implied |
| 15:08 |
|
Dyrcona1 joined #evergreen |
| 15:17 |
Dyrcona |
wifi-- |
| 15:18 |
bshum |
@blame wifi |
| 15:18 |
pinesol_green` |
bshum: wifi 's bugfix broke bshum's feature! |
| 15:18 |
kmlussier |
berick: I got a little lost in the discussion for bug 1187993. Would it indeed be useful for me to ask somebody to do a small JAWS test of a site using HTML5 datalist elements? |
| 15:18 |
pinesol_green` |
Launchpad bug 1187993 in Evergreen "Auto suggest causes significant accessibility issues for using basic search in some browsers" (affected: 3, heat: 18) [High,Confirmed] https://launchpad.net/bugs/1187993 |
| 15:18 |
Dyrcona |
So, is it normal for pg_tap to say that you gave it a bad plan if a test fails? |
| 15:18 |
kmlussier |
berick: If so, I'll do it ASAP. |
| 15:18 |
jeff |
I see no left joins, SET copy_id, or even UPDATE statements in that trigger. |
| 15:19 |
jeff |
anyone else who cares to, i'd be interested if this turns up a non-zero value: select count(*) from asset.opac_visible_copies where copy_id is null; |
| 15:19 |
|
kbutler joined #evergreen |
| 15:20 |
eeevil |
jeff: I'm not looking at the code, but ... transcendent bibs? |
| 15:20 |
bshum |
jeff: I'm boring and came back with zero results for that query. |
| 15:20 |
jeff |
eeevil: i have several instances that are not, and from what i've dug into so far, i don't think those or located URIs come into play for this mat view. |
| 15:21 |
berick |
kmlussier: yes, it would be helpful, thanks |
| 15:21 |
kmlussier |
OK, will do. |
| 15:25 |
mmorgan |
jeff: I'm getting zero, too. |
| 15:26 |
jeff |
max(id) on that mat view is 16222979 currently, and max(id) where copy_id is null is 2682029, so i'm going to assume that whatever caused it is fixed now. |
| 15:27 |
jeff |
odd mystery, though. even looked at upgrade scripts for asset.cache_copy_visibility and don't see anything (again, quick scan) that could lead to that. |
| 15:29 |
eeevil |
berick / kmlussier: a drawback to that: I believe we'll lose the highlighting in the autosuggest dropdown (well, and the ability to format at all... which we do now for the supplying class/field in addition to the highlight) |
| 15:30 |
jeff |
ooh! i found it. |
| 15:30 |
eeevil |
oh! well, actually, we can get the class/field labeling off to the right (text content in the <option>), but not the highlight... :( |
| 15:31 |
mmorgan |
jeff: what did you find? |
| 15:32 |
kmlussier |
eeevil: I would take accessibility over highlighting, but I'm just one person. Unless there are other options that give us both. |
| 15:32 |
eeevil |
berick / kmlussier: -^ ... also, still no formatting on the <option> content, but it is shown lighter and smaller than the value attribute data |
| 15:33 |
berick |
eeevil: yeah, hadn't really gotten that far |
| 15:33 |
eeevil |
kmlussier: I think there can be, but <datalist> won't do both. unfortunate, really, because the highlighting was a big part of the original request and design... |
| 15:34 |
jeff |
a long time ago the table asset.opac_visible_copies was (id, circ_lib, record), and the function to populate it from scratch (asset.refresh_opac_visible_copies_mat_view) used INSERT INTO asset.opac_visible_copies (id, circ_lib, record) SELECT cp.id, cp.circ_lib, cn.record [...] |
| 15:35 |
bshum |
A long time ago, in an Evergreen system far, far away... |
| 15:35 |
jeff |
but if you upgraded to the point where the asset.opac_visible_copies table was now (id, copy_id, record, circ_lib) but you ran the OLD asset.refresh_opac_visible_copies_mat_view which spelled copy_id as just "id"... |
| 15:36 |
jeff |
...you'd eventually end up with stale entries that would never be updated. |
| 15:36 |
jeff |
and thus, permanently visible records with no actually visible copies. |
| 15:37 |
jeff |
unless and until you either deleted the rows with a null copy_id, or ran the correctly updated asset.refresh_opac_visible_copies_mat_view to truncate and re-generate the data in the asset.opac_visible_copies table |
| 15:38 |
jeff |
confirmation will be if the id of the rows with null copy_id match a copy that is tied to a matching record |
| 15:39 |
jeff |
confirmation! |
| 15:39 |
jeff |
oof. |
| 15:58 |
bshum |
kmlussier: Hmm, bug 1251394 to make the list of new features to highlight for further discussion at the dev meeting? |
| 15:58 |
pinesol_green` |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" (affected: 3, heat: 14) [Undecided,New] https://launchpad.net/bugs/1251394 - Assigned to Bill Erickson (erickson-esilibrary) |
| 15:59 |
kmlussier |
bshum: That works for me if it's okay with berick. |
| 15:59 |
kmlussier |
We are looking forward to the day when our reports display titles in proper case. |
| 16:00 |
berick |
talk about stuff? never! |
| 16:00 |
berick |
bshum++ |
| 16:01 |
eeevil |
berick / kmlussier: I commented on https://bugs.launchpad.net/evergreen/+bug/1187993 with another, bigger concern with <datalist> |
| 16:01 |
pinesol_green` |
Launchpad bug 1187993 in Evergreen "Auto suggest causes significant accessibility issues for using basic search in some browsers" (affected: 3, heat: 18) [High,Confirmed] |
| 16:03 |
kmlussier |
eeevil / berick: I concur that 1) looks like a major issue. |
| 16:03 |
berick |
eeevil: for #1, i was assuming we could populate the datalist from the autosuggest search |
| 16:03 |
|
gmcharlt_ joined #evergreen |
| 16:03 |
berick |
wait, nevermine |
| 16:03 |
eeevil |
berick: sure, but the browser will only display left-anchored maches from the <datalist>, regardless |
| 16:03 |
berick |
i see what yr saying |
| 16:04 |
eeevil |
right :) |
| 16:04 |
kmlussier |
I did just a little reading on datalists, and I thought I saw that you could control the formatting by adding a class to the input element. |
| 16:05 |
berick |
kmlussier: i played with it a little, it's not cooperative |
| 16:05 |
kmlussier |
Ah, ok then. |
| 16:05 |
berick |
yeah, oh well. easy come, easy go |
| 16:14 |
* eeevil |
beats the dead horse: http://www.noupe.com/webdev/html5-datalists-what-you-need-to-know-78024.html and search down for "Limitations of Datalists" |
| 16:28 |
bshum |
jquery eh? |
| 16:28 |
* bshum |
likes the article's explanations. Thanks eeevil! |
| 16:33 |
kmlussier |
And is jquery an option for us? |
| 16:36 |
jeff |
wheezy, precise, and saucy users may want to keep an eye out for an openssl security update fixing CVE-2014-0160. squeeze appears to be unaffected. http://www.openssl.org/news/secadv_20140407.txt |
| 16:36 |
pinesol_green` |
** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160) |
| 16:38 |
bshum |
kmlussier: Well I wondered about angularjs solutions too. Like http://justgoscha.github.io/allmighty-autocomplete/ |
| 16:39 |
bshum |
Not that I know anything about either |
| 16:39 |
bshum |
Or anything |
| 16:39 |
bshum |
I know nothing |
| 16:39 |
bshum |
Today is that sort of day |
| 16:45 |
pastebot |
"gsams" at 64.57.241.14 pasted "mail looks to be going out, but I'm getting a lot of complaints. Is there anything I'm missing?" (2 lines) at http://paste.evergreen-ils.org/51 |
| 16:46 |
gsams |
We keep getting complaints about courtesy notices not showing up, and if it weren't for the volume of complaints I would assume trying to get out of paying. |
| 16:47 |
Dyrcona |
Junk mail filters on the user's end. |
| 16:48 |
gsams |
that is what I say, but a few have been pretty adamant about that not being the case. |
| 16:48 |
gsams |
a few people I would consider to know better otherwise even. |
| 16:48 |
Dyrcona |
Do they control their own mail server? If not, then they don't know. |
| 16:48 |
bshum |
That's more or less what I've been telling folks too who claim not to be getting their notices. |
| 16:48 |
gmcharlt |
adding SPF records for the libraries' domains referring to the Evergreen (mail)server would help, if they don't already exist |
| 16:50 |
jeff |
seconding the SPF record, which can be as simple as "v=spf1 mx ?all" if the mail comes from a host that is listed as an MX for the return domain. |
| 16:50 |
jeff |
just don't screw it up, or you'll end up worse off. :-) |
| 16:50 |
Dyrcona |
That's a useless spf record and should not be allowed. |
| 16:50 |
Dyrcona |
?all... is useless. :) |
| 16:50 |
jeff |
(and ensure that you communicate to relevant parties that the outgoing mail path should not be changed without adjusting the SPF record) |
| 16:51 |
jeff |
Dyrcona: I'd call it "safe" and "conservative", but not "useless". All depends on point of view, though. |
| 16:51 |
gsams |
I'll have to check and see if that wasn't setup. I'm betting it hasn't though, not a lot of people working on these things. |
| 16:52 |
* Dyrcona |
has run mail servers for over 15 years. That's my point of view. :) |
| 16:52 |
gsams |
Dyrcona++ bshum++ jeff++ gmcharlt++ |
| 16:52 |
gsams |
thanks for the help! |
| 16:52 |
Dyrcona |
gsams: Is mostly one ISP, or do you know? |
| 16:53 |
gsams |
Dyrcona: I believe it is, but I'm not 100% on that. |
| 16:54 |
jeff |
now i'm thinking of the years and the MTAs... eesh... sendmail, smail, Mercury, AIMS, qmail, exim, postfix, exchange, and groupwise. |
| 16:54 |
Dyrcona |
Individual ISPs often have things that they suggest for getting mail to their users. |
| 16:54 |
jeff |
iirc, at least one of those used the operating system's print queue functionality for mail. |
| 16:54 |
Dyrcona |
SPF is a decent start. |
| 16:56 |
jeff |
gsams: since you mentioned gmail in particular (in your log message), i'd try to find a gmail user that has had a message end up in their spam folder, and see what hints gmail offers for why it was there. |
| 16:57 |
gsams |
I will definitely look at that, it seems to mostly be gmail lately that's been throwing them out. |
| 16:57 |
jeff |
gsams: in addition to that, i'd review this document from Google, which spells things out more than I can right now: https://support.google.com/mail/answer/81126?hl=en |
| 16:57 |
jeff |
gsams: pay particular attention to the basics, like the reverse DNS (PTR) record for the mail server. |
| 16:58 |
gsams |
jeff++ #that will be super helpful! |
| 16:59 |
gsams |
jeff: yeah the basics, I'm pretty sure are solid. But the also recommend portion is definitely questionable for us. |
| 16:59 |
jeff |
also, generating some test messages to a gmail account you control can help when you get to the point of reviewing your SPF record, etc. -- it's useful to do a before and after there. |
| 16:59 |
jeff |
FWIW, we do not currently do DKIM or DMARC on our transactional email from the ILS, and have not had problems. |
| 17:00 |
jeff |
But we also have a pretty strong separation between transactional and promotional -- our promotional stuff goes through completely different channels. |
| 17:01 |
jeff |
The unfortunate truth is that in some cases, a handful of users hitting "this is spam" can hurt you regardless of what you do. |
| 17:01 |
jeff |
for sufficiently large values of "handful" :-) |
| 17:01 |
gsams |
yeah, that also had occured to me. I know at least this is purely transactional though, so I've got that going for me. |
| 17:02 |
gsams |
and SPF is setup already... |
| 17:02 |
jeff |
worth a test to ensure that your spf record as seen by and interpreted by google is resulting in a pass. |
| 17:03 |
jeff |
(headers as viewed in gmail "View Original" will help there) |
| 17:03 |
gsams |
well, the odd thing for me: v=spf1 include:_spf.google.com ~all |
| 17:05 |
gsams |
I'm honestly not sure if that is odd actually... |
| 17:05 |
jeff |
sounds like you're a google apps user, and sounds like that SPF record is intended to identify the mail for that domain that is sent through google apps. it does not appear to account for the mail being sent from the ILS. |
| 17:06 |
gsams |
you are correct, I am seeing differences in other parts of our setup... |
| 17:06 |
bshum |
~all = if receiving mail servers receive a message from this domain that doesn’t match this record, they should accept it but mark it as suspicious. |
| 17:06 |
pinesol_green` |
bshum: I am only a bot, please don't think I'm intelligent :) |
| 17:07 |
bshum |
Oops, darn you pineso |
| 17:07 |
jeff |
if you have a google apps account configured for the domain example.org and your emails from the ILS go out with a return address of example.org, you should modify the SPF record to include the smtp server that sends the ILS emails. |
| 17:07 |
gsams |
it looks like that might be a leftover of another organization actually |
| 17:08 |
|
mmorgan left #evergreen |
| 17:08 |
jeff |
"A "SoftFail" result should be treated as somewhere between a "Fail" and a "Neutral". The domain believes the host is not authorized but is not willing to make that strong of a statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal." |
| 17:09 |
jeff |
with ~all and the sending server not in the list, you'll get a softfail. |
| 17:09 |
jeff |
which is in most cases worse than not having any SPF record. :-) |
| 17:09 |
jeff |
even with the "Receiving software SHOULD NOT reject the message based solely on this result" bit. |
| 17:26 |
gsams |
well a postfix test showed it heading to spam for my gmail. I've gone in and added an SPF record for our system, so we will see in a bit if it helps us out. |
| 17:26 |
gsams |
jeff++ Dyrcona++ |
| 17:26 |
gsams |
thanks again! |
| 17:26 |
gsams |
bshum++ as well |
| 17:27 |
bshum |
gsams++ # raising the question and getting me wondering about our own systems too.... |
| 17:31 |
gsams |
roanoke_patrons++ #for raising the issue enough times to get me to do that! |
| 17:31 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:46 |
|
book` joined #evergreen |
| 18:56 |
gmcharlt |
FYI, OpenSSL has released a major security fix http://heartbleed.com/ |
| 18:56 |
rangi |
yeah, upgrade all the things |
| 18:56 |
rangi |
except squeeze, squeeze is ok |
| 19:09 |
hbrennan |
All the things! |
| 19:09 |
hbrennan |
Sorry, lurking all day but I can't help myself when that comes up |
| 20:45 |
|
b_bonner joined #evergreen |
| 20:46 |
|
mtcarlson_away joined #evergreen |
| 21:18 |
|
jeff_ joined #evergreen |
| 21:47 |
bshum |
hbrennan++ |
| 21:48 |
bshum |
# for asking fun questions |
| 21:51 |
hbrennan |
Aw, thanks bshum. Anything to avoid finishing my expense report for the conference travel |
| 21:51 |
hbrennan |
:) |
| 21:51 |
bshum |
Indeed :) |
| 21:52 |
hbrennan |
I also received a grant for continuing education so I had to do extra reporting |
| 21:52 |
hbrennan |
I think I'm done now.. but finance always has the final say! |
| 21:55 |
hbrennan |
Welp, just learned it's National Beer Day... sounds like a good time to go home! |
| 21:58 |
bshum |
Fun times, enjoy! |
| 22:01 |
hbrennan |
Will do! |
| 22:48 |
|
dluch joined #evergreen |
| 22:49 |
bshum |
@coin |
| 22:49 |
pinesol_green` |
bshum: heads |
| 22:49 |
jeff |
heads i win, tails you lose. |
| 22:50 |
bshum |
Heh, classic. ;) |
| 23:11 |
jeff |
hrm. thinking back again on this opac visible copy mat view, i'm still having trouble reproducing it in my head. if the old function had been run against the new table schema, i'd expect there to be more than 12k rows with a null copy_id |
