| 08:25 |
csharp |
heh |
| 08:25 |
bshum |
That's what led me to poke at it. |
| 08:26 |
bshum |
If I have a moment later this morning, I'll dust off my branch. |
| 08:27 |
csharp |
I believe 'LEFT JOIN actor.card circ_card ON circ_u.card = circ_card.id' will accomplish what I'm trying to fix |
| 08:27 |
csharp |
since users can have multiple active cards now too |
| 08:27 |
* csharp |
is testing the view query now |
| 08:28 |
csharp |
oh, and for the logs, we're discussing bug 1072892 |
| 08:28 |
pinesol_green |
Launchpad bug 1072892 in Evergreen "reporter.classic_item_list view creates repeated rows" (affected: 1, heat: 6) [Undecided,Incomplete] https://launchpad.net/bugs/1072892 |
| 08:28 |
bshum |
csharp++ |
| 08:29 |
|
kbeswick joined #evergreen |
| 10:11 |
csharp |
eeevil: thanks - I'll look into window functions |
| 10:12 |
|
CarrieC joined #evergreen |
| 10:17 |
pastebot |
"eeevil" at 204.193.129.146 pasted "possible replacement for csharp" (9 lines) at http://paste.evergreen-ils.org/14 |
| 10:17 |
csharp |
eeevil++ |
| 10:18 |
csharp |
I'll test it |
| 10:18 |
eeevil |
csharp: there are many more than that one to convert, of course. and I'm testing on an empty db, so the syntax works but we may need to add window range conditions |
| 10:18 |
csharp |
good to know |
| 10:25 |
|
mcooper joined #evergreen |
| 10:26 |
csharp |
eeevil: that returns a list of rows rather than a single row (though the last one has the correct total owed) |
| 13:15 |
|
kmlussier joined #evergreen |
| 13:19 |
csharp |
eeevil: I've been working on the other money views. The only ones I'm unsure how to approach conversion with are money.billable_xact_summary_new and money.billable_xact_with_void_summary since they are pretty complicated with subqueries |
| 13:20 |
|
dboyle joined #evergreen |
| 13:24 |
eeevil |
csharp: I don't have time to look currently, but I would say toss the ones you have up as a branch for testing and signoff and we can address the remainders later |
| 13:24 |
eeevil |
csharp++ |
| 13:25 |
csharp |
will do - thanks for your help! |
| 13:26 |
|
Dyrcona joined #evergreen |
| 13:35 |
|
timf joined #evergreen |
| 09:01 |
|
ericar joined #evergreen |
| 09:08 |
|
sborger joined #evergreen |
| 09:19 |
|
kmlussier1 joined #evergreen |
| 09:21 |
mmorgan |
jboyer-isl: your suggestion to delete rows from the action_trigger.event table worked, I was able to rerun my test trigger. Thanks! |
| 09:22 |
jboyer-isl |
Good to hear. maybe now I can clean up some of the failed events that are sitting around in ours. :D |
| 09:29 |
|
mcooper joined #evergreen |
| 09:33 |
bshum |
So I'm getting some javascript errors on large pull lists when using the "Clear Hold Shelf" option directly off the Circulation menu actions. |
| 14:13 |
dbwells |
jeff_: Let me know whenever you are done with your latest NCIP commits, and I will pull those into the jonscott repo right away. |
| 14:13 |
jeff_ |
dbwells: thanks! |
| 14:14 |
jeff_ |
dbwells: are you guys using the duplicate message detection? i've removed it in https://github.com/tadl/iNCIPit/commit/537b6a763ae6ec1a48d1bd9439daa177436f3bf1 |
| 14:15 |
dbwells |
jeff_: If your testing shows it should be removed, I have no issue with removing it. |
| 14:21 |
|
sseng joined #evergreen |
| 14:22 |
Dyrcona |
FWIW, I thought it should be removed the first time that I tried testing iNCIPit. |
| 14:24 |
jeff_ |
In testing, we rarely received duplicate messages (other than those that were legit retries after a failure to respond properly). The duplicate message detection was apparently due to an old issue that is no longer an issue, and it can cause problems such as failure to auth the same patron twice in a row. |
| 14:24 |
jeff_ |
Also, it would require shared storage or a modification to use memcache to work in multi-server environments, so I was pleased when told by MeLCat staff that it should no longer be needed. :-) |
| 14:26 |
|
bshum joined #evergreen |
| 14:28 |
|
rfrasur joined #evergreen |
| 14:29 |
bshum |
Am I back? Maybe... |
| 15:45 |
jventuro |
I was wondering the same thing about email requests. Should I have requesters respond to the list, or directly to me. |
| 15:45 |
|
AaronZ-PLS joined #evergreen |
| 15:46 |
jventuro |
I have no problem with doing that, chtrotter. I am the list admin :) |
| 15:46 |
AaronZ-PLS |
Looking for an action trigger hook to send a test email every day, is there one that would work? |
| 15:47 |
jventuro |
Hi AaronZ-PLS. We're having a meeting at the moment. Would you mind tabling your question for 15 minutes or so? |
| 15:48 |
AaronZ-PLS |
Willdo. |
| 15:49 |
jventuro |
Thanks! |
| 16:16 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-07-30-15.00.html |
| 16:16 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-07-30-15.00.txt |
| 16:16 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-07-30-15.00.log.html |
| 16:17 |
AaronZ-PLS |
Looking for an action trigger hook to send a test email every day, is there one that would work? |
| 16:21 |
paxed |
AaronZ-PLS: if you just want to send a test email, you could just invoke mail directly from crontab ...? |
| 16:21 |
AaronZ-PLS |
paxed: Could do that, but looking to make action triggers arent hanging as well as making sure email is happy from end to end |
| 16:36 |
gsams |
AaronZ-PLS: I know it wouldn't be quite as informative, but the mail log should be a pretty good indication of whether action triggers are working or not. I can't say that I've tried looking into it in any other way myself. |
| 17:11 |
|
smyers_ joined #evergreen |
| 14:00 |
jeff |
email and IM are poor methods of revision control. |
| 14:01 |
Dyrcona |
Yes, they are. |
| 14:01 |
Dyrcona |
I use git as a sort of distribution mechanism, too. |
| 14:02 |
Dyrcona |
I edit the code on the laptop and then push to the server to test it. |
| 14:02 |
* jeff |
nods |
| 14:07 |
jeff |
fieldmapper alias typos are one of those "probably really difficult to fix" things. |
| 14:09 |
Dyrcona |
Could be.... |
| 14:56 |
yboston |
Dyrcona: Thanks. I guess setting active=false could be helpful if I change my mind so it is easy to reinstate? any other reasons off the top of your head? |
| 14:56 |
Dyrcona |
yboston: It's just what I typically do rather than delete. |
| 14:57 |
yboston |
Dyrcona: thanks for the info and sharing your preferred workflow |
| 14:57 |
kmlussier |
Dyrcona++ |
| 14:57 |
kmlussier |
I forgot include you in all the thanks I sent yesterday when signing off on the bib browse code, so I'm sending along karma now instead. |
| 14:58 |
kmlussier |
Dyrcona can not get enough good karma for all the assistance he gives me when I'm testing code. :) |
| 15:18 |
csharp |
@karma Dyrcona |
| 15:18 |
pinesol_green |
csharp: Karma for "Dyrcona" has been increased 382 times and decreased 3 times for a total karma of 379. |
| 15:31 |
|
mrpeters left #evergreen |
| 15:41 |
|
zerick joined #evergreen |
| 15:52 |
mmorgan |
I'm trying to test an action trigger. Is there a recommended way to remove rows from the database so I can tweak and retest? |
| 16:06 |
jboyer-isl |
mmorgan: A guess I'm thinking of testing soon: delete from action_trigger.event where event_def=(The event id you're testing). You could add additional clauses for add_time, state, etc. if needed. |
| 16:07 |
|
smyers_ joined #evergreen |
| 16:08 |
jboyer-isl |
but note that I've not tried it yet. |
| 16:10 |
mmorgan |
Thanks, anything I try will be on a test server :). Will deleting the row from action_trigger.event also remove rows from action_trigger.event_output? |
| 16:10 |
mmorgan |
or can those just stay there and not bother anybody? |
| 16:10 |
jboyer-isl |
Ah, I doubt it. |
| 16:10 |
|
rfrasur joined #evergreen |
| 16:10 |
jboyer-isl |
Cleaning them up might make testing easier, if that's where you're looking for success/failure. |
| 16:14 |
mmorgan |
Good point. I will give this a try on a test server, but maybe not til Monday. Thanks! |
| 16:16 |
bshum |
In the old days, we used to just put complete times on unfinished A/T events |
| 16:16 |
bshum |
And change the status |
| 16:17 |
bshum |
But deleting is also simple too. |
| 16:20 |
mmorgan |
I'm fine with updating rather than deleting. I'm testing notices and want to be able to run the same trigger again for the same user. |
| 16:23 |
mmorgan |
events for the event_def I'm working with have status complete but complete_ time of null. Can I update these fields to get it to run again after I make changes to the template? |
| 16:25 |
|
jdouma joined #evergreen |
| 16:25 |
|
kbeswick joined #evergreen |
| 16:30 |
|
jdouma joined #evergreen |
| 16:31 |
|
mcooper joined #evergreen |
| 16:36 |
|
smyers_ joined #evergreen |
| 16:46 |
|
shadowspar joined #evergreen |
| 16:49 |
bshum |
mmorgan: Hmm, I'd say, probably |
| 16:50 |
bshum |
I think we used to do that when we were testing acq EDI |
| 16:50 |
bshum |
And it would error out |
| 16:50 |
bshum |
So we'd tweak things, then null out the output and complete stuff and try again |
| 16:54 |
mmorgan |
Thanks! I'll look at that on Monday, too. Don't want to try anything new on a database on a Friday afternoon. |
| 16:55 |
kmlussier |
mmorgan: Go home and enjoy the beautiful weather! ;) |
| 16:55 |
mmorgan |
What beautiful weather?? Where?? It's quite gray out my window! |
| 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 |
| 18:50 |
bshum |
Well the popup worked |
| 18:50 |
bshum |
Generated an alert that asks me to verify the hold upon checkin |
| 18:51 |
bshum |
So I don't think there's a problem there. |
| 18:52 |
bshum |
gsams: Maybe there was something weird with the hold and doing that find another target helped move it on the right path again. |
| 18:52 |
bshum |
And that hold verify on the copy location wasn't involved. |
| 18:52 |
bshum |
Though good to check and make sure it's what the library wants. |
| 18:53 |
gsams |
I did all of those steps before turning it off and it didn't have that behavior then |
| 18:53 |
bshum |
Very weird. |
| 18:53 |
gsams |
indeed. I'll take a thorough look into it tonight if I get a chance |
| 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 <berick esilibrary.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> |
