| 00:20 |
|
nhilton joined #evergreen |
| 00:32 |
jeff |
dbs++ |
| 04:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:31 |
|
chatley joined #evergreen |
| 07:25 |
|
wsmoak joined #evergreen |
| 07:42 |
|
TaraC joined #evergreen |
| 11:46 |
tsbere |
attr and value come from the left joined table |
| 11:46 |
eeevil |
sure they do |
| 11:47 |
eeevil |
so your problem stems from not having a coded_value_map-side value, at all, from those records. is that correct? |
| 11:48 |
tsbere |
The problem stems from "we are getting at least one null when the previous, pre-peformance-improvement code would never have spit a null out" regardless of *where* that null comes from. Removing the left joins brings the "faster" (I haven't tested that myself) code back into not outputting those nulls. |
| 11:49 |
eeevil |
you're seeing, what, a row for titlesort from uncontrolled, and a second row with nulls for both attr and value. is that right? |
| 11:49 |
Dyrcona |
They have mravl entries. |
| 11:50 |
Dyrcona |
And, what purpose does returning nulls serve, other than to cause a database error? |
| 11:50 |
eeevil |
Dyrcona: thanks. I'm guessing the int array has only negative values in them? |
| 11:50 |
tsbere |
eeevil: The ones I am seeing in my own tests have only *positive* values. |
| 11:51 |
* tsbere |
isn't going all that deep, mind you, just trying to find ones that output nulls |
| 11:51 |
eeevil |
tsbere: so they have no title or author fields? |
| 11:51 |
|
mllewellyn joined #evergreen |
| 11:52 |
eeevil |
Dyrcona: the left join was key to helping the planner with query optimization in my tests with large data sets |
| 11:52 |
eeevil |
when going through multiple views |
| 11:52 |
tsbere |
eeevil: Looks like at least one of them has a title. |
| 11:53 |
eeevil |
tsbere: then it should have a negative value in the int array -- or the title wasn't found by the attr |
| 11:53 |
eeevil |
attr def, that is |
| 11:55 |
tsbere |
eeevil: Given that this apparently happens with real world data either the record_attr_flat view needs to never spit out nulls (as it hadn't before) or the next view up the chain needs to not dump the output directly into hstore as keys. |
| 11:56 |
eeevil |
tsbere: see my comments on the bug |
| 12:00 |
tsbere |
eeevil: I will also point out I am not finding a significant difference in plans between the left join and normal join versions of the view when I run things through explain analyse. |
| 12:01 |
eeevil |
tsbere: what data set size are you testing with |
| 12:01 |
tsbere |
eeevil: I am poking around in a copy of our production system at the moment. |
| 12:03 |
tsbere |
eeevil: Really, the only difference I can see in the plans themselves are "Nested Loop" vs "Nested Loop Left Join" |
| 12:03 |
eeevil |
well, you can either believe that I'm not lying, or you can test all code that uses either of those views (and the rec_descriptor view), I guess |
| 12:05 |
tsbere |
eeevil: I will point out that I get *very* different plans from the old version of record_attr_flat. I just don't get any improvements when I remove the LEFT from the joins in the current one. |
| 12:06 |
tsbere |
eeevil: AKA, I see improvements in the current one, but I don't see the LEFT portion of the joins aiding those improvements. |
| 12:07 |
eeevil |
a left join opens up more options for plans depending on the field from the view that is joined in a larger query. that expanded set of plan options was necessary to make certain queries fast. it was months ago that I was working on this, so I don't recall (or have time to dig up) the details right now |
| 12:11 |
tsbere |
eeevil: Well, I am not seeing those differences as I go through iterations of queries I can find happening elsewhere as I walk up from one level to the next. Major improvements on not using full_attr_id_map, but nothing on left join vs regular join. |
| 12:15 |
eeevil |
tsbere: is the filter in the next view up really so offensive to you that you'd rather try to find and test every possible way the views in question could be used? |
| 12:17 |
mrpeters |
Fix for bug 1319964 pushed to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mrpeters/lp1319964_fix_summaries_ampersand -- it's an old annoying bug that most people just fixed locally i think, but its been busted in master for a while |
| 12:17 |
tsbere |
eeevil: I am using your own "keep things outputting the same thing they did" gig - The version you replaced does not, in any of my tests, output null attr columns. Your replacement does, but is much faster in all my tests. My change to your replacement maintains the same performance boost, from what I can see, but without the null attr columns. |
| 12:17 |
pinesol_green |
Launchpad bug 1319964 in Evergreen "double-escaped entity in "Summaries & More" label" (affected: 3, heat: 18) [Low,New] https://launchpad.net/bugs/1319964 - Assigned to Athira S (athirasnamby) |
| 12:18 |
tsbere |
eeevil: As such, unless you can point at a good reason for the LEFT JOIN version to remain and spitting out null attrs I am against the view spitting out null attrs. |
| 12:21 |
|
phasefx joined #evergreen |
| 12:21 |
eeevil |
tsbere: here's my good reason: it was needed to get bshum's server to be able to search in a reasonable amount of time, because the plans became not-insane. do you believe that I am lying to you? does the solution i've suggested to your problem not work? |
| 12:23 |
eeevil |
and I would absolutely love to be able to not change the output of the view. but not at the cost of killing performance to the point of "broken for the user" |
| 12:24 |
bshum |
I haven't really tested either of the fixes (I'm not sure I can really test it without crummier bib records) but I think it'll be good to look at what has been suggested thus far. |
| 12:24 |
tsbere |
eeevil: I have no problem with changing the output of the view if you can provide information on where, exactly, things go wrong with the output remaining the same. The fact that I get massive performance boosts with the union version, with or without the left joins, says it works. I am arguing that the left join part does *not seem to matter* on that front. |
| 12:24 |
bshum |
At a cursory glance, I think eeevil's treatment for the check for not null attr columns looks sane to me. |
| 12:24 |
tsbere |
eeevil: If you can dig up evidence that I can't for the left join portion mattering I am willing to look at it. |
| 12:29 |
tsbere |
eeevil: And what *I* see is "the view outputs things differently when it doesn't need to" |
| 12:31 |
eeevil |
tsbere: you've looked at it for less than an hour |
| 12:32 |
tsbere |
eeevil: And you admit it has been a while since you looked at it. As such, from my POV my "less than an hour" is currently more relevant than your recollections from the past, unless you pull relevant data out that you collected in the past on this issue to show me. |
| 12:34 |
eeevil |
tsbere: look, you've broken search before with code that I warned would not work in situations beyond your test environment, and I had to revert and rewrite that. If I need to revert more of your code and replace it, I'll do so. you do whatever you feel you need to do for MVLC |
| 12:35 |
|
nhilton joined #evergreen |
| 12:35 |
bshum |
Alright guys, so in the interest of testing by third-parties, I'd like to request we get some sample bib records (that create the mess) that we can use to replicate the issue initially. |
| 12:35 |
bshum |
And then let's see how testing pans out for the solutions proposed. |
| 12:35 |
tsbere |
eeevil: And you also yell at people that change the output of existing *anything* in the database, because who knows what else is using it. Your changes change the output, my adjustment to your changes restores the previous output. |
| 12:37 |
tsbere |
eeevil: As I can't find a situation where the database plans differently between our two versions, but both versions are a vast (identical, as far as I can see) improvement over the version you replaced, the fact that the output is restored to what used to come out makes sense to me. |
| 12:52 |
|
mtcarlson joined #evergreen |
| 12:57 |
|
nhilton joined #evergreen |
| 13:05 |
|
sandbergja joined #evergreen |
| 13:21 |
* csharp |
would be happy to test this issue too, FWIW |
| 13:21 |
csharp |
especially since we're moving to 2.7 in about a month ;-) |
| 13:21 |
RoganH |
We're a little further than a month out but not much and I'm interested in testing for the same reason. |
| 13:22 |
csharp |
we're also bound to have a wide array of poorly cataloged records |
| 13:23 |
csharp |
and/or records mangled in multiple ILS migrations over the years, non-MARC-compliant ILSs, etc. |
| 13:23 |
RoganH |
csharp: I feel like we could have a contest to see who has imported more bad records into the consortium. :) |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:42 |
|
artunit_ joined #evergreen |
| 06:50 |
|
kmlussier joined #evergreen |
| 06:56 |
|
wsmoak joined #evergreen |
| 10:44 |
|
sfortin joined #evergreen |
| 10:58 |
eeevil |
remingtron / kmlussier: I've got a few fixes from Bill that are not yet deployed on webby. would you like me to make that happen? it'll cause just a second of outage while apache is restarted |
| 10:58 |
kmlussier |
I'm okay with that. I think there are only a few of us working on it right now. |
| 10:59 |
remingtron |
eeevil: I'm not actively testing right now |
| 10:59 |
remingtron |
eeevil: thanks! |
| 10:59 |
kmlussier |
eeevil: Anything interesting with the fixes? |
| 10:59 |
pinesol_green |
[evergreen|Remington Steed] Docs: Web Client preview intro - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=14784b3> |
| 11:01 |
eeevil |
kmlussier: they're all right here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/web-client-sprint1-bug-fixing-rebased-collab ... |
| 11:35 |
|
dreuther joined #evergreen |
| 11:41 |
mrpeters |
Fix for Bug #1154656 at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mrpeters/lp1154656_marc_expert_search_duplicate_rows if anyone has a break from documentation party today for a signoff/pullrequest! |
| 11:41 |
pinesol_green |
Launchpad bug 1154656 in Evergreen 2.4 "MARC Expert Search "Add Rows" adds duplicate row" (affected: 5, heat: 22) [Medium,Confirmed] https://launchpad.net/bugs/1154656 |
| 11:49 |
kmlussier |
If you exit the browser without first logging out, you stay logged into the web client. Is that right? |
| 11:49 |
kmlussier |
Do we know how long users stay logged in? |
| 11:51 |
|
sandbergja joined #evergreen |
| 11:51 |
* kmlussier |
can't test this without either completely exiting out of the browser with my Google Hangout session or the browser that is playing my music. :( |
| 11:51 |
|
sandbergja joined #evergreen |
| 11:51 |
jcamins |
kmlussier: time to download a new browser! |
| 11:51 |
remingtron |
kmlussier: don't you have seven different browsers installed just for testing purposes? :) |
| 11:52 |
jcamins |
kmlussier: fortunately, there are lots of options, even just with Firefox: https://www.mozilla.org/en-US/firefox/developer/ https://nightly.mozilla.org/ |
| 11:53 |
kmlussier |
No, but I have about 12 different xul staff clients installed. |
| 11:54 |
eeevil |
bshum: first, thank you for signing off the sip branch!!! unfortunately, you've got some merge issues remaining in your commit ... look at the bottom of http://git.evergreen-ils.org/?p=working/SIPServer.git;a=blobdiff;f=SIPServer.pm;h=beb6e001719b477bd7ae6d43167aafb64d96a3d2;hp=36f505de5cb99b10dd081c8586339c26f69168e3;hb=b0786d3ae13fedb87b13463c18e1bfb43df9c3b5;hpb=c8e2ac5fe68961219095ab1b42486b161ce68e48 |
| 11:54 |
kmlussier |
jcamins: I'll remember that next time. For this go-around, sacrificed the music. |
| 11:54 |
alynn26 |
I'm in the middle of staff day, had a break thought I would work on Hatch, Got to go back with the rest of the crowd, and I've logged into Webby, will close it out and come back later, and test it after a few hours. |
| 11:54 |
eeevil |
bshum: if you want, I can rebase the branch to master for a clean signoff |
| 11:55 |
bshum |
eeevil: Maybe you mean to be talking to Bmagic? |
| 11:55 |
kmlussier |
eeevil: I think that was Bmagic, wasn't it? |
| 11:58 |
Bmagic |
yeah, rebase |
| 11:59 |
Bmagic |
I thought it was odd that I only needed to change the includes...... silly rabbit |
| 12:04 |
|
sandbergja left #evergreen |
| 12:05 |
mrpeters |
bah, hold off on testing that -- i broke Advanced Search now -- ReferenceError: addSearchRow is not defined :( |
| 12:05 |
mrpeters |
fix one thing, break another ;P |
| 12:05 |
|
sandbergja__ joined #evergreen |
| 12:08 |
Dyrcona |
mrpeters++ |
| 12:08 |
* mrpeters |
loves a good game of whack-a-mole |
| 14:39 |
* kmlussier |
needs to take a break from documentation for a bit, but hopes to do a little more before the day is done. |
| 14:46 |
yboston |
kmlussier: thanks for the updates, I was going to ignore those features but I was curious if there were any ongoing plans for both |
| 14:50 |
|
akilsdonk joined #evergreen |
| 15:19 |
bshum |
eeevil: I updated the couple of bugs that were also pushed today for SIPServer. I was confused at first why there were so many new commits in SIPServer till I realized it were multiple bug tickets afoot. |
| 15:19 |
bshum |
New stuff looks cool :) |
| 15:22 |
bshum |
A question though |
| 15:22 |
bshum |
The changes for sipconfig.xml in the commit, that's a test config file of some kind right? |
| 15:23 |
bshum |
Do those need to be adapted towards oils_sip.xml config or whatever we point SIPServer to use? |
| 15:23 |
Bmagic |
I didnt look at that |
| 15:23 |
bshum |
I'm thinking on things like the <cache> area, and specifying a different memcache source for the Multiplex mode |
| 15:24 |
bshum |
And the keepalive params |
| 16:58 |
|
kmlussier joined #evergreen |
| 17:03 |
phasefx |
berick: jcamins: eeevil figured out a good solution for the focus issue, using promises: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=9730cb52064bce949a352e379759f9daec28550c |
| 17:04 |
jcamins |
phasefx: ooh, good call! |
| 17:09 |
berick |
++ to that. but I wonder why that worked and not $timeout(func-to-set-focus, some-huge-number-to-test) |
| 17:09 |
|
mdriscoll left #evergreen |
| 17:09 |
berick |
even tested an embedded $apply() |
| 17:09 |
berick |
anyway, eeevil's approach is superior to any time |
| 17:09 |
berick |
glad it works |
| 17:14 |
phasefx |
berick: we can actually get rid of the $timeout, but I didn't want to do that until we looked at all other uses of focusMe |
| 17:15 |
phasefx |
but I experimented with removing $timeout with .finally in play and it worked |
| 17:16 |
berick |
phasefx: hm, yeah, i'd be wary of removing the timout within the focusMe directive |
| 17:17 |
berick |
i mean, i'd be wary of the original zero timeout |
| 17:17 |
berick |
arg, i'd be wary of *removing* the original zero timeout |
| 17:17 |
phasefx |
berick: the some-huge-number-to-test not working thing, I'm not groking that. 1-second was working for you? |
| 17:17 |
berick |
sorry, that comment was unclear |
| 17:18 |
berick |
i tested adding a timeout within the checkout controller |
| 17:18 |
phasefx |
oh, right |
| 17:18 |
berick |
which would fire after initTab had completed (also promise-based) |
| 17:18 |
berick |
so, i was confused why one promise resolver worked, but not another |
| 11:16 |
tsbere |
csharp/mmorgan: Grab everything after "bib search:" and dump it into query_parser.pl as the -query="blah" param to possibly get the full core query - That won't help with the wrapper function, though. |
| 11:16 |
bshum |
mmorgan: And what's in "filter_group_entry(4)" |
| 11:17 |
bshum |
"history" seems like a fairly broad search |
| 11:17 |
tsbere |
csharp/mmorgan: Oh, query_parser.pl would be in Open-ILS/src/support-scripts/test-scripts |
| 11:18 |
|
cokesme joined #evergreen |
| 11:18 |
bshum |
Oooh, fancy, tsbere++ |
| 11:18 |
mmorgan |
"filter_group_entry(4)" is a format filter "Books(All)" - we are suspicious that might be part of it |
| 11:24 |
bshum |
But I know that bug was a huge stumbler for our performance when we moved up to 2.6 during the summer. |
| 11:24 |
bshum |
Along with tuning in our PG database, but that was the worst part. |
| 11:26 |
mmorgan |
bshum: I think we did, but will need to verify. |
| 11:28 |
bshum |
With the changes to formats in 2.6, I'd also be curious to know how your filter_group_entry pointed back |
| 11:28 |
bshum |
And maybe something isn't quite optimal there |
| 11:29 |
bshum |
We don't use that feature in our catalogs, so I've never tested it. |
| 11:31 |
bshum |
csharp: I'd say speed and performance considerations are always a critical element with every upgrade. :) |
| 11:32 |
* bshum |
generally loves the new icons and formats, but does think it has been an interesting road walked thus far. |
| 11:37 |
mmorgan |
So we have a few leads to follow now, thanks all! |
| 11:37 |
mmorgan |
berick++ csharp++ bshum++ tsbere++ |
| 11:38 |
* mmorgan |
needs to investigate system crankiness. |
| 15:54 |
jcamins |
I guess I know what I'm doing tonight. |
| 15:54 |
phasefx |
:D |
| 15:55 |
berick |
phasefx: see opensrf master README |
| 15:55 |
phasefx |
berick: gracias |
| 15:56 |
* phasefx |
bumped the node.js version in the qa tests, incidentally |
| 15:57 |
|
akilsdonk_ joined #evergreen |
| 16:09 |
bshum |
tsbere++ # helping me read the closed_dates.js bits |
| 16:26 |
|
arthurdent left #evergreen |
| 16:27 |
|
mike_pizza left #evergreen |
| 16:35 |
phasefx |
so close.. :) WebSocket connection to blah failed: WebSocket opening handshake was canceled Uncaught Error: WebSocket Error [object Event] : undefined socket.onerror closing websocket |
| 16:36 |
* phasefx |
goes poking at opensrf_ws.js, see if he can get a better error |
| 16:43 |
berick |
phasefx: testing in chrome? |
| 16:43 |
phasefx |
berick: yes, chrome and chromium |
| 16:44 |
phasefx |
happens in firefox as well |
| 16:44 |
berick |
what happens if you go to https://hostname:7682 |
| 16:59 |
eeevil |
we can squash/reorder/etc later, I figure |
| 17:01 |
jeff |
togetherness! |
| 17:01 |
* jeff |
grins |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:15 |
|
mrpeters left #evergreen |
| 17:44 |
|
nhilton joined #evergreen |
| 01:28 |
|
phasefx__ joined #evergreen |
| 01:28 |
|
Callender_ joined #evergreen |
| 01:40 |
|
dkyle joined #evergreen |
| 05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:15 |
|
wsmoak joined #evergreen |
| 05:54 |
|
wsmoak joined #evergreen |
| 06:28 |
|
phasefx joined #evergreen |
| 10:14 |
bshum |
I think it's missing. |
| 10:17 |
Dyrcona |
Looks like it is missing, but I seem to recall something else possibly depending on it. |
| 10:18 |
Dyrcona |
I could be mistaken, but even if I'm not, it won't hurt to make sure it is installed. |
| 10:19 |
bshum |
You're probably right, I don't know how else I could have tested or used the new marc_export previously otherwise |
| 10:19 |
bshum |
Maybe something changed when we moved to the modularized makefiles per distro |
| 10:19 |
Dyrcona |
I wonder if it was in there and got axed by a jumbled/out of sync commit? |
| 10:20 |
bshum |
Hmm, maybe. |
| 10:20 |
Dyrcona |
Well, I recall something else being missed when that happened. |
| 10:41 |
jeff |
*nod* |
| 10:47 |
Dyrcona |
Looks like the dependency was just plain missed. |
| 10:48 |
Dyrcona |
I don't see it in my working branch. |
| 10:51 |
bshum |
Maybe it got lost when we changed working branches from Marque.pm |
| 10:51 |
bshum |
Oh well. |
| 10:52 |
bshum |
Dyrcona++ # I'll test it later this weekend |
| 14:41 |
dbs |
Dyrcona: dang. sounds like something we should fix; a web app that can't handle requests for web pages isn't very useful :/ |
| 14:41 |
* dbs |
wonders if it's the same "extremely broad searches cause a cascading database denial of service" issue that we faced a while back |
| 14:52 |
Dyrcona |
Dunno. We recently changed some O/S settings after a crash. |
| 14:53 |
Dyrcona |
Might be related, might not be. |
| 15:18 |
|
sandbergja joined #evergreen |
| 16:37 |
|
StephenGWills joined #evergreen |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:09 |
jeff |
dbs: what are your thoughts on search engine indexing of searches in general (say, from external links to search results) and things like subject/facet/related searches? |
| 17:11 |
jeff |
dbs: with sitemaps being a path toward indexing of the records without searches, is it useful/important to index the search result pages themselves? |
| 18:53 |
|
StephenGWills left #evergreen |
| 01:32 |
* bshum |
sighs |
| 01:44 |
bshum |
@later tell dbs I put some thoughts on the bug in reply, but I think we should forward port 2.6.2-2.6.3 to rel_2_7. Master already has it, so the question is changing the assumption that you can upgrade at any point along the 2.6 to 2.7.0, but actually it needs to be 2.6.3-2.7.0 (exactly) |
| 01:44 |
pinesol_green |
bshum: The operation succeeded. |
| 01:45 |
bshum |
Not sure if that's better or worse actually.... version upgrades are such a mess. I'm sorry that I couldn't test it more thoroughly myself. Not being on any particular version is a downside to my own personal testing efforts of these scripts :( |
| 01:46 |
bshum |
dbs++ # actually getting 2.7 tested :) |
| 01:54 |
bshum |
I also updated bug status on bug 800478 (that's 0890) and bug 1189556 (that's 0891) |
| 01:54 |
pinesol_green |
Launchpad bug 800478 in Evergreen "Acquisitions - Funds transfer always transfers entire fund, not specified amount" (affected: 5, heat: 34) [Medium,Confirmed] https://launchpad.net/bugs/800478 |
| 01:54 |
pinesol_green |
Launchpad bug 1189556 in Evergreen "Typo: 'Allows a user to process and verify ULSs'" (affected: 1, heat: 6) [Low,Confirmed] https://launchpad.net/bugs/1189556 |
| 01:54 |
bshum |
We'll have to fix those as well to figure out how to incorporate those upgrade script fixes in the 2.7 series. |
| 01:55 |
bshum |
dbs++ # seriously bummed that 2.7.0's upgrade script is wonky :( |
| 01:55 |
bshum |
bshum-- |
| 01:55 |
bshum |
Oh well. Something to ponder more today while avoiding the snow... |
| 05:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:31 |
paxed |
dbs: i'm going to steal some parts of your intro-to-git - i got tasked to teach git at work ... |
| 05:47 |
|
wsmoak joined #evergreen |
| 06:28 |
|
eeevil joined #evergreen |
| 11:40 |
Dyrcona |
csharp: You got that file from OCLC, or you exported it from Evergreen? |
| 11:41 |
csharp |
exported from Evergreen |
| 11:41 |
Dyrcona |
Never seen those particular errors from an Evergreen export before. |
| 11:41 |
csharp |
and that particular file has already been processed - I was using it as a test case for my perl script |
| 11:41 |
* csharp |
tries another |
| 11:42 |
Dyrcona |
I often have charset conversion errors when they want MARC8 and records with empty fields because of it. |
| 11:42 |
Dyrcona |
I'd ask OCLC if they'd accept MARC21XML. :) |
| 11:43 |
csharp |
maybe I can try MARC::Charset->ignore_errors() |
| 11:43 |
csharp |
ok |
| 11:44 |
Dyrcona |
csharp: All the vendors do. Our tools work. Why should we change them? |
| 11:44 |
bshum |
eeevil++ # fun reading indeed :) |
| 11:44 |
csharp |
well, since my script is theoretically sound, and the files I'm testing with have known issues, I'll try a new export and test on it. |
| 11:44 |
csharp |
Dyrcona: thanks for being a sounding board |
| 11:45 |
csharp |
bshum: after the holiday, I'd love to compare notes with you on the Dell DBs |
| 11:45 |
Dyrcona |
csharp: You might have low ascii in some of your fields. |
| 11:45 |
bshum |
csharp: For sure! I think things have gone much better since we reformatted them (again) and made all the changes to the configs. |
| 11:46 |
Dyrcona |
It's not supposed to be there, but old data could have it. |
| 15:11 |
berick |
hm, right, user.js would need to live in the egCoreMod in that case (instead of egUserMod) |
| 15:27 |
|
artunit_ joined #evergreen |
| 15:51 |
|
Dyrcona joined #evergreen |
| 16:38 |
pinesol_green |
[evergreen|Lynn Floyd] Docs: Update to template receipt docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3c40129> |
| 16:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:01 |
|
mmorgan left #evergreen |
| 17:39 |
|
artunit joined #evergreen |
| 18:52 |
|
dcook joined #evergreen |
| 05:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:51 |
|
wsmoak joined #evergreen |
| 05:51 |
|
wsmoak joined #evergreen |
| 06:31 |
|
mtate joined #evergreen |
| 10:43 |
jeff |
(because those do set physical_loc) |
| 10:43 |
Dyrcona |
jeff: Ok. I thought it might be to stop it loading in the library after I asked my question. |
| 10:43 |
|
krvmga joined #evergreen |
| 10:44 |
kmlussier |
eeevil: I was just testing out the code you added for https://bugs.launchpad.net/evergreen/+bug/1367926. |
| 10:44 |
pinesol_green |
Launchpad bug 1367926 in Evergreen "Add support for (nearly) direct access to the full unapi backend" (affected: 1, heat: 6) [Wishlist,New] |
| 10:44 |
kmlussier |
Using the example from your git branch, going to http://mlnc2.mvlcstaff.org/opac/extras/unapi?id=tag::U2@acp/CONC40000537{acn,bre,mra}/-/0/barcode&format=xml seems to work well. |
| 10:45 |
krvmga |
Under what circumstances might a staff client stay logged in, even if the PC is shut down? I had this question and I think the answer is "under no circumstances" but I want to be sure. |
| 13:41 |
dbs |
Ah, ye olde "ERROR: could not find trigger 5235330" at commit time. WUT? |
| 13:42 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/1261355 |
| 13:42 |
pinesol_green |
Launchpad bug 1261355 in Evergreen 2.6 "2.4.3-2.5.0-upgrade-db.sql causing "could not find trigger" PostgreSQL error" (affected: 3, heat: 14) [Undecided,Fix released] |
| 13:47 |
csharp |
dbs: in my case, I had to comment out one of the sub-scripts that were apparently colliding and ran it separately - I didn't actually test the patch once I figured out my own hack |
| 13:47 |
csharp |
so csharp-- for not following up :-/ |
| 13:50 |
csharp |
so, I thought I would just throw this out there, to see if anyone is seeing a similar issue... |
| 13:50 |
csharp |
we're getting sporadic reports from libraries (some, but not all) where the staff client white screens when doing patron updates |
| 13:51 |
csharp |
and they get a Windows message that xulrunner has stopped responding |
| 13:51 |
dbs |
csharp: thanks; trying again to see what happens :0 |
| 13:51 |
dbs |
csharp: ugh. not a memory bloat thing? |
| 13:52 |
csharp |
dbs: apparently not. terran and I saw it happen and were able to see the Windows Task Manager at the time |
| 14:45 |
|
ericar joined #evergreen |
| 14:56 |
|
akilsdonk_ joined #evergreen |
| 15:03 |
|
krvmga joined #evergreen |
| 15:07 |
jboyer-isl |
A completely different question: Can anyone tell me when openils_dojo.js is created? I can see where it's defined (openils.profile.js) but not where it's built. |
| 15:07 |
jboyer-isl |
And of course, it doesn't exist on my test server. |
| 15:09 |
gsams |
question for the masses, supposing I'm not interrupting something, I'd like for fine alerts on renewals to only prompt once for the threshold. Is this possible? |
| 15:09 |
gsams |
currently the alert pops up for each item, and when you are talking about 50+ items it can really slow things down. |
| 15:10 |
|
dreuther_ joined #evergreen |
| 15:20 |
Dyrcona |
bshum: If it was minified away, I think the templates, etc. that refer to it should be updated, don't you? |
| 15:20 |
pinesol_green |
Launchpad bug 1076582 in Evergreen "Documentation explaining openils_dojo.js" (affected: 1, heat: 8) [Low,Confirmed] |
| 15:20 |
bshum |
"Secret sauce" |
| 15:20 |
kmlussier |
jihpringle: the patch for bug 1380709 is on mlnc3.mvlcstaff.org whenever you have time to test it. |
| 15:20 |
pinesol_green |
Launchpad bug 1380709 in Evergreen 2.6 "invoice print amounts-per-fund uses wrong value when item price varies" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1380709 |
| 15:20 |
bshum |
It's used in building custom dojo builds |
| 15:20 |
bshum |
We reference it, but it's not built unless you follow those scratchpad notes |
| 15:28 |
bshum |
Good times... |
| 15:29 |
csharp |
jboyer-isl: thanks - sounds like we have the same issue |
| 15:29 |
bshum |
jboyer-isl++ |
| 15:36 |
jihpringle |
kmlussier: thanks, I'll test that patch later today :) |
| 15:49 |
jboyer-isl |
csharp, One more data point, I'm not certain what version PINES is on, but we've been seeing this on 2.5(.2) I can't remember if we were running into it on 2.2. |
| 15:58 |
csharp |
jboyer-isl: yep - we're on 2.5.1+ (which is probably pretty close to 2.5.2 |
| 15:58 |
csharp |
) |
| 16:06 |
dbwells |
If you install from a git checkout, you don't have it. |
| 16:06 |
dbwells |
It isn't actually tied into the install process. |
| 16:07 |
dbwells |
As you noticed it doesn't cause any errors if it isn't there, as Dojo just falls back to the separate file requests. |
| 16:07 |
jboyer-isl |
bshum, dbwells: sorry, I meant I think csharp's issue with the client hogging a core and dying is related to the last time we changed xulrunner. Since my test server builds out of git repos I understand why I don't have those dojo files now. :) |
| 16:08 |
bshum |
Ah, my bad too then. |
| 16:09 |
jboyer-isl |
(I'm working on building them as we speak, however, because I hate 404's and love speed. :) ) |
| 16:10 |
dbwells |
jboyer-isl: If you have any issues with the build, you can also just grab the one we throw in the releases from here: http://evergreen-ils.org/downloads/dojo.tgz |
| 08:51 |
|
jwoodard joined #evergreen |
| 08:52 |
mrpeters |
dbwells++ thank you for the great info last night. so, we have retrieve_all, search_, are there others? any documentation on this I can read? |
| 09:11 |
dbwells |
mrpeters: I'm not sure if there is any thorough documentation for that. A few bits and pieces exist in various tutorials, mostly the work of dbs. |
| 09:12 |
mrpeters |
10-4 yeah, he has lots of great stuff for opensrf |
| 09:12 |
mrpeters |
i think i have this working, about to fire up and test |
| 09:12 |
mrpeters |
i was missing declaring my $auth along with $ident_type |
| 09:13 |
dbwells |
mrpeters: The usual CRUD (create/retrieve/update/delete) commands are all available, as well as search, batch_retrieve, and retrieve_all. |
| 09:13 |
mrpeters |
ok, very cool |
| 09:13 |
mrpeters |
well crap, no dice on the alpha sort |
| 09:57 |
tsbere |
csharp: That sounds about right, but I am not looking at that part of the system right now ;) |
| 09:58 |
mrpeters |
is your concern that it would sort the group headings too, because of the way the tree gets built? |
| 09:58 |
csharp |
tsbere: understood - thanks! |
| 10:00 |
tsbere |
mrpeters: Gimme a sec to test something quick. |
| 10:01 |
tsbere |
mrpeters: Yea, a standard sort kindof ignores the "tree" part of things... |
| 10:02 |
mrpeters |
ok, i think phasefx mentioned that in the bug as a possible side effect |
| 10:03 |
mrpeters |
your sort_ident_type branch works perfect, signoff forthcoming |
| 10:03 |
* bshum |
just realized that once alpha sort for ident_type goes in, he will no longer have "Yes" (id 1) before "No" (id 2) in his patron registration. |
| 12:22 |
mrpeters |
so the error message is even less helpful in current master |
| 12:23 |
mrpeters |
im at http://pastie.org/9732735 now -- which is good, i know my window.alert will work, i just need to move it to a proper location since it shows up on a valid, and invalid au.id right now |
| 12:30 |
tsbere |
mrpeters: What interface are we aiming to return to? |
| 12:30 |
Stompro |
mrpeters: Bug 1124498 - I have this almost tested after adding in the repeat delay bit. An event is generated but stays in collected state, just need to figure out how to get it to move on from there. |
| 12:30 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 4, heat: 30) [Wishlist,In progress] https://launchpad.net/bugs/1124498 - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 12:31 |
tsbere |
mrpeters: I will point out that the "interface" you seem to want (prompt for another ID) isn't actually an "interface" at all... |
| 12:31 |
mrpeters |
tsbere: it is the "Search" > "Retreieve patron by Database ID" |
| 12:36 |
mrpeters |
so wouldnt it be acceptable to bounce you to a window.alert and the portal page for the entry point? |
| 12:36 |
mrpeters |
if invalid |
| 12:36 |
tsbere |
mrpeters: I could argue "send them to patron search instead" but the amount of work to re-make the prompt isn't worth it. :P |
| 12:37 |
mrpeters |
yeah, that would be a fair redirect too. from the way the code looks, i think this might have just been a quick add for someone who was testing something |
| 12:37 |
tsbere |
mrpeters: Basically, "send them to something else, with that something else being uniform across the board" would be fairly easy. Making it know how you got there and sending you back, including to a prompt that isn't even a page, not so much. |
| 12:38 |
tsbere |
mrpeters: Note that the functionality exists (beyond the menu item) for things like "load patron from the hold/circ/whatever" type menus. So whatever is changed needs to take those into account as well, so you can't just make it always prompt for a new ID (or barcode). |
| 12:39 |
tsbere |
Which is why it goes to the main barcode entry box, I think. >_> The menu item causing it to do that is just pre-existing functionality triggering on bad inputs. |
| 13:00 |
Stompro |
kmlussier++ for pointing out the google doc that mmorgan++ created on getting the 30 day pre expire notice working. The Processing Group Context Field needs to be blank, not set to usr. |
| 13:02 |
mrpeters |
oh, nice you guys were able to create that? |
| 13:03 |
mrpeters |
and keep it recurring? |
| 13:07 |
mmorgan |
Stompro: Glad the notes helped! |
| 13:07 |
mmorgan |
we have not yet implemented it, but it worked in testing |
| 13:08 |
mmorgan |
assuming the recurrence will work based upon the interval that now be set in the action trigger. |
| 13:10 |
kmlussier |
mmorgan: What did you set the interval at? I know Stompro asked a question back on what a good interval would be, and I suggested 30 days. |
| 13:10 |
kmlussier |
s/back/a while back |
| 13:13 |
mmorgan |
so I guess that's actually "Event Repeatabilty Delay"? |
| 15:37 |
dbwells |
mrpeters: Thanks for letting me know. I figured you were trying to learn, so I was avoiding looking too deeply into the code. Glad it got worked out. |
| 15:37 |
mrpeters |
i indeed was, i wish i could have figured it out but tsbere saw a faster way and went on and fixed it |
| 15:38 |
mrpeters |
was a good lesson all the way down through the code clear to CDBI perl stuff though |
| 15:38 |
tsbere |
Had I not stumbled on the easy, quick, and correct solution and basically put the right code in place to test if the solution would even work I would have left it more to mrpeters ;) |
| 15:38 |
dbwells |
jboyer-isl: sitem to sunit is one-to-many |
| 15:38 |
mrpeters |
i think your suggestion would have worked for, say a srfsh request of the values |
| 15:38 |
mrpeters |
but i guess that tree unsorts things |
| 17:00 |
mrpeters |
thank you, sincerely, tsbere |
| 17:01 |
tsbere |
mrpeters: (bool op) ? do this if true : do this if false |
| 17:01 |
mrpeters |
got it |
| 17:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:46 |
mrpeters |
great success! high five! tsbere++ berick++ |
| 17:46 |
mrpeters |
will push dee848f HEAD@{0}: commit: Make users_of_interest test for defined actor.usr.card values to working once my SSH keys are updated |
| 18:05 |
|
mnsri joined #evergreen |
| 18:11 |
|
nhilton joined #evergreen |
| 18:13 |
|
dreuther_ joined #evergreen |
| 01:38 |
|
letsgofightdrag1 joined #evergreen |
| 01:54 |
|
letsgofightdrag1 joined #evergreen |
| 02:21 |
|
letsgofightdrag2 joined #evergreen |
| 05:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:34 |
|
wsmoak joined #evergreen |
| 06:34 |
|
wsmoak joined #evergreen |
| 06:35 |
|
eeevil joined #evergreen |
| 11:06 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 4, heat: 30) [Wishlist,In progress] - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 11:23 |
tsbere |
mrpeters: So, I can stop all but the commonStrings ones (usually), but I at least know what causes them! |
| 11:25 |
tsbere |
mrpeters: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/stop_before_remove stops most of the popups. The last of them appears to be caused by the onunload handlers in the pages or subpages due to them trying to run before the page actually finished loading. |
| 11:46 |
mrpeters |
oh man, nice |
| 11:47 |
mrpeters |
ill test and sign-off then, thanks |
| 11:52 |
mrpeters |
was also looking at 506689 -- but should probably see if the behavior exists in the web client too -- would anyone be willing to insert a non-stock config.ident_type value to one of the web client test servers (Bill - Utility Company), perhaps to test the sort order outside of License, SSN, and Other? |
| 11:52 |
mrpeters |
bug 506689 that is |
| 11:52 |
pinesol_green |
Launchpad bug 506689 in Evergreen "Patrons > Identification Type > (Sort order)" (affected: 1, heat: 8) [Wishlist,Confirmed] https://launchpad.net/bugs/506689 |
| 12:00 |
|
sandbergja joined #evergreen |
| 12:13 |
* tsbere |
is amazed at finding patrons with a "last circ month" in 1992 in the system |
| 13:00 |
dbwells |
Seems like I've been on a bad run lately, so nice to get something working :) |
| 13:33 |
kmlussier |
dbwells: A bad run? I just figured that was the nature of coding. |
| 13:35 |
RoganH |
The fickle finger of fate foretells fortune foul and fair for all. |
| 13:41 |
jboyer-isl |
mmorgan, are you about? I've got a couple questions about your test results re: bug 1210541 |
| 13:41 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 13:43 |
jboyer-isl |
Alas. I'll look into them when I have time to put a good test together. :) |
| 13:43 |
kmlussier |
jboyer-isl: She's around, but away from her desk at the moment. |
| 13:45 |
jboyer-isl |
ok. |
| 13:46 |
mmorgan |
jboyer-isl: be back in a few minutes ... |
| 14:02 |
gsams |
jboyer-isl: In the system I'm seeing max_delay (evergreen staff client call it Max Event Validity Delay. |
| 14:03 |
gsams |
I'm not seeing a minimum, but if it acts as a minimum wait time that would be an appropriate change in my mind. |
| 14:03 |
mmorgan |
jboyer-isl: The deleted locations still appeared in the interfaces where groups and order could be configured. |
| 14:04 |
jboyer-isl |
mmorgan, Ah, ok. Bummer. Back to my testing then. |
| 14:04 |
jboyer-isl |
Thanks! |
| 14:04 |
jboyer-isl |
mmorgan++ |
| 14:04 |
tsbere |
gsams: I would pick something like 12 hours or so. Or 1 hour more than however long from midnight your a/t runners pick up on the events to go out. |
| 14:04 |
mmorgan |
No, thank YOU! |
| 14:04 |
tsbere |
er, 1 hour less |
| 14:46 |
|
_bott_1 joined #evergreen |
| 14:48 |
|
_bott_1 joined #evergreen |
| 15:25 |
mrpeters |
in register_table.tt2 I'm seeing lots of references to fmclass and fmfield -- I'm taking a leap, and assuming those refer to the fm_IDL.xml, correct? |
| 15:34 |
kmlussier |
Doh. I suppose using an LC classification scheme would make it easier to test this LC Call number fix. |
| 15:38 |
|
vlewis_ joined #evergreen |
| 15:47 |
jeff |
mrpeters: *nod* |
| 15:47 |
jeff |
mrpeters: what brings you into the user editor? |
| 16:10 |
mrpeters |
i think, from retrieve_all_config_identification_type, which i beleive is loaded into memory when you login to the staff client |
| 16:12 |
mrpeters |
and now i'm looking at Storage/CDBI/ stuff which is scaring me :P i think i'm going to dig a hole to china! |
| 16:14 |
mrpeters |
http://pastie.org/9730906 feels like the end of the line... |
| 16:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:55 |
|
akilsdonk joined #evergreen |
| 16:56 |
|
mdriscoll left #evergreen |
| 16:59 |
|
nhilton joined #evergreen |
| 09:21 |
pinesol_green |
csharp: The operation succeeded. Quote #98 added. |
| 09:22 |
jboyer-isl |
mmorgan, just wanted to let you know I haven't been ignoring your update to bug 1210541, but I've not had time to investigate/reply. |
| 09:22 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 09:23 |
jboyer-isl |
mmorgan++ # for testing it |
| 09:23 |
mmorgan |
jboyer-isl: no problem! I am thrilled to see progress on it! |
| 09:24 |
kmlussier |
jboyer-isl++ mmorgan++ |
| 09:24 |
Dyrcona |
If you search the logs you'll find some brief discussion of how we at MVLC solved some of our issues by increasing the limit on the number of files that our opensrf user can have. |
| 09:39 |
jeff |
> Donna appears to say that she is aware of this problem but has found a dishwasher in the White House kitchen that speaks Botok. Mr. Minaldi speaks Portuguese and so does the dishwasher. So Josh and Toby will be able to converse with Mr. Bambang via English-Portuguese-Botok-Portuguese-English. |
| 09:40 |
bshum |
jeff: That was a good episode. :P |
| 09:40 |
|
mllewellyn joined #evergreen |
| 09:40 |
jeff |
This is the scene from The West Wing that went through my mind this morning as I was describing to a co-worker how I was successful last night in initial testing with getting an outside vendor to verify patrons in our Evergreen system by emulating the III Patron API. |
| 09:42 |
bshum |
Yeah, that sounds about right. |
| 09:48 |
jeff |
There was a moment the other day where I thought the "Why don't we just speak in English" would have been more appropriate, but no. |
| 09:51 |
csharp |
The_West_Wing++ |
| 10:36 |
jeff |
But I think the long term goal would still be to use technologies that are better with regard to being 1) less niche, 2) better experience for patrons and 3) not gaping privacy/security holes |
| 10:37 |
kmlussier |
Dyrcona: Do you still have the fine generator running overnight on your dev server? |
| 10:37 |
Dyrcona |
It should be. |
| 10:37 |
kmlussier |
Dyrcona: OK, I just wanted to check before I got to far in my testing. Thanks! :) |
| 10:37 |
jeff |
the "other things" for the current reality would include divorcing SIP2 credentials from ILS credentials, giving the ability to filter or limit SIP messages and their responses -- essentially a field-level fine-grained control over what a given SIP client can see and do. |
| 10:37 |
kmlussier |
s/to/too |
| 10:38 |
jeff |
that second bit could either be in SIPServer (with or without need for driver support -- probably depending on where you wanted to do your config) or via a SIP proxy, which would be a bit more complex but have wider benefit to those not running SIPServer |
| 11:07 |
Bmagic |
mmorgan: yes..... |
| 11:08 |
bshum |
Bmagic: The thing that bothers me right now is that when I install a fresh Evergreen master / OpenSRF master, I don't see this bug. So it seems sporadic somehow. |
| 11:08 |
bshum |
Meaning not production data, using concerto or whatnot |
| 11:08 |
mmorgan |
we were testing some code and had made changes to the fm_idl. |
| 11:08 |
kmlussier |
Odd, I just tried the Fast Item Add from the MARC editor and had no problems. |
| 11:08 |
mmorgan |
then we could not save changes to items. We reverted the idl and it fixed the problem. |
| 11:08 |
Bmagic |
kmlussier: are you on 2.7+ ? and OpenSRF 2.4+ ? |
| 11:22 |
jeff |
bshum: wait until it's likely everyone's restarted their staff clients. :-) |
| 11:22 |
bshum |
mllewellyn will definitely be happier ;) |
| 11:22 |
bshum |
jeff: Gah, you're right |
| 11:23 |
* kmlussier |
returns to negative balance testing but thanks Bmagic for the distraction. :) |
| 11:23 |
Bmagic |
The stock js files have the path to the server with the generic /server/ and autogen replaces that with whatever you compled with right? |
| 11:23 |
* bshum |
will wait for the weekend then. |
| 11:23 |
mllewellyn |
mllewellyn will be much happier |
| 09:13 |
mrpeters |
how are you going to fix something you break if you aren't able to do a scratch install, you know? |
| 09:13 |
Stompro |
I hate editing the xml files... the fact that sometimes it's <password> and sometimes its <passwd>. And dealing with all the ejabberd accounts. |
| 09:14 |
mrpeters |
for me, personally, the solution to the time consuming bit is using VMWare (though Virtualbox would work fine too) and using snapshots |
| 09:14 |
RoganH |
I was trying to point out tools that can help with blasting and rebuilding a test build of Evergreen, not saying that they void the need to have the underlying skills. |
| 09:14 |
wsmoak |
:::shrug::: I don’t really want to fix bugs. I want to play with it and write against the api and see how it all works and *then* maybe get more involved. |
| 09:15 |
mrpeters |
no, I agree with you RoganH. Once you can perform the install once, no need to repeat it over and over again (though, it does become like muscle memory to install Evergreen eventually haha) |
| 09:15 |
RoganH |
using Virtual Box snapshots can work most of the time as well though I'd argue sometimes it's good to just be able to do a quick new build from git |
| 09:21 |
wsmoak |
… but that leans a lot on Java’s built-in stuff I know, with the ability to swap out data sources easily |
| 09:21 |
RoganH |
If you're running OSX virtual box is your friend. |
| 09:21 |
mrpeters |
heck yeah it is |
| 09:21 |
csharp |
wsmoak: we do have a test dataset (not automatically installed by the .deb package, fwiw) |
| 09:21 |
RoganH |
You can pay for VMWare (I used to) but Virtual Box has gotten so good in the last few years. |
| 09:22 |
mrpeters |
when i was at ISL my "master" server for submitting new patches, development, etc. was just a virtualbox VM on their OS X server |
| 09:22 |
mrpeters |
csharp: we could make the test data load SO easy. There is a flag now for eg_db_config to load all of that |
| 09:22 |
mrpeters |
i discovered it monday |
| 09:23 |
mrpeters |
--load_all_test or something |
| 09:23 |
mrpeters |
we could add that to our debs pretty easily i think |
| 09:23 |
csharp |
yep |
| 09:24 |
mrpeters |
maybe have it set up so you can do an apt-get install evergreen-ils and apt-get install evergreen-ils-populateddb |
| 09:24 |
csharp |
I wonder if it should be a separate deb, though |
| 10:00 |
jboyer-isl |
mrpeters, Probably a URI if you want to be picky, I can never remember the difference |
| 10:00 |
mrpeters |
heh yeah |
| 10:03 |
Stompro |
Does anyone have a "New Patron Welcome Email" notice that they use? We currently try to email a new customer right away, so that if their email is bad the staff have a chance to fix it while the customer might still be in the building. I just need to figure out if that is possible with action triggers. |
| 10:04 |
mrpeters |
so, if gpls were to host a deb of the current "stable" release with and without test data would the community advertise that as a "quick start" or would that still meet resistance because it doesn't account for installing the software, and could **potentially** cause someone to accidentally upgrade the package when they didn't intend to |
| 10:06 |
Stompro |
mrpeters: I'm pretty new, but I would support that and I would help add it to the community install docs. |
| 10:06 |
kmlussier |
berick++ |
| 10:07 |
Stompro |
mrpeters: would it be Ubuntu only or could Wheezy and Jessie users make use of it? |
| 10:08 |
mrpeters |
we would have to build seperate debs for those, i think |
| 10:08 |
mrpeters |
debian has some slightly different install steps |
| 10:08 |
bshum |
mrpeters: I think that's an interesting offer. Though I'm always curious to see the deb building process you guys have come up with in action. |
| 10:08 |
mrpeters |
I could make a demo video |
| 10:09 |
mrpeters |
i just hate hearing my own voice narrate it....and today is NOT the day to do that....60 degrees to 22 degrees in 12 hours did not help my throat |
| 10:11 |
mrpeters |
there is a little work done (Andy Witter usually handles it) to build any new debs for things that would normally get installed from source (spidermonkey, etc.) but if those don't change much from version to version, its really just grab the tarball and put it in a certain location and then run a script |
| 10:11 |
mrpeters |
you can pick "cluster" or "single server" |
| 10:11 |
mrpeters |
for the repo, its single server |
| 10:12 |
mrpeters |
only half of that I don't have a lot of knowledge on yet is the actual apt archive |
| 10:12 |
mrpeters |
not sure where Andy sticks the built debs up to update the repo |
| 10:13 |
mrpeters |
i just tell him hey, i built the 2.7.1a debs can you update the repo and link him my deb |
| 10:14 |
mrpeters |
one thing that would be cool, and im not sure if it could be done, is to have ALL of the old debs still there too, so you could do say, apt-get install evergreen-ils-2.0.4 and get the 2.0.4 build installed |
| 10:14 |
mrpeters |
wouldn't see many reasons to do that, other than nostalgia or testing "did this act differently before?" but could be handy |
| 10:17 |
bshum |
With deb files, wouldn't the version be part of the package name though? |
| 10:17 |
bshum |
Usually |
| 10:18 |
mrpeters |
yeah, i think traditionally it is |
| 12:43 |
tsbere |
kmlussier: I would argue then that the setting is horribly mis-named, then, because it isn't acting like a copy. |
| 12:44 |
* kmlussier |
notes that all of the examples in the docs at http://docs.evergreen-ils.org/2.7/_cataloging_electronic_resources_8201_8212_8201_finding_them_in_catalog_searches.html#_adding_a_located_uri_to_the_record were working as described back in the summer. |
| 12:44 |
jeff |
are they no longer working as described? |
| 12:44 |
kmlussier |
tsbere: If the subfield 9 is set to the consortium without the setting enabled, then it will show up in searches all the way down the org tree. But if it's set at a system or branch level, it only travels down, not up. |
| 12:45 |
kmlussier |
jeff: I believe they are. I haven't tested it since then. |
| 12:45 |
kmlussier |
tsbere: If you enable the setting, then the resource shows up both up and down the org tree. So if it's owned by a system and you search the consortium, it still shows up. Like copies do. |
| 12:45 |
tsbere |
kmlussier: As far as I know, copies only travel "up", not "down", so if the setting makes them travel *both* ways then URIs aren't acting as copies. |
| 12:46 |
tsbere |
kmlussier: Which would make the setting's name horribly wrong. :P |
| 12:46 |
kmlussier |
tsbere: If your search is scoped to the consortium, you don't see copies owned by a branch? |
| 12:52 |
tsbere |
jeff: I seem to recall it only shows up when scoped to the top of the tree. |
| 12:52 |
* tsbere |
has done stuff like that before |
| 12:54 |
kmlussier |
I guess the specific name of the settings was used to show how enabling it differs from default behavior. The default behavior is what makes the electronic resource show up in searches higher up the org tree. Enabling the settings is what allows it to travel down, as copies do. |
| 12:56 |
tsbere |
kmlussier: My (current) point being that the name and description *don't match what it does* - Copies by default travel "up" the tree, URIs by default travel "down" the tree, that option tells URIs to travel "up AND down" the tree. That is not acting like copies. That is acting like a combination of copies and URIs at the same time. |
| 12:58 |
* tsbere |
is assuming that kmlussier's assertion about things is true, BTW, and has not tested or dug the actual code up at this point |
| 13:00 |
dbwells |
I agree with tsbere that the setting doesn't really do what it claims. Anyone interested in all the various cans of worms should check out ldw's bug #1353643. I suspect the fallout from that will clarify the original setting as well. |
| 13:00 |
pinesol_green |
Launchpad bug 1353643 in Evergreen "URI $9 displayes too many links in TPAC" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1353643 |
| 13:05 |
* eeevil |
is running to a doctor's appointment (already late) but the setting is to make URIs act like copies /in that/ they scope "down". it doesn't remove the "up" scoping, though. electronic resource limiting is about modeling access rights, where the uri owner (and it's subordinates) should have access |
| 14:24 |
kmlussier |
bug 1171984 |
| 14:24 |
pinesol_green |
Launchpad bug 1171984 in Evergreen "add support in Vandelay for overlaying authorities during import using match sets" (affected: 4, heat: 18) [Wishlist,Triaged] https://launchpad.net/bugs/1171984 - Assigned to Liam Whalen (whalen-ld) |
| 14:24 |
kakes |
kmlussier: who do you think is working on the overlay? |
| 14:25 |
kmlussier |
Are there still issues for the LC Call number group once dbwells's code is tested and merged? |
| 14:25 |
Stompro |
gmcharlt: Thanks for reviewing and committing the KPAC setup docs. gmcharlt++ |
| 14:25 |
kmlussier |
Sorry, that's the next agenda item. I withdraw the question. |
| 14:25 |
dbs |
#info dbs = Dan Scott, Laurentian University (with coffee in hand, finally) |
| 14:32 |
yboston |
yes |
| 14:32 |
yboston |
I finally put in a bug for issues searching LC calnumbers in OPAC numeric searches; bug 1389403 |
| 14:32 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:32 |
yboston |
I then added a link inside the bug to some test code that Dan Wells wrote to address the issue. I saw that Kathy tried testing that code during the EG bug squashing day. |
| 14:32 |
yboston |
I still need to query the community to see what other LC call number issues need to be addressed |
| 14:33 |
kmlussier |
I still owe a response to dbwells regarding what we're seeing in the logs. |
| 14:33 |
yboston |
and I made a basic wiki page for this group too |
| 14:33 |
kmlussier |
I think I sent out a query to the Evergreen community. |
| 14:36 |
pinesol_green |
Launchpad bug 1352542 in Evergreen "Printing: LC Call number formatting (2.5.2)" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1352542 |
| 14:37 |
dbs |
dbwells: are we normalizing the incoming call number label? /me isn't seeing that immediately in supercat |
| 14:38 |
remingtron |
dbwells is in a meeting at the moment |
| 14:38 |
yboston |
since we have one definite open bug, and one bug that has a fix awaiting more testing, we can keep the group open for now |
| 14:38 |
kmlussier |
DonB: Since you semi-volunteered up above, is this something you want to work through. At this time, I'm thinking it's primarily about identifying specific issues that are still out there. |
| 14:39 |
yboston |
I am sure there are other bugs I could report if I talk to the cataloger here, though she is on maternity leave right now |
| 14:39 |
* dbs |
sees that that's what the patch from dbwells is trying to do; seems reasonable |
| 14:42 |
pinesol_green |
[evergreen|alzr] LP#1207529: Add /openils assumption note - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e38ec30> |
| 14:42 |
yboston |
you being Kathy |
| 14:42 |
yboston |
we were all new like you once |
| 14:43 |
kmlussier |
#action kmlussier to post testing feedback for dbwells on bug 1389403 |
| 14:43 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:43 |
kmlussier |
Got it. |
| 14:43 |
kmlussier |
Those are all the sub-groups then. |
| 16:01 |
dbs |
jihpringle: cool, thanks -- that's a pretty impressive set |
| 16:06 |
|
jwoodard joined #evergreen |
| 16:33 |
|
mdriscoll left #evergreen |
| 17:05 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
|
mmorgan left #evergreen |
| 17:20 |
|
buzzy joined #evergreen |
| 18:01 |
|
kmlussier joined #evergreen |
