11:08 |
|
akilsdonk_ joined #evergreen |
11:08 |
* rfrasur |
goes to delegate. |
11:11 |
RoganH |
If interest is high enough based on the doodle poll I might do two dates. |
11:16 |
csharp |
okay, so since open-ils.storage.asset.copy.circ_count pulls more than just a raw count from the circ table, I've fixed it (on my test machine) to use action.all_circulation... so now the issue is probably to recreate a new method for grabbing the circ count from extend_reporter.full_circ_count and use that in place of open-ils.storage.asset.copy.circ_count ;-) |
11:17 |
csharp |
s/recreate/create/ |
11:17 |
csharp |
I'll update the bug with what I've done and we can continue the discussion there |
11:21 |
bshum |
Huh, why would uploading offline transactions fail on "PERM_FAILURE" where almost all of them list out as needing "CIRC_PERMIT_OVERRIDE" |
11:21 |
rfrasur |
RoganH++ |
11:22 |
bshum |
I looked at the patron and items and they don't seem to require any override |
14:34 |
jeff_ |
these libraries use these vendors with {Evergreen|Koha} |
14:34 |
jeff_ |
etc |
14:35 |
csharp |
@hates |
14:35 |
pinesol_green |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; and reports more |
14:35 |
rfrasur |
ooooo....base filters! |
14:35 |
Dyrcona |
jeff_: EBSCO EDS. It appears to be aimed at academic libraries but one of our publics has signed up for it. |
14:37 |
csharp |
Dyrcona: I have that same project for PINES libs and GALILEO |
18:37 |
bshum |
Probably not |
18:37 |
bshum |
Still, perhaps you've stumbled into a quirky issue area. |
18:37 |
bshum |
:D |
18:37 |
gsams |
I suppose it would warrant some testing in some way, since this does appear to be a bug in our system at least |
18:38 |
gsams |
And I'm not sure if possible incoming libraries would be interested in using this feature |
18:38 |
gsams |
or current libraries for that matter |
18:38 |
gsams |
will enquire |
18:45 |
|
CarrieC left #evergreen |
18:48 |
bshum |
Well, the code looks like it ought to prompt the user with something. |
18:48 |
bshum |
I'm going to try testing it on one of our servers to see if it does |
10:26 |
rfrasur |
mmorgan: thanks. I noted that it did clear the field but didn't notice a message. That could be because I added my own though. |
10:27 |
|
mcooper joined #evergreen |
10:27 |
mmorgan |
I actually had to reload the patron (F8) to see the message. It didn't refresh until I did that. |
10:28 |
rfrasur |
okay, I'll go in and test it. I was wondering if it'd be a good idea to bar email addresses...but I can see that being a bad idea as well. |
10:30 |
jeff |
there's no current method to do so. |
10:30 |
jeff |
i've not had need to do so here. |
10:31 |
rfrasur |
well, honestly, the only need to do it here stems from repeated inaccuracies in input...and a lack of attention. |
10:59 |
jeff |
jbfink: you're welcome! glad it was somewhat simple to fix! |
10:59 |
jbfink |
got opensrf like 99% done. Got one problem with the srf shell that I will pick at today. |
11:00 |
jeff |
jbfink: i'm interested to hear what your thoughts on docker are, perhaps after you've used it more (if it's brand new to you) |
11:00 |
jbfink |
if this works though it will make deployment (in test instances at least) like about super super easy. |
11:00 |
jbfink |
I've done some work with it. |
11:00 |
jbfink |
I would not call myself an expert, but boy, is it something really intriguing. |
11:00 |
jbfink |
I did a Koha container for it. :) http://index.docker.io/u/jbfink/koha |
11:01 |
dbs |
jbfink++ |
11:01 |
|
CarrieC joined #evergreen |
11:10 |
rfrasur |
RoganH: Do you have a minute to talk about the inventory module project? |
17:00 |
rfrasur |
forEVER! |
17:01 |
rfrasur |
I wish we could actually get a real circ statistic on it...but will figure that out after it gets rolling and people care enough. |
17:02 |
gsams |
bshum: I didn't even think to check that at all, thanks again |
17:03 |
bshum |
gsams: No problem man. I couldn't remember how it was all setup either :) |
17:04 |
bshum |
Glad it's not a bug or other problem. |
17:06 |
bshum |
Dyrcona++ tsbere++ #for live testing the pain and suffering ahead of the rest of us |
17:06 |
bshum |
(and fixing it) |
17:07 |
Dyrcona |
Who said anything about fixing it? ;) |
17:08 |
Dyrcona |
Well, the first attempt caused a different error, but we'll have it by the end of the week, I'm sure. |
17:08 |
* tsbere |
made things worse, a nicer error for the user, but then a crashed circ backend |
10:16 |
moodaepo |
eeevil++ |
10:19 |
|
caveman273 left #evergreen |
10:24 |
|
ericar_ joined #evergreen |
10:25 |
dbs |
jboyer-isl: I suspect there would be a) bits of time for devs who are not familiar with a given area to get up to speed on certain areas (websockets, security, testing come to mind from last hack-a-way); communication and coordination on critical areas; and powering through things that especially benefit from collaboration |
10:26 |
dbs |
It's not a "how to develop Evergreen bootcamp" though |
10:26 |
jboyer-isl |
Thanks. |
10:27 |
* dbs |
notes that he's not the organizer and might be off-base |
10:27 |
jboyer-isl |
Well, it can't be too much of that, or nothing else would get done. |
12:07 |
bshum |
Total bill showing underneath the "bills" button in the patron interface. |
12:08 |
Dyrcona |
bshum: Red usually means a deficit. If it does show up in red maybe it means the library owes the patron. |
12:08 |
bshum |
Aha! |
12:08 |
Dyrcona |
You should test that to be sure, though. |
12:08 |
bshum |
Yeah I'm checking now |
12:09 |
bshum |
Nope, it's still black for them too. |
12:09 |
bshum |
$-8.00 in black text |
12:09 |
bshum |
I think the library is imagining the red. |
12:09 |
bshum |
Hmm |
12:10 |
Dyrcona |
I've never seen it in red personally, but I don't work with it that much. |
12:10 |
mmorgan |
fine threshold is set at $50, and my test patron owes $63.60, which appears in red under the Bills button. |
12:11 |
Dyrcona |
I bet that's it in bshum's case too, not those numbers exactly, but |
12:12 |
bshum |
mmorgan: Dyrcona: We'll check for that, thanks! |
12:15 |
RoganH |
A quick reminder - Hackaway 2013 Registration is open now and until 8/15 http://hackaway2013.eventbrite.com/ |
12:19 |
|
jihpringle joined #evergreen |
12:25 |
|
ElliotFriend joined #evergreen |
12:27 |
ElliotFriend |
Is there a way to display branch information (hours, address, etc.) in the OPAC? On an "About the library" page, for example? |
12:28 |
kmlussier |
ElliotFriend: It's not available yet, but I'm currently testing https://bugs.launchpad.net/evergreen/+bug/1201982, which will allow libraries to provide a link to this information. |
12:29 |
pinesol_green` |
Launchpad bug 1201982 in Evergreen "TPAC: In copy table, link library name to an external URL (if OU setting exists)" (affected: 1, heat: 6) [Wishlist,New] |
12:29 |
kmlussier |
I expect it will be available as of 2.5 |
12:29 |
dbs |
ElliotFriend: I'm also interested in automatically generating pages like that in the TPAC, with schema.org markup |
13:41 |
|
montgoc1 joined #evergreen |
13:44 |
* dbs |
takes a quick look for "template" in the official docs and notices that we are overloading the term "template" quite severely |
13:47 |
jeff_ |
tt2 templates, bib templates, copy templates, receipt templates... |
13:48 |
bshum |
jihpringle: Question for you when you have a moment about acq... |
13:48 |
bshum |
jihpringle: mllewellyn has been poking at receiving items in invoicing and seeing a quirk where clicking on it results in a loading bar animation that doesn't go away. |
13:49 |
bshum |
jihpringle: Curious if you've seen that anywhere in your 2.4 acq testing. |
13:49 |
bshum |
We're looking in our logs to see if we can trace it back now. |
13:50 |
jihpringle |
bshum: I don't recall seeing anything like that recently in acq and our libraries haven't reported it, but I have previously seen that in year end |
13:51 |
jihpringle |
I've also seen that in Circulation Policies especially when applying limits to existing policies |
13:51 |
|
abneiman joined #evergreen |
14:43 |
StephenGWills |
nod. kmlussier++ |
14:43 |
kmlussier |
RoganH: I was thinking a vote could wait until we have a real policy to vote on. |
14:44 |
StephenGWills |
it sounds if, if a motion is needed it would come next meeting? |
14:44 |
gmcharlt |
yes |
14:44 |
gmcharlt |
#action kmlussier will draw up an Evergreen version of Koha's support listing policy for consideration by the EOB by the August meeting |
14:45 |
* gmcharlt |
notes, BTW, that Koha's webmaster uses a particular WordPress plugin, Connections, for managing the directory; has worked well so far |
14:45 |
gmcharlt |
moving on |
14:45 |
gmcharlt |
#topic Follow-up on testing meeting |
14:45 |
* StephenGWills |
makes a note and runs to google |
14:45 |
gmcharlt |
sborger: you have the follow |
14:46 |
gmcharlt |
*floor |
14:46 |
sborger |
I have notes from our conference call which I would like to share but wasn't sure what would be appropriate. Also, I don't have access to Google docs at work. Would the board like to review the notes from the meeting? |
14:47 |
sborger |
Shall I email Galen or Kathy for them to quickly upload the minutes to Google docs so everyone can review? |
14:47 |
gmcharlt |
sborger: please |
14:48 |
sborger |
Since this was the first meeting, I spent much of the time asking questions to find out what has been done in the past and what is presently done in terms of testing Evergreen. |
14:48 |
gmcharlt |
#info Minutes of the 2013-07-02 testing conference call are at https://docs.google.com/file/d/1ImfRJH4V_5xUhTmv_8ni4ekt7_J-4gBU_EGz_lrOI9renZEO26QpHCwZ3JRL/edit?usp=sharing |
14:49 |
sborger |
We discussed collaboration with DIG since there certainly is an opportunity there and we don't want to recreate the wheel. |
14:50 |
gmcharlt |
any questions for sborger? |
14:50 |
sborger |
Moving forward, it was recommended that we plan another conference call and invite Yamil (DIG), a rep from Equinox (QA project) and a developer (Dan Scott). |
16:38 |
|
sseng joined #evergreen |
16:41 |
bshum |
senator: Hmm, changed that global flag and it still takes about 16-17 seconds |
16:42 |
* bshum |
now realizes he should have noted what the original value of that flag was. |
16:42 |
senator |
bshum: it was 100 |
16:42 |
senator |
thanks for the test! |
16:42 |
bshum |
Gotcha. |
16:43 |
bshum |
So no, unfortunately no effect it seems |
16:54 |
|
afterl left #evergreen |
11:12 |
dbs |
-1 to "in production" as good enough. "in production" means "with one very limited set of settings" |
11:13 |
eeevil |
dbs: what is good enough, then, for a bug fix? |
11:14 |
dbs |
and they may be in production, without the other fixes that are in production elsewhere, with not so good results |
11:14 |
eeevil |
dbs: code changes that aren't tested in production are tested on (normally) one non-author developer's test server |
11:15 |
gmcharlt |
dbs: I grant that that is a real concern, but do you have any alternative? a good many things simply do not get tested adequately before they hit master; at least bugfixes that are in actual production use have at least a bit more going for them, no? |
11:17 |
dbs |
The alternative that I proposed in the past was a commit checklist, which has had no adoption, but would probably be a good idea for sites to look through. |
11:18 |
eeevil |
to be clear, all, I'm talking about but fixes for common problems. IOW, things that have been seen (in this case, that I have seen) at multiple EG sites, for which a fix has been developed and shown to work |
11:18 |
dbwells |
I've sometimes wondered if we should adopt a more general bug-aging policy, i.e. and bugfix branch older than X is fair game for the author to commit. This would not apply to features, and I am not sure what "X" should be. |
11:21 |
eeevil |
dbs: you're not alone, as you well know (**points at self**), but that's also much more rare these days |
11:21 |
dbs |
I'm not sure we know what we _want_ to accomplish |
11:21 |
eeevil |
dbwells: for my part, yes, I'm trying to find a way to get real problems fixed without straying from convention where at all possible |
11:22 |
dbs |
What I would want to accomplish would be to have a reasonable amount of certainty that a commit doesn't introduce regressions for common but complex scenarios. |
11:23 |
dbs |
Sounds like phasefx is working towards that with the recreation of Ben's effort from a couple of summers back of an auto-installing VM that runs various test cases and reports on the results, which would be a good move. |
11:23 |
eeevil |
dbs: in an existential sense? ;) I know what I'm trying to accomplish: fixes are offered based on problems at live sites, but they are not of the type that many EG developers care about, or feel comfortable working on, or believe effects them or their site |
11:24 |
eeevil |
and I'm trying to find an equivalent to "wait for someone to care" |
11:25 |
dbs |
eeevil: no, I sometimes wonder whether one of the goals is "bug inbox zero" and whether that's actually a worthwhile goal (sez the guy with a mail inbox in the thousands) |
11:32 |
* berick |
reminds self to let things simmer in all cases |
11:33 |
gmcharlt |
it also points to another factor -- simmering time as compared to the complexity of the patch |
11:33 |
dbwells |
I am also -1 on this proposal, but that is mostly out of default, and not having enough time and information to properly consider the whole situation. |
11:33 |
eeevil |
since there is reasonable and thoughtful objection to "production testing is not enough", I'll be leaving 2 bug fixes unmerged for 2.4.1, unless someone wants to put their name on them next to mine. the two bugs, for reference, are: https://bugs.launchpad.net/evergreen/+bug/1200770 https://bugs.launchpad.net/evergreen/+bug/1200768 |
11:33 |
pinesol_green |
Launchpad bug 1200770 in Evergreen 2.4 "Search result rendering can crush the system" (affected: 1, heat: 6) [High,New] |
11:33 |
pinesol_green |
Launchpad bug 1200768 in Evergreen "2 remaining authority fixed fields out of whack" (affected: 1, heat: 6) [Medium,New] |
11:34 |
gmcharlt |
I can vouch for 1200700, having done quite a bit of back and forth with eeevil over it, FWIW |
11:36 |
dbs |
complexity, severity, local priorities, expertise - all compounding factors, and poor old i18n gets crushed in many cases :/ |
11:36 |
eeevil |
there's a third that I wanted to get in too, and if my stirring up this mess gets eyes on it that it's been worth it, but it's much newer than those two: https://bugs.launchpad.net/evergreen/+bug/1201962 |
11:36 |
pinesol_green |
Launchpad bug 1201962 in Evergreen 2.4 "hold count by record includes useless where clause" (affected: 1, heat: 6) [Medium,New] |
11:37 |
dbs |
eeevil: yeah, that one sounded good. |
11:38 |
dbs |
Many of these would be slam-dunks if we could drop them in, run a standard set of system tests, and note any differences in performance or output |
11:39 |
dbs |
Otherwise, we eyeball it and take our chances, or go through the laborious process of setting up a test environment, test data, profiling, etc to try and do what machines do better anyway |
11:39 |
eeevil |
dbs: right, and that is what phasefx is working towards, but until then my hope was (in the case of 1200770) that multiple production sites would be enough |
11:39 |
dbwells |
eeevil: thanks for posting the bugs, I think that clarifies what you are asking |
11:40 |
eeevil |
hrm, perhaps that's a factor to consider, actually. if /multiple/ production sites use the fix, does that make a difference in terms of "production = sign-off"? |
12:19 |
dbwells |
eeevil: re:1200770, it seems like we might be missing an 'next' where we push the $bid back on. Otherwise, it seems like we end up running the request again anyway, since it is in just a bare 'else'. |
12:21 |
* eeevil |
looks |
12:22 |
dbs |
QA note for phasefx: recording log file sizes and looking for size increases over time might be worthwhile |
12:23 |
phasefx |
dbs: good idea. Besides explicit tests with assertions, I'm also thinking of doing straight up diffs of various outputs between runs, and logs certainly qualify |
12:25 |
dbs |
phasefx: yeah, diffs of expected output is pretty common. logs are going to be fuzzier due to time stamps and what not :/ |
12:25 |
phasefx |
yeah |
12:27 |
eeevil |
dbwells: yes. I'm going to force-push a 'next' in there |
12:29 |
|
edoceo joined #evergreen |
12:29 |
|
jihpringle joined #evergreen |
12:30 |
eeevil |
dbwells: complete |
12:30 |
dbwells |
eeevil: thanks, will test |
12:33 |
|
smyers_ joined #evergreen |
12:36 |
eeevil |
dbwells: thank you, kind sir |
12:36 |
|
remingtron joined #evergreen |
12:41 |
gmcharlt |
dbwells++ |
12:41 |
gmcharlt |
eeevil: I'm going to do some torture testing of that now |
12:41 |
eeevil |
gmcharlt: cool, thanks |
12:46 |
gmcharlt |
eeevil: OK, looks good |
12:46 |
gmcharlt |
again |
15:55 |
eeevil |
re-entering i18n doldrums ... makensis :( |
16:06 |
|
brentm_sage joined #evergreen |
16:14 |
|
bshum joined #evergreen |
16:22 |
dbs |
Dyrcona: re bug 1201982 - can you verify that misc_util.tt2 matches the diff at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=aeabe10c51b502a7d9256c2e760fca13e726fdf3 on your test server? |
16:22 |
pinesol_green |
Launchpad bug 1201982 in Evergreen "TPAC: In copy table, link library name to an external URL (if OU setting exists)" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1201982 |
16:27 |
Dyrcona |
No, it doesn't. |
16:27 |
Dyrcona |
I'll make a new branch for tomorrow. |
17:08 |
Dyrcona |
ALTER FUNCTION action.copy_related_hold_stats(bigint) |
17:08 |
Dyrcona |
OWNER TO evergreen; |
17:08 |
Dyrcona |
Looks like a "bug" in the 0811 upgrade script to me..... |
17:08 |
eeevil |
ok ... testers wanted! http://evergreen-ils.org/downloads/previews/ has a pile of 2.4.1 files for lookin'. tests appreciated. waiting for at least one set of eyes to avoid brown-bagging |
17:08 |
eeevil |
AND THERE'S THER FIRST! ;) |
17:09 |
eeevil |
Dyrcona: yeah... I'm gonna remove that with a big ol' chainsaw |
17:09 |
dbs |
Dyrcona++ |
17:11 |
Dyrcona |
bah. pushing to a checked out branch is not advisable.... |
17:16 |
pinesol_green |
[evergreen|Mike Rylander] Explicit function ownership is not the job of upgrade scripts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e66ddf9> |
09:41 |
* paxed |
investigates |
09:42 |
|
mrpeters joined #evergreen |
09:43 |
rfrasur |
something that's called .id is usually a number, isn't it? while w/o the .id....it's a text string? that's just the understanding I've had when building reports (that work 50% of the time) |
09:43 |
paxed |
http://i.imgur.com/6jPQg1l.jpg |
09:43 |
paxed |
i think ctx.user.home_ou is a fieldmapper object, so it shouldn't work |
09:44 |
* paxed |
compiles eg and tests |
09:44 |
rfrasur |
just so you know...I prefer earth to the other views. much prettier....and watered |
09:44 |
paxed |
yup |
09:46 |
paxed |
(the Venus picture was taken in '67!) |
09:47 |
rfrasur |
We've already got the steam. Now we just need a mouthy young adult...and we'll have the punk. |
09:48 |
rfrasur |
jboyer-isl: are you available? |
09:49 |
jboyer-isl |
I'm in and out. In now. |
09:51 |
rfrasur |
I did a little testing on the galaxy tab 7 last night. it worked well, looked good, etc. the only thing I was noticed was when I changed orientation it switches to traditional OPAC view (which was expected), but because it's narrower, the facets and results don't fit...and the facets show first. Is there a way to have an intermediate view that gets those facets out of the way? |
09:52 |
jboyer-isl |
There is. I'll have to look some things up, but there can easily be an intermediate step between everything and bare bones. |
09:54 |
rfrasur |
excellent. Other than that...and I also was thinking about the search view. I'm not sure that's a big deal after all. Does it show results based on relevance as default? (I don't really know how to spell relevance/relevence) |
09:54 |
rfrasur |
but...other than that...I think it's good. I mean, there's always something to critique/criticize, but it seems like a great step. |
11:14 |
kayals |
By default admin account did not get associated to the top org level unit. How to assign admin to get top level permission...say Global Administrator |
11:14 |
kayals |
thanks |
11:23 |
rjackson-isl |
bshum++ for knowledge sharing |
11:23 |
bshum |
rjackson-isl: Please feel free to add notes or findings to that bug report. |
11:24 |
bshum |
I'll try to do the same once the dust settles more over here :( |
11:27 |
bshum |
kmlussier: "Now witness the firepower of this fully armed and operational battle station." (replace battle station with test server) |
11:29 |
|
kmlussier1 joined #evergreen |
11:31 |
kmlussier |
Heh |
11:31 |
rfrasur |
kmlussier++ # that sounds like a huge task |
11:37 |
bshum |
And then let the hold targeter spread things back out more evenly again. |
11:38 |
bshum |
Like I set all active holds to a prev check time of midnight or something back then. |
11:38 |
bshum |
I've been thinking to push them back towards 9 or 10 pm at the rate I'm going. |
11:55 |
jboyer-isl |
We secretly replaced kmlussier's test server with Folgers crystals. Let's see if she notices. |
11:55 |
rfrasur |
jboyer-isl++ |
11:56 |
jboyer-isl |
dbs: agreed. I was also trying to take a light touch with the html in 2.2. I'll still try to leave as much alone in the future as I can thouhgh, or I'm likely to try to redesign the whole thing. :D |
11:56 |
* kmlussier |
probably wouldn't notice, but tsbere might. :) |
12:00 |
berick |
kmlussier: go for it |
12:08 |
|
jihpringle joined #evergreen |
12:08 |
dbs |
paxed: chrome and firefox both worked for the self-check for me, using OpenSRF master (due to that opensrf_xhr.js issue berick mentioned) when I wrote up http://docs.evergreen-ils.org/2.4/_self_checkout.html a week or so ago |
12:09 |
paxed |
maybe it's just some settings i'm missing then. i tried it with the test data that comes with eg. |
12:09 |
paxed |
the concerto |
12:09 |
dbs |
paxed: there were some gotchas that I noted along the way, too - like needing to have hours of operation set - and I documented those |
12:10 |
paxed |
ah. well, that's it then. |
12:10 |
dbs |
paxed: no, that's all that I used. |
12:28 |
bshum |
paxed: dbs: There's a bug ticket for that too. |
12:28 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1047485 |
12:29 |
pinesol_green |
Launchpad bug 1047485 in Evergreen "Selfcheck needs to be run with https" (affected: 1, heat: 10) [Low,Confirmed] |
12:31 |
bshum |
I vaguely recall testing mrpeters' fix and there was something odd about it. But I guess I should look again... |
12:53 |
rfrasur |
dbwells++ |
12:53 |
bshum |
dbwells++ indeed |
12:56 |
bshum |
eeevil: I think our hold targeter is set to 3 right now. |
14:07 |
gmcharlt |
I think that item was from phasefx? |
14:08 |
phasefx |
yes |
14:08 |
gmcharlt |
phasefx: take it away, then :) |
14:08 |
phasefx |
I have some code I'm wanting feedback on, kudos, etc ;) And I'm hoping others may want to tie it into what we're doing now, etc. |
14:09 |
phasefx |
http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/phasefx/wheezy_installer |
14:09 |
|
BigRig_ joined #evergreen |
14:09 |
phasefx |
basically, given a pristine debian wheezy installation, this will install and run Evergreen without any prompting, and then fire off the pgTAP tests we have, and potentially whatever tests we come up with that require a live environment |
14:10 |
phasefx |
an area I'm really weak on is Buildbot, though it's not necessary for what I'm trying to do, it'd be nice to have some integration there |
14:11 |
|
tmccanna joined #evergreen |
14:11 |
phasefx |
so, any thoughts, interest, comments, etc? |
14:11 |
phasefx |
defer discussion to list? |
14:12 |
gmcharlt |
phasefx: it's a good idea, but sounds like discussion will in fact need to be deferred |
14:12 |
eeevil |
comment: +1 |
14:12 |
|
acoomes joined #evergreen |
14:13 |
berick |
phasefx: would you accept patches for teaching the script to update an existing install and firing the tests again? |
14:13 |
gmcharlt |
ok, moving on |
14:13 |
berick |
if it doesn't do that already, that is |
14:13 |
gmcharlt |
#topic OpenSRF release |
14:35 |
jsime |
it wasn't clear from that initial review if the use of ILIKE was more extensive, though, hence the flagging of it |
14:35 |
eeevil |
jsime: very fair. thanks! |
14:35 |
jsime |
np |
14:36 |
patnorton |
dbwells - once we get moving with a fully functional test environment, approximately 2 − 2.5 months |
14:36 |
patnorton |
environment should be available this week |
14:36 |
patnorton |
i beleive |
14:36 |
dbwells |
patnorton: sounds good, thank you |
14:36 |
kmlussier |
Yes, we're hoping for this week unless tsbere tells me something differently. |
14:38 |
gmcharlt |
anything else on this topic, or any last-minute topics? |
10:15 |
|
rfrasur joined #evergreen |
10:15 |
jeff_ |
we're on 2.2, so we don't even have copy location groups, so we just emulated groups in the template -- <option value='527,531,530,532,791,795,529,793,528,794,792,571,516,593,771,770,542,589,549'>Juvenile</option> |
10:15 |
Dyrcona |
jeff_: Take a look at OpenILS::Utils::Normalize::clean_marc in master. It will have some tricks you might to use. |
10:16 |
jeff_ |
it is likely less performant than copy location groups, but I've not tested |
10:16 |
jeff_ |
Dyrcona: thanks! |
10:16 |
csharp |
jeff_: thanks for those details ;-) |
10:22 |
* rfrasur |
sees an email with the subject "mobile OPAC testing" from jboyer-isl - looks very interesting |
10:23 |
gmcharlt |
testing the OPAC from the bookmobile? |
10:23 |
rfrasur |
jboyer-isl: I have story time at 10:30 but will test on a variety of screens after I get done with that. Probably around 11:30. |
10:23 |
gmcharlt |
;) |
10:23 |
rfrasur |
gmcharlt++ # maybe |
10:24 |
rfrasur |
as an unrelated aside - when your mother and brother endorse you on Linkdin, it kind of takes some of the professionalism and credibility away. |
11:19 |
bshum |
parts-- |
11:20 |
bshum |
kmlussier: Our pain begins early this week. |
11:20 |
Dyrcona |
To elebenty and beyond! |
11:21 |
Dyrcona |
kmlussier: My development VM is working if you're interested in testing things. |
11:25 |
|
BigRig joined #evergreen |
11:38 |
bshum |
senator: Dyrcona: To verify, the branch I should look at for the browse stuff is collab/dyrcona/bib-auth-browse-squash, right? |
11:38 |
senator |
bshum: right |
11:38 |
bshum |
(We're rebasing our test servers today and I'm going to add it again to the mix) |
11:38 |
bshum |
Cool deal. |
11:39 |
bshum |
And also, holy cow that's alot o' commits |
11:39 |
Dyrcona |
bshum: There's a small conflict with master at the moment, just keep both parts. |
11:39 |
bshum |
:D |
11:39 |
senator |
bshum: i think when all parties are reasonably happy with it, it can be squashed way down |
11:56 |
senator |
asimon: that should show up in the staff client. if not, there's either a permissions issue or some deeper problem. |
11:56 |
bshum |
That should be in the library settings editor. |
11:56 |
bshum |
Or at least, it was when we configured it. |
11:57 |
dbs |
asimon: maybe your site missed an upgrade ? |
11:57 |
dbs |
looks like it's in 1.6.1-2.0-upgrade-db.sql |
12:03 |
dbs |
Hey, here's a brilliant idea for a simple perl test... ensure that DEBUG_TIMING == 0. heh :) |
12:06 |
|
rfrasur joined #evergreen |
12:07 |
paxed |
dbs: are peer.title & peer.author already scrubbed of hmtl? |
12:07 |
paxed |
blah. html. |
12:09 |
dbs |
paxed: no; good catch. gotta prevent those cataloguers from exploiting vulnerabilities :) |
12:09 |
paxed |
dbs: well, who knows, maybe some author will name their book <a href="goatse"> ... :P |
12:15 |
dbs |
paxed: pushed a nice sanitized branch with a hat-tip to you in the commit message |
12:15 |
rfrasur |
jboyer-isl: testing on galaxy nexus phone...then kindle fire. will try galaxy tab 7 at home later. |
12:16 |
rfrasur |
(of course, it'd help if I could remember my password) |
12:17 |
jboyer-isl |
Thanks. I was able to do a little testing with someone's random android somethingorother and it looked ok, so I'm hoping things will be good all around. |
12:17 |
rfrasur |
so far, it looks good. will take a look in my account and then do a couple searches and do some stuff. |
12:17 |
dbs |
jboyer-isl: any of your work headed 2.5 / master's way? |
12:19 |
rfrasur |
(figure it's a good chance to see how easy it is to do a password reset from my phone) |
12:19 |
jboyer-isl |
Everything that I re-make for 2.4, sure. I haven't actually started that though. D: Need to study up on user/collab branches, because I'm also starting from 0 on that. |
12:20 |
jboyer-isl |
rfraur: and you would also be testing a page I forgot to ever even look at. Hope it looks ok, heh. |
12:20 |
jboyer-isl |
And I can't type. :/ |
12:20 |
rfrasur |
jboyer-isl: the reset page? it looked fine :) |
12:20 |
jboyer-isl |
Lucky us. |
12:22 |
jboyer-isl |
Also, I don't know if all of the necessary back end stuff is running for that to actually work. If you need me to change the password on an account let me know. (The dataload is several months old, in case you've changed it recently.) |
12:27 |
rfrasur |
also, are we foregoing a limited advanced search forever or just for now? |
12:28 |
jboyer-isl |
I just meant that the email will never come, and the actual reset may not work if it did. Are you using the same hostname on the desktop vs. mobile? (and NOT letting the keyboard "help" you by auto-capitalizing the first letter of your username? They're ALSO case sensitive...) |
12:29 |
jboyer-isl |
I'm personally planning to forego advanced search forever. I'm working off the assumption that it's a hassle to enter things into a bunch of fields. I won't argue with anyone else that wants to take care of it. |
12:30 |
rfrasur |
no, I'm using the standing catalog on the desktop (to make sure that I wasn't messing up the log-in). let me try the mobile on the desktop and see what it does there. I'm okay with just the basic search for the same reason you mentioned. |
12:31 |
|
mmorgan left #evergreen |
12:31 |
rfrasur |
yeah, it's not helping me on the desktop (as you say), and I can't log in on the test site. |
12:32 |
rfrasur |
hmm...s/standing/standard |
12:37 |
rfrasur |
I do like the library chooser |
12:38 |
kmlussier |
Dyrcona: Searches on your dev server are quite zippy today. :) |
12:38 |
Dyrcona |
kmlussier: It's the new database server. We got one almost identical to what we use in production. |
12:39 |
Dyrcona |
Which reminds me of an email I have to answer after lunch. |
12:39 |
kmlussier |
Dyrcona++ |
12:40 |
rfrasur |
jboyer-isl: search works well as far as I've delved into it. |
12:40 |
bshum |
dbwells++ #milestone wrangling |
12:41 |
rfrasur |
and records show up nice. can't test the hold placing because of the authentication issue. let me try something with that real quick (sorta quick). |
12:43 |
rfrasur |
yeah - no. won't authenticate. |
12:49 |
pinesol_green |
[evergreen|Dan Wells] Make AuthProxy LDAP bind code more robust - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=36ea3a2> |
12:49 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
12:52 |
bshum |
Blah, 0795 fails because we apparently don't have a metabib_field entry 30 for LCCN. |
13:37 |
paxed |
do people remove the bug assignment once they've released a fix for it? |
13:39 |
jboyer-isl |
I'm more interested in how Chrome likes it than "Browser," but I was able to log in with someone else's phone using Browser. |
13:39 |
|
sidion left #evergreen |
13:39 |
rfrasur |
I'm testing Chrome right now. Browser didn't work on phone...and neither did Firefox on desktop. Maybe I need to clear out the cache and start over. |
13:41 |
bshum |
kmlussier: I'll be here and there. But yeah, in a phone call during the meeting, so I might be a little more distant than I'd like :( |
13:41 |
rfrasur |
jboyer-isl:fail on phone using chrome |
13:41 |
kmlussier |
bshum: A little difficult to run a meeting that way. :) |
14:07 |
|
akilsdonk_ joined #evergreen |
14:09 |
jboyer-isl |
It's possible they're all disabled in case a patron tried to play with it., I've not looked at it. |
14:09 |
jboyer-isl |
disabled because it's the migration server, that is. |
14:10 |
rfrasur |
ahhh, I gotcha. You're probably right. Are you testing it with a staff profile account I'm assuming? |
14:10 |
jboyer-isl |
yes. |
14:10 |
jboyer-isl |
They act the same in the OPAC anyway. |
14:11 |
rfrasur |
except when they're disabled :-) |
14:14 |
rfrasur |
paxed++ |
14:32 |
|
tspindler joined #evergreen |
14:40 |
|
jihpringle joined #evergreen |
14:41 |
Dyrcona |
Well, I'm going to rig an experiment to test my question. |
14:59 |
|
rfrasur joined #evergreen |
15:12 |
|
kbeswick joined #evergreen |
15:27 |
|
ldwhalen joined #evergreen |
15:56 |
linuxpoet |
Dyrcona: it is not reasonable to suggest that kind of switch at this time. It isn't like it is something that can be done overnight for this installation |
15:56 |
paxed |
phasefx: no. we're not in production yet. |
15:57 |
phasefx |
paxed: roger that |
15:57 |
paxed |
phasefx: but i do tend to test most of my fixes with our full conversion db |
15:57 |
Dyrcona |
linuxpoet: You will have fewer problems or none at all if you switch, and you'll get actual useful help. |
15:58 |
Dyrcona |
Anyway, at that point GNU Make is passing the error up from an executable that it has run. The first [3] suggests it is in the 3 recursive make call, so 3 three Makefiles down. |
16:00 |
bshum |
linuxpoet: Actually it seems perfectly reasonable to me for Dyrcona to suggest using one of the established known linux distributions that are currently supported by the community documentation for OpenSRF. |
17:06 |
* Dyrcona |
recently cleaned his hates up. ;) |
17:06 |
dbwells |
paxed: Sorry, was afk. Yes, just confirming that 2.5.0-alpha1 targetting is fine and expected. |
17:06 |
|
kmlussier1 joined #evergreen |
17:06 |
gmcharlt |
@love test cases |
17:06 |
pinesol_green |
gmcharlt: The operation succeeded. gmcharlt loves test cases. |
17:06 |
bshum |
@love Fridays |
17:06 |
pinesol_green |
bshum: The operation succeeded. bshum loves Fridays. |
17:06 |
rfrasur |
@caresabout |
17:27 |
* rfrasur |
decides doing payroll is better than sifting through county personal income growth study. |
17:28 |
jeff_ |
yeah. i'm not even lucky enough to get it in PickupLocation, but it's in ItemShipped/ShippingInformation/PhysicalAddress/UnstructuredAddress |
17:29 |
Dyrcona |
Gotta love standards that aren't. |
17:29 |
jeff_ |
There are codes in the system for individual branches, but the codes don't seem to be used here, so it's unstructured freeform-looking text. |
17:29 |
jeff_ |
This is because I got impatient and jumped ahead and found a way to test without our contact at the state level, so I could be shown a better way on Monday, but it is seeming unlikely. |
17:30 |
Dyrcona |
Y'know, it is valid to respond with just the version response if you don't "understand" a message you've received. |
17:30 |
jeff_ |
It is incredibly likely that we will not expose our end users to the statewide web interface, and will just scrape it on their behalf. :P |
17:31 |
* Dyrcona |
shudders at the mention of scraping. |
12:22 |
rfrasur |
my thinking was...present this to comp sci professors/departments as an educational tool. So, these kids may not actually be involved in the EG community (yet...or ever) or contributing/building anything of value (right now...or ever) |
12:23 |
rfrasur |
but, it's free software that requires all the basics that get covered in a comp. eng./sci. program...and if the net was thrown over a broad enough area, there could protentially be some quality return. |
12:24 |
|
laque|2 joined #evergreen |
12:26 |
egbuilder_ |
build #257 of evergreen-master-debian-6.00-x86_64 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/257 blamelist: Bill Erickson <berickesilibrary.com> |
12:26 |
egbuilder_ |
build #233 of evergreen-master-ubuntu-12.04-x86 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/233 blamelist: Bill Erickson <berickesilibrary.com> |
12:26 |
egbuilder_ |
build #199 of evergreen-master-fedora-18 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/199 blamelist: Bill Erickson <berickesilibrary.com> |
12:28 |
eeevil |
dangit |
12:28 |
* eeevil |
goes to fix |
12:29 |
bshum |
buildbot++ |
12:36 |
pinesol_green |
Launchpad bug 833820 in Evergreen "Support PO activation without requiring bibs/items" (affected: 1, heat: 8) [Wishlist,Triaged] https://launchpad.net/bugs/833820 - Assigned to Dan Wells (dbw2) |
12:37 |
berick |
dbwells: will do |
12:38 |
dbwells |
berick: thanks! |
12:46 |
egbuilder_ |
build #258 of evergreen-master-debian-6.00-x86_64 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/258 |
12:46 |
egbuilder_ |
build #234 of evergreen-master-ubuntu-12.04-x86 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/234 |
12:46 |
egbuilder_ |
build #200 of evergreen-master-fedora-18 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/200 |
12:55 |
rfrasur |
why wouldn't Google+ integrate bookmarks into a person's profile? |
12:56 |
dbs |
rfrasur: possibly because it would require browser integration, and not everyone uses Chrome? |
12:56 |
* rfrasur |
uses Firefox as default. |
14:13 |
rfrasur |
I like the idea of the Google Hangout. It may be difficult for those further abroad to handle two trips out east (in our case). |
14:14 |
kmlussier |
Sure, I don't think I could travel out of state to a doc hack-a-way this year, but would be happy to join via a Hangout if it is hosted in another area. |
14:15 |
yboston |
BTW, with my intern I used Dropbox to share the files she was converting to AsciiDoc, which we can use in combination with Google hang out |
14:15 |
dbs |
I highly recommend getting people who plan to join via Google Hangout to go through a test run a few days before, just to ensure everyone's equipment is all good :) |
14:15 |
yboston |
dbs: thanks |
14:15 |
rfrasur |
dbs: very good point |
14:16 |
yboston |
we can try it during a DIG meeting |
16:51 |
dbs |
we also added some custom code to support users logging in with their LDAP username, even though their actor.usr.usrname was their email address, because of the likelihood of dscottlaurentian.ca clashing with dscottuwindsor.ca when it came to LDAP uids |
16:51 |
dbs |
but that's only a consortial concern where more than one LDAP (or CAS in the case of Windsor) system is in play |
16:52 |
dbs |
LDAP CNs, I should use the appropriate terminology :) |
16:55 |
dbwells |
berick: are you actively testing it now? I have a bug fix branch I made a while back for a specific request here in IRC, but never heard back whether it helped them or not. I am going to try and figure out what happened to that. |
16:55 |
berick |
dbwells: not this second, but will be doign some poking soon-ish |
16:56 |
berick |
i'd be glad to review the code. not sure if I know enough to be of assistance just yet, though. |
16:57 |
|
mtcarlson joined #evergreen |
10:24 |
paxed |
so the surveys cannot be answered anymore? |
10:24 |
|
kmlussier joined #evergreen |
10:25 |
|
jboyer-isl joined #evergreen |
10:28 |
rfrasur |
paxed: my understanding, and this is old understanding that might have been wrong in the beginning - was you could set it up whenever and when it went into effect, it'd alert you when you went into the patron account. |
10:28 |
* rfrasur |
has never used it. |
10:28 |
|
Meliss1 joined #evergreen |
10:28 |
* rfrasur |
will do a lil test |
10:29 |
paxed |
i only quickly glanced at the UI today (and filed bug 1199626) |
10:29 |
pinesol_green |
Launchpad bug 1199626 in Evergreen "Add New Survey asks start and end dates in US format" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1199626 |
10:30 |
|
bshum joined #evergreen |
11:08 |
rfrasur |
I did clear the cache, but it might not have been enough. |
11:08 |
phasefx |
the view under Other is read-only. I think the patron editor and offline patron registration is the only other places they show up |
11:09 |
* paxed |
hopes for several utf-8 related fixes in -m2 ... :P |
11:10 |
rfrasur |
testing |
11:11 |
rfrasur |
(an automatic reload when saving configuration would be nice as well) |
11:13 |
rfrasur |
okay...the read only did show up... |
11:13 |
rfrasur |
ty phasefx. hunting around still. |
11:15 |
phasefx |
rfrasur: automatic reloads may be trickier than you might think, if you expect all of your workstations to instantly get changes like that. At the time, the mindset was that a lot of these changes were supposed to be treated as big deals and not on the fly tinkering. I'd like instant updates, though |
11:15 |
rfrasur |
and it's in the patron registration, but not in the patron acct editor...registration and offline registration. |
11:16 |
rfrasur |
phasefx: yeah, I understand...and I tend to do a lot more on-the-fly things anyway. the whole break it and ask questions later. |
11:26 |
|
acoomes joined #evergreen |
11:26 |
phasefx |
was a developer itch, but I don't think it was something PINES was pushing for, so it didn't land in jspac |
11:27 |
rfrasur |
personally, I don't have any desire to do a survey through the OPAC. I think it'd cheese some people off and confuse some others. But, if that's the case, and maybe it's already addressed in later versions, that needs to be removed from the UI |
11:28 |
Dyrcona |
gmcharlt: If you have a test version of MARC::Charset that you'd like me to try, just let me know. |
11:28 |
gmcharlt |
Dyrcona: soon |
11:29 |
Dyrcona |
cool |
11:29 |
phasefx |
rfrasur: I think the only reason for us to even want to implement over just using a dedicated javascript library is the js-lite mandate for the TPAC |
14:44 |
pinesol_green |
Launchpad bug 1103706 in Evergreen 2.4 "Hold ratios in circ policies cause errors when trying to renew items" (affected: 2, heat: 16) [Medium,Confirmed] https://launchpad.net/bugs/1103706 |
14:45 |
|
jdouma joined #evergreen |
14:46 |
fparks |
bshum: Interesting in a good way? |
14:46 |
bshum |
fparks: I'm sure kmlussier and others will be quite interested in what you've found. |
14:47 |
bshum |
Sounds like a good thing though; I'll have to test it out too, but we don't use hold ratios in our system. |
14:47 |
kmlussier |
I'm in the process of adding it to Dyrcona's list of development branches. :) |
14:48 |
rfrasur |
Okay, lovelies - time to shut 'er down and make the trek south. |
14:50 |
kmlussier |
fparks: I'll see if I can test it soon. If it works, you will make a lot of our libraries very happy. :) |
15:05 |
jeff_ |
kmlussier: what does hold ratio decide for you? |
15:06 |
jeff_ |
kmlussier: are you using it to permit/deny renewals, or something else? |
15:07 |
kmlussier |
jeff_: We aren't using it yet because of bug 1103706. What we want to use it for is to prevent renewals when there are holds on the title and no available copies to fill that hold. |
15:12 |
gsams__ |
The worst part is I am having trouble duplicating the behavior |
15:12 |
gsams__ |
but I have seen it happen |
15:13 |
jeff_ |
you can't reproduce it with an item checked out, placing a copy-level hold on the item, then attempting renewal? |
15:14 |
gsams__ |
I haven't been able to so far, its really quite odd. I've been trying to track down the items that this has happened on |
15:14 |
gsams__ |
I just got a small list of items that this has happened and am about to run tests with those |
15:14 |
jeff_ |
gsams__: i suspect it may vary depending on if there are any other holds. |
15:15 |
gsams__ |
jeff_: and I can't verify if the holds were the only ones on those items/titles |
15:16 |
jeff_ |
my initial thought was that the copy check was done solely on action.hold_copy_map and that copy holds might not use ahcm -- but at least in 2.2, I've confirmed that copy level holds do indeed use ahcm. |
15:24 |
phasefx |
bshum: there's a list of overridable events for renewals in server/circ/util.js, line 3883 |
15:25 |
|
zerick joined #evergreen |
15:27 |
|
zerick joined #evergreen |
15:29 |
gsams__ |
jihpringle: I will test this out and submit a bug if I can duplicate it on our system. I don't currently see anything like that. |
15:31 |
jihpringle |
I don't think we ever submitted it as a bug, we just told our library to make sure to check things in first, but I agree that it is a bug |
15:35 |
|
mtcarlson joined #evergreen |
15:37 |
bshum |
csharp: There were improvements to patron search and UI, but yes, there's still something major going on. |
13:20 |
WNPL |
Would anybody know if there is a way to include a ILS User expiration in my reports? |
13:21 |
WNPL |
Expiration date* |
13:21 |
dbwells |
rfrasur: The intention of the event is to focus on development, especially complex or cross-feature development which can benefit from in-person developer interaction. I don't want to exclude people outright, but if a person cannot partcipate in such things, then this event isn't really for them. |
13:26 |
yboston |
rfrasur: I am a member of DIG, and I am planning on attending the hack-away. I am not very familiar with the code, but I already know some Template Toolkit basics, but if all else fails I can set up tests systems with brand new code at the hack away. I can also work on some documentation while there. |
13:27 |
yboston |
rfrasur: DIG also has rough plans to try to do our own documentation sprint / hack-a-way sometime in the next few months. We had one last year around the same time of the dev hack-a-way at my library in Boston |
13:27 |
kmlussier |
moodaepo: Sure, either Lori or Jim. I think Jim has the archive. |
13:28 |
rfrasur |
dbwells: yboston: will roll this around in my head for a few minutes - hookin' a youngin' up with a new card and some work/study for her fines. |
13:33 |
rfrasur |
okay...reading |
20:02 |
pinesol_green |
[evergreen|Dan Scott] Correct Linux staff client build instructions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=39c46c1> |
20:07 |
* bshum |
ponders |
20:15 |
mcooper |
bshum: what are you pondering? |
20:16 |
bshum |
mcooper: Reading the bug tickets and picking which to work on. |
20:16 |
bshum |
mcooper: Speaking of which, I vaguely remember testing your work for the admin perms so whenever you're finished with your rebase, I think we can move that along. |
20:16 |
pinesol_green |
[evergreen|Pasi Kallinen] Fix LP#1108668 by marking the internet access level column contents as translatable in fm_IDL.xml - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f0f70c4> |
20:17 |
mcooper |
bshum: funny you mention it, i did that just recently. needs some testing though. |
20:18 |
mcooper |
bshum: by me i mean, i try to do that before inflicting anything on other people |
20:18 |
mcooper |
=) |
20:18 |
bshum |
mcooper++ |
20:22 |
pinesol_green |
[evergreen|Jason Stephenson] Modify default logging of SIP2 in oils_ctl.sh. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2a8ca3> |
20:40 |
pinesol_green |
[evergreen|Pasi Kallinen] Don't let pref_ou repeat in staff recent searches list - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8a1598e> |
03:25 |
|
Lunchb0x joined #evergreen |
07:18 |
|
mrpeters joined #evergreen |
07:41 |
|
jboyer-isl joined #evergreen |
08:03 |
csharp_ |
so during the vandelay upload step, to which location is the file uploaded? I am expecting it to be in the location specified in <open-ils.vandelay><importer> in opensrf.xml, but I don't see it there |
08:04 |
csharp_ |
also not in /tmp on either of the brick heads on my test server |
08:28 |
|
kbeswick joined #evergreen |
08:36 |
berick |
csharp_: the file is deleted after all the records are queued |
08:37 |
|
Dyrcona joined #evergreen |
08:42 |
|
Shae joined #evergreen |
08:45 |
|
ericar joined #evergreen |
08:48 |
|
csharp joined #evergreen |
08:50 |
csharp |
berick: I guess I'm trying to see where in the process things are. I'm testing whether the ~250MB file I'm uploading is actually moving since I'm just seeing "Uploading..." on the interface. Just looking for a way to monitor progress |
08:51 |
berick |
ah, gotcha |
08:52 |
berick |
in that case, yes, you should see a file slowing growing in size in the directory configured under <importer> |
08:52 |
berick |
s/slowing/slowly/ |
15:01 |
kmlussier |
csharp: My understanding is that our consortia limit the size of their uploads, but I can't remember what limit they used. |
15:01 |
csharp |
it's possible that my staff client auth session timed out while it was running too |
15:01 |
csharp |
ah - makes sense |
15:02 |
kmlussier |
I don't think anyone did a test to see how large the files could get. But I can check. |
15:02 |
csharp |
thanks |
15:02 |
|
tmccanna left #evergreen |
15:05 |
|
tmccanna joined #evergreen |
16:10 |
Dyrcona |
MARC::CharSet just loves them to death! |
16:13 |
Dyrcona |
gmcharlt: I'll be emailing you some examples a bit later, possibly tomorrow. |
16:13 |
gmcharlt |
Dyrcona++ |
16:13 |
rfrasur |
Hah! Have been wanting to test some Korean records. How many characters are in the vietnamese charset? |
16:14 |
Dyrcona |
Phép lạ của sự tỉnh thức. |
16:15 |
Dyrcona |
That's what seems to be causing the problem. |
16:15 |
rfrasur |
oh...that's not what I was expecting. |
07:47 |
dbs |
paxed: a major part of the value of review & sign-off is reproducing the before / after behaviour in a separate environment, as well as ensuring nothing else breaks unexpectedly as a result. so, not really :/ |
07:48 |
* dbs |
is enjoying Canada Day, apparently |
07:51 |
paxed |
dbs: disheartening. |
07:53 |
dbs |
paxed: it's a time vs. quality thing. We keep on seeing what happens when we push commits that "look good" without actually testing them. |
07:53 |
dbs |
Or testing them in a very limited way. And testing in production, really, really sucks for the community. |
07:54 |
csharp |
bshum: thanks! |
07:57 |
csharp |
dbs: happy Canada Day! |
07:58 |
csharp |
not a holiday I take it? ;-) |
08:01 |
csharp |
dbs: ah - I see ;-) |
08:03 |
|
jasonb-iph joined #evergreen |
08:03 |
jcamins |
dbs: have you looked at things like gerritt? |
08:06 |
dbs |
jcamins: it's more about testing & reproducing UI behaviour (selenium etc) than code review tools |
08:07 |
|
Dyrcona joined #evergreen |
08:08 |
jcamins |
dbs: ah. We have both problems with Koha. |
08:10 |
dbs |
for example, paxed has a patch that affects 8 or so different dialogues in the staff client. testing that means setting up a clean testing environment, reproducing the problem conditions (possibily requiring setup of special data to provoke the problem), setting up the test env + patch, reproducing the corrected scenarios... and all of that gives us no guarantee that other scenarios haven't been negatively affected by the patch |
08:10 |
dbs |
jcamins: I'm not saying gerritt or the like wouldn't be helpful, just a different problem :) |
08:21 |
|
finnx joined #evergreen |
08:25 |
|
rjackson-isl joined #evergreen |
08:34 |
|
laque joined #evergreen |
18:12 |
|
konr_revmob joined #evergreen |
18:12 |
|
finn1 joined #evergreen |
18:13 |
|
finnx1 joined #evergreen |
18:14 |
konr_revmob |
Can I test whether, say, the infinite scroll functionality works in my website using evergreen, or its not the appropriate tool? |
18:15 |
|
finnx1 left #evergreen |
18:18 |
|
finnx1 joined #evergreen |
18:19 |
|
finnx1 left #evergreen |
07:21 |
|
Dyrcona joined #evergreen |
07:32 |
|
jboyer-isl joined #evergreen |
07:34 |
|
bkuhn joined #evergreen |
08:25 |
csharp |
okay - I'm back to troubleshooting my circ rule issue - the problem is that we have a rule based on a circ modifier called 'dvd' assigned to dvd items. When I use the find_circ_matrix_matchpoint test on an item, patron, and location on our production server, the correct rule matches. When I do the same test on our test server, it picks a different rule. |
08:25 |
csharp |
The only thing I've changed is linking a circulation limit set |
08:26 |
csharp |
the rule it selects on our test server is based on the item's marc type |
08:27 |
pastebot |
"csharp" at 204.193.129.146 pasted "circ policy matching descrepancy" (16 lines) at http://paste.evergreen-ils.org/34 |
08:27 |
csharp |
as you'll see in the paste, rule 159 no longer matches |
08:27 |
|
timf joined #evergreen |
08:30 |
Dyrcona |
@quote random |
08:30 |
pinesol_green |
Dyrcona: Quote #21: "< Dyrcona> Writing software is more fun than working." (added by csharp at 09:29 AM, November 29, 2011) |
08:36 |
|
kbeswick joined #evergreen |
08:37 |
csharp |
created CSVs of a dump of circulation policies on test and production and diffed them - no difference |
08:39 |
csharp |
btw - test image is from 6/26, so no substantial differences between the datasets |
08:40 |
|
finnx joined #evergreen |
08:43 |
|
mmorgan joined #evergreen |
08:47 |
Dyrcona |
csharp: I've not ever seen the behavior you described in my environment. If I check something out in production and in development, I get the same matchpoint. |
09:26 |
csharp |
I'm using the Default weightset, which has worked fine for us until now |
09:28 |
* bshum |
checks to see what that is :) |
09:33 |
pastebot |
"csharp" at 204.193.129.146 pasted "default weightset" (7 lines) at http://paste.evergreen-ils.org/35 |
09:36 |
bshum |
csharp: Can you paste the rules 139 and 159 from your test server? |
09:36 |
bshum |
Curious to see what the rows look like. |
09:37 |
pastebot |
"csharp" at 204.193.129.146 pasted "more details on circ limit set setup" (43 lines) at http://paste.evergreen-ils.org/36 |
09:37 |
|
rfrasur joined #evergreen |
09:38 |
csharp |
I'll paste 139 too |
09:38 |
pastebot |
"csharp" at 204.193.129.146 pasted "circ matrix matchpoint 139" (4 lines) at http://paste.evergreen-ils.org/37 |
09:39 |
bshum |
What's the copy location of the item you're testing? |
09:39 |
bshum |
Just the first thing that jumped out to me looking at rule 159 |
09:39 |
|
remingtron joined #evergreen |
09:39 |
bshum |
Hopefully 7404 |
09:39 |
csharp |
we don't use copy locations in our rules since copy locations are managed at the library level |
09:40 |
csharp |
that would multiply our number of rules exponentially |
09:40 |
bshum |
But 7404 is in the column for "copy_location" in the paste. |
10:03 |
bshum |
Just thinking aloud, but it seems bad to allow copy location to be set for a specific library if they're also creating consortium level rules (or rules in general that affect greater than just them). |
10:03 |
csharp |
Indiana's still using script-based circ too, I think |
10:04 |
* csharp |
agrees |
10:04 |
bshum |
Since we don't let end users create policy, I don't think we've ever tested restricting the level of rules they can create. |
10:04 |
rfrasur |
csharp: yes...I think we are (because it breaks from time to time) |
10:04 |
bshum |
Or if that's possibly restricted by permission. |
10:12 |
rfrasur |
So, explain to me while I'm editing a million call #s - why not to use the "circ as type" attribute? |
10:17 |
rfrasur |
hmm, our circ policies are based on circ modifiers |
10:17 |
rfrasur |
meh |
10:17 |
jeff_ |
But those incorrect bibs should still be fixed -- because the copy-level override for circulate as type will do nothing to fix the other issues caused by the incorrect MARC data -- mostly with searching and display in the catalog. |
10:17 |
dbs |
paxed's fixes in bug 1195334 looks like it's probably golden, but because we lack any sort of UI test automation to reproduce the problems before the patch and show that it's fixed after the patch, I'm reluctant to wade into applying & testing it myself |
10:17 |
pinesol_green |
Launchpad bug 1195334 in Evergreen "Some data URIs don't define character set" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1195334 |
10:18 |
dbs |
and without testing, I'm not going to commit anything. Which is a major part of our QA problem in a nutshell, methinks. (surprise, broken record, whatever) |
10:22 |
mrpeters |
is there any way to test a LONG (14 day) grace period without checking out an item and waiting 2 weeks? --- using in-db circ |
10:24 |
mrpeters |
i suppose i could check out an item for 1 day and see if it accrues fines over the weekend... |
10:26 |
bshum |
mrpeters: I haven't tried it recently, but I think you could edit the circulation entry to be in the past, like 10 days past due or whatnot. |
10:26 |
Dyrcona |
mrpeters: Check it out and change the due date to the past? |
10:26 |
bshum |
mrpeters: Through the DB |
11:25 |
jeff_ |
k. |
11:25 |
jeff_ |
i forget that reports have debug output now. :-) |
11:25 |
mrpeters |
ya itsnice |
11:26 |
* rfrasur |
is running a test report (obviously not the same one...but similar) |
11:26 |
rfrasur |
so...in a couple hours.... |
11:28 |
mrpeters |
http://pastie.org/private/af01zwkuj3hikoucyobttg |
11:30 |
rfrasur |
(is it just me or are Indiana reports taking longer and longer and longer to generate?) |
11:33 |
mrpeters |
big database.... |
11:38 |
mrpeters |
they all look like normal circs.....except the "migrated" ones have no due date |
11:39 |
mrpeters |
http://imageshack.us/a/img838/5477/auvn.png |
11:39 |
|
collum joined #evergreen |
11:39 |
jeff_ |
mrpeters: er, that contains patron data. |
11:39 |
jeff_ |
unless those are test users. |
11:40 |
mrpeters |
yeah, guess i better obscure that |
11:40 |
mrpeters |
image deleted |
11:41 |
mrpeters |
http://imageshack.us/a/img834/102/hj51.png |
13:57 |
* rfrasur |
is def not THAT cool |
13:58 |
bshum |
jeff_: I have multiple accounts to LP but only get notifications to one as well. I don't think it sends to more than one. |
13:58 |
bshum |
Since you're cool and have gapps though, you could probably setup a filter to find LP emails and forward them on and only those. |
14:05 |
hopkinsju |
jeffdavis: I added CASCADE to the upgrade script and it completed successfully. It took quite a while but I'm finally done upgrading this test DB to 2.4. OPAC searching is being weird though... |
14:05 |
hopkinsju |
Searching takes forever and so far I'm seeing queries that should return results not returning any results on the first try, but oddly returning them on the second attempt. |
14:05 |
rfrasur |
Hah! One of those two staff members is already GOING to GenCon (no money from lib needed) |
14:06 |
hopkinsju |
I need to have a better way to test that the db upgrades *really* worked well. |
14:07 |
bshum |
hopkinsju: Returning on the second attempt sounds like the query ran long and didn't finish till later. And it being cached. |
14:07 |
hopkinsju |
bshum: Makes sense |
14:07 |
Dyrcona |
hopkinsju: You probably have to reingest. |
14:27 |
dbs |
GIN takes more space, more time to build, but is faster |
14:27 |
bshum |
faster++ |
14:27 |
* csharp |
peruses http://www.postgresql.org/docs/9.1/static/textsearch-indexes.html |
14:27 |
jeffdavis |
metabib_title_field_entry_index_vector_idx is a GIN index on our upgraded 2.4 test db |
14:27 |
dbs |
and will be required if oleg / alex gets their super-fast text search patches in |
14:27 |
rfrasur |
faster++ |
14:27 |
* Dyrcona |
has had some recent experience with faster in a different context. |
16:09 |
* bshum |
ponders how safe it is to make a copy of m_* migration schemas and then drop them from production DBs. |
16:09 |
rfrasur |
you live dangerously, remember? |
16:10 |
* rfrasur |
does payroll and prepares to be entertained by bshum living dangerously. |
16:10 |
bshum |
rfrasur: You've got a point. And hey that's what test databases are for right? :D |
16:11 |
rfrasur |
bshum: that's exactly right. |
16:11 |
* rfrasur |
cues music https://www.youtube.com/watch?v=7nqcL0mjMjw |
16:13 |
|
stevenyvr2 joined #evergreen |