| Time |
Nick |
Message |
| 00:19 |
|
nhilton joined #evergreen |
| 01:15 |
|
mrpeters left #evergreen |
| 06:14 |
|
mtate joined #evergreen |
| 06:14 |
|
eeevil joined #evergreen |
| 06:15 |
|
phasefx joined #evergreen |
| 06:15 |
|
maryj joined #evergreen |
| 06:15 |
|
BigRig joined #evergreen |
| 06:15 |
|
TaraC joined #evergreen |
| 06:15 |
|
Callender joined #evergreen |
| 06:16 |
|
graced joined #evergreen |
| 06:17 |
|
bmills joined #evergreen |
| 07:34 |
|
sarabee joined #evergreen |
| 07:53 |
|
ericar joined #evergreen |
| 08:06 |
|
_bott_ joined #evergreen |
| 08:15 |
kmlussier |
eeevil: I'll see if I can get some end user testing here on webby for those web client fixes. |
| 08:26 |
|
rjackson-isl joined #evergreen |
| 08:31 |
|
Shae joined #evergreen |
| 08:34 |
|
abowling joined #evergreen |
| 08:37 |
|
collum joined #evergreen |
| 08:51 |
|
gmcharlt joined #evergreen |
| 08:56 |
|
akilsdonk joined #evergreen |
| 09:12 |
|
Dyrcona joined #evergreen |
| 09:16 |
Dyrcona |
I should probably ask in #launchpad, but does the Hide function in comments actually hide it from everyone or just from your current session? |
| 09:16 |
Dyrcona |
I thought it only did the latter. |
| 09:17 |
kmlussier |
Dunno. Send me a link to a Launchpad bug where you hid a comment and I'll let you know if I can see it. :) |
| 09:18 |
Dyrcona |
kmlussier: That's OK. It's academic at this point. |
| 09:18 |
kmlussier |
If it only hides it from you for a given session, it seems rather useless. |
| 09:18 |
Dyrcona |
Also, is launchpad based on MoinMoin? If not, the help search is just as bad as regular search. |
| 09:19 |
Dyrcona |
kmlussier: Agreed, but I've seen less useful features implemented on web sites before. |
| 09:21 |
Dyrcona |
Apparently, the help search is just as bad as regular launchpad search. |
| 09:22 |
Dyrcona |
Ah. The help is based on MoinMoin wiki.... |
| 09:22 |
Dyrcona |
So, I when I search for help on comments, I got the help for the comments on MoinMoin. Still not useful. |
| 09:23 |
Dyrcona |
+1 to ditching Launchpad for just about anything else, even a set of index cards stored in a disused Kensington lavatory with a sign on the door saying beware of leopard. |
| 09:25 |
collum |
http://blog.launchpad.net/general/you-can-hide-your-bug-and-question-comments |
| 09:25 |
collum |
Is that what you were looking for Dyrcona? |
| 09:26 |
Dyrcona |
Probably, but I expected to find something at help.launchpad.net. Not very helpful to have to look up a blog post. |
| 09:26 |
collum |
agreed |
| 09:28 |
Dyrcona |
collum++ |
| 09:28 |
Dyrcona |
Thanks that answers my question. |
| 09:28 |
Dyrcona |
I tried hiding a comment and when I could still see it, I wasn't sure if it was universally hidden or not. |
| 09:29 |
Dyrcona |
Anyway........ |
| 09:32 |
|
jeff___ joined #evergreen |
| 09:32 |
|
yboston joined #evergreen |
| 09:34 |
Dyrcona |
Guess there were net splits last night, eh? |
| 09:35 |
bshum |
Just a few. :) |
| 09:46 |
|
Stompro joined #evergreen |
| 09:48 |
|
mllewellyn joined #evergreen |
| 09:49 |
* csharp_ |
wonders if export from launchpad is even possible |
| 09:51 |
|
csharp joined #evergreen |
| 09:52 |
kmlussier |
I wonder how quickly you have to hide the comment to prevent it from being sent out to everyone who subscribes to that bug. |
| 09:55 |
Dyrcona |
Probably right away. |
| 09:55 |
Dyrcona |
There's more than just email, btw. |
| 09:56 |
Dyrcona |
There's RSS, XMPP, and other syndication methods. |
| 09:57 |
* kmlussier |
nods. |
| 09:58 |
Dyrcona |
Apparently the hid function was added as a compromise with people who wanted to be able to delete or edit comments after they were posted. |
| 09:58 |
Dyrcona |
s/(hid)/\1e/ |
| 10:10 |
dbs |
csharp: export has been possible for years; there's an API |
| 10:14 |
csharp |
dbs: ah - good to know |
| 10:14 |
csharp |
Dyrcona++ # writing and sharing scripts to make upgrades actually doable ;-) |
| 10:15 |
* csharp |
is finishing pingest.pl and moving on to the authority linker batcher/disbatcher shortly |
| 10:17 |
csharp |
Dyrcona: speaking of, have you ever hit a limit on the number of batched authority processes that could be run concurrently? I would love to run 24 batches at the same time. |
| 10:18 |
Dyrcona |
I've never hit a limit, but I think I've only ever run about 8 at once. |
| 10:18 |
dbs |
pingest.pl++ |
| 10:18 |
csharp |
that helps to know |
| 10:18 |
dbs |
Dyrcona++ |
| 10:18 |
Dyrcona |
I generally do number of cores on db server divided by 2. |
| 10:18 |
csharp |
yeah - that's what I'm doing here |
| 10:18 |
csharp |
it's a beefy DB server ;-) |
| 10:20 |
Dyrcona |
You could likely get away with more if you do it in the "off" hours. |
| 10:20 |
csharp |
we're totally down, so maybe I'll try 32 |
| 10:20 |
* csharp |
laughs evilly |
| 10:20 |
jboyer-isl |
It's particularly fun to use cores-1, provided it has the RAM to pull it off. |
| 10:20 |
csharp |
jboyer-isl: daredevil! |
| 10:21 |
jboyer-isl |
I like to test ACID compliance, keep postmaster on it's toes, etc. :D |
| 10:21 |
* berick |
waits for a 'top' screenshot |
| 10:22 |
csharp |
ERROR: not enough room on screen |
| 10:22 |
berick |
says it all |
| 10:22 |
csharp |
it's what we all aspire to |
| 10:29 |
|
nhilton joined #evergreen |
| 10:39 |
|
mrpeters joined #evergreen |
| 10:42 |
jboyer-isl |
Ugh, Seq Scan on circulation, Seq Scan on copy, this report is a horror show. |
| 10:43 |
jboyer-isl |
Lots of research to do, apparently. |
| 10:52 |
jboyer-isl |
csharp, I just had a thought re: pg replication vs slony. Are all of your DBs running the same (or similar) hardware? |
| 10:53 |
csharp |
jboyer-isl: yes - identical |
| 10:53 |
jboyer-isl |
Since we have such lopsided power on our primary vs. reports I think we've got some bad query plans floating around because the primary can do whatever while our reporter is practically an antique. |
| 10:53 |
csharp |
that wasn't the case before this past year though |
| 10:53 |
jboyer-isl |
Ah, you should be all set in either case then. |
| 11:05 |
|
nhilton joined #evergreen |
| 11:06 |
|
bmills joined #evergreen |
| 11:07 |
|
chatley_ joined #evergreen |
| 11:10 |
|
chatley__ joined #evergreen |
| 11:20 |
|
RoganH joined #evergreen |
| 11:25 |
RoganH |
We don't actually need holds policies do we? They like they just suppress the proletariat. |
| 11:26 |
kmlussier |
RoganH++ |
| 11:28 |
* dbs |
needs to investigate why opportunistic hold capturing seems to not be happening after our 2.4->2.7 upgrade |
| 11:29 |
|
vlewis joined #evergreen |
| 11:38 |
eeevil |
dbs: one thing to confirm: is action.hold_copy_map.prox populated? |
| 11:38 |
|
nhilton joined #evergreen |
| 11:45 |
dbs |
94 entries in that table, I'll dig further |
| 11:47 |
dbs |
ah, it was not populated for one of the holds that was not captured |
| 11:47 |
dbs |
and the hold was placed after we migrated. Interesting. |
| 11:48 |
eeevil |
disabled trigger? |
| 11:48 |
eeevil |
(or missing trigger) |
| 11:48 |
dbs |
Or not existing trigger |
| 11:48 |
dbs |
yeah, seems to be missing |
| 11:51 |
* dbs |
peers at 090.schema.action.sql |
| 11:53 |
dbs |
didn't have hold_request_clear_map_tgr but that's not the droid I'm looking for anyway |
| 11:53 |
dbs |
hold_request_clear_map_tgr does not appear in sql/Pg/version-upgrade. ruh roh |
| 11:53 |
eeevil |
boo |
| 11:54 |
eeevil |
there's supposed to be a trigger on action.hold_copy_map that populates prox |
| 11:54 |
dbs |
so upgrade/0902.schema.clear_hold_copy_map.sql got missed |
| 11:54 |
eeevil |
that's the droid you're looking for, I think |
| 11:54 |
dbs |
yes, clearly there's another missing trigger :) |
| 11:55 |
berick |
hm, i don't think hold_request_clear_map_tgr is in 2.7 |
| 11:55 |
gmcharlt |
the saga of the lonely droid, the one nobody is looking for... |
| 11:56 |
dbs |
upgrade/0869.schema.pre-calculate-prox-adjustment.sql perhaps |
| 11:56 |
dbs |
oh yeah, should be looking at rel_2_7 not master. heh |
| 11:59 |
dbs |
2.5.3-2.5.4-upgrade-db.sql contains hold_copy_proximity_update_tgr |
| 12:01 |
dbs |
and I already had that anyway |
| 12:01 |
* dbs |
shakes head |
| 12:02 |
dbs |
So is action.hold_copy_map not populated by database triggers? |
| 12:04 |
berick |
dbs: hold targeter API |
| 12:04 |
* dbs |
grepped all perlmods for ahcm and found reads only |
| 12:04 |
dbs |
okay |
| 12:05 |
berick |
new_hold_copy_targeter is the sub, i believe |
| 12:05 |
eeevil |
dbs: are you using proximity adjustment, and if not, is action.org_unit_proximity populated? |
| 12:06 |
dbs |
ah, was being too fancy expecting database-level logic / ahcm-only in code references |
| 12:07 |
|
b_bonner joined #evergreen |
| 12:08 |
|
rashma_away joined #evergreen |
| 12:08 |
|
mnsri_away joined #evergreen |
| 12:08 |
dbs |
actor.org_unit_proximity is indeed populated |
| 12:08 |
dbs |
AFAIK we're not using proximity adjustment |
| 12:09 |
dbs |
We are still using scripts though! Which is always fun. |
| 12:09 |
|
julialima_ joined #evergreen |
| 12:16 |
|
mtcarlson joined #evergreen |
| 12:39 |
kmlussier |
berick/eeevil: For commit b577d39, is there a specific bug with dates being fixed that we should be testing for? |
| 12:39 |
kmlussier |
Hmm...I thought that would bring up the commit if I typed it that way. |
| 12:39 |
|
buzzy joined #evergreen |
| 12:39 |
berick |
kmlussier: it's not a bug |
| 12:39 |
berick |
it's part of the noncat circ display |
| 12:39 |
berick |
(and eventually other things) |
| 12:39 |
kmlussier |
berick: OK, I see, thanks! |
| 12:40 |
kmlussier |
I may be asking more questions like that one as I go through this list. :) |
| 13:04 |
|
jihpringle joined #evergreen |
| 13:24 |
|
mrpeters left #evergreen |
| 13:25 |
|
nhilton_ joined #evergreen |
| 13:29 |
|
nhilton joined #evergreen |
| 13:33 |
kmlussier |
julialima_++ #Nice updates at http://lima-julia.tumblr.com/ |
| 13:34 |
julialima_ |
:) |
| 13:34 |
|
Shae joined #evergreen |
| 13:38 |
|
mrpeters joined #evergreen |
| 13:41 |
mrpeters |
what is current reccomended xulrunner for 2.72? (building a mac client) |
| 13:45 |
berick |
mrpeters: 14.0.1 |
| 13:45 |
mrpeters |
thanks berick! |
| 13:45 |
eeevil |
kmlussier++ # testing! :) |
| 13:57 |
|
nhilton_ joined #evergreen |
| 13:59 |
|
Sally joined #evergreen |
| 14:21 |
dbs |
julialima++ # great stuff |
| 14:25 |
julialima_ |
dbs: Thank you! |
| 14:37 |
jeffdavis |
We've had a request to optionally allow patrons to renew items when they've hit their max fine amount. "Optionally" as in some of our libraries want this to be possible and some don't. |
| 14:38 |
jeffdavis |
I was thinking of modifying the action.item_user_circ_test db function so that, if the patron has the PATRON_EXCEEDS_FINES penalty, EG checks an org setting to decide whether to override the block and permit the renewal. |
| 14:38 |
Dyrcona |
jeffdavis: Kick the ones who want to out of the consortium. :) |
| 14:38 |
jeffdavis |
Dyrcona: True, the easiest solution to many problems would be to have no patrons and no member libraries. :) |
| 14:38 |
jeffdavis |
Does that approach seem reasonable, or am I opening a can of worms there? |
| 14:39 |
jeffdavis |
(The actual suggested approach, not getting rid of all users.) |
| 14:39 |
Dyrcona |
I'd have to give it some more thought. |
| 14:40 |
Dyrcona |
My initial reaction was to create a new penalty for exceeds fines that doesn't block renewals, but then you'd have to figure out how to apply it. |
| 14:40 |
Dyrcona |
Another question is who decides, the library doing the renewal, the library that applied the block, or the library that owns the item? |
| 14:41 |
Dyrcona |
Though, I guess a library doesn't apply the block does it? |
| 14:42 |
Dyrcona |
We can change that to "the library that circ'd the item." |
| 14:42 |
jeffdavis |
Yeah, basing it on circ lib's org setting was my thinking. |
| 14:43 |
kmlussier |
"[TADL] also happens to be the most user-friendly and inviting Evergreen catalog landing page out there, at least of the ones I’ve seen." Did you see that jeff? :) |
| 14:44 |
* Dyrcona |
didn't see that, and I cannot say that I disagree. Where did that come from? |
| 14:45 |
Dyrcona |
jeffdavis: I can see how others might want to base it on who owns the copy or something else, but I hesitate to suggest another setting or flag for that. |
| 14:45 |
kmlussier |
Dyrcona: The general list. Alexey's email regarding call number shelf browse. |
| 14:45 |
Dyrcona |
kmlussier: OK. I likely haven't read that one yet. |
| 14:47 |
jeff |
kmlussier: thanks for calling that out. i've been reading that thread but apparently am not current. |
| 14:49 |
|
nhilton joined #evergreen |
| 14:52 |
kmlussier |
eeevil / berick: If you're still around, there were 4 bug fixes mentioned in Mike's most recent bug repairs comment that I was unsure on what to test for. http://pastebin.com/r21hv2ke |
| 14:53 |
kmlussier |
Some may be related to other fixes to be tested there, but I just want to make sure I'm not missing anything. |
| 14:53 |
berick |
kmlussier: for "Repair browser client dropdown buttons" -- it's an issue that would only appear on a fairly new server |
| 14:54 |
|
mrpeters left #evergreen |
| 14:54 |
berick |
in the grids, the Actions drop-down buttons don't work w/o the patch |
| 14:54 |
berick |
making sure they still work on older servers would be helpful, thoug |
| 14:54 |
berick |
h |
| 14:54 |
kmlussier |
berick: Ok. So the 1st isn't something I can really test for on webby? |
| 14:55 |
berick |
checking Actions dropdowns in Webby to make sure the change didn't introduce a problem would be good |
| 14:55 |
kmlussier |
berick: Sure, that we can do. :) |
| 14:55 |
berick |
kmlussier: for "Avoid org tree retrieval race condition on patron app" -- without this patch, pages would sometimes fail to load with a JS error. if you never saw the problem before, it's not really testable, apart from "hey, pages load!" |
| 14:56 |
* kmlussier |
doesn't recall seeing that problem and therefore won't worry about it. |
| 14:59 |
RoganH |
kmlussier: it's like evolution, you can always deny it and make your own reality |
| 15:03 |
kmlussier |
RoganH: :) |
| 15:05 |
jeffdavis |
"... as Karl Rove once aptly observed." |
| 15:14 |
jeffdavis |
I created bug 1411819 (is there a way to mark it as a feature request?). |
| 15:14 |
pinesol_green |
Launchpad bug 1411819 in Evergreen "Allow patron renewal on max fines for some libraries, disallow it for others" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1411819 |
| 15:15 |
jeff |
jeffdavis: i set importance to "wishlist" -- that's the convention so far, iirc. |
| 15:15 |
jeffdavis |
thanks! |
| 15:15 |
dbs |
like bug 1411820 |
| 15:15 |
pinesol_green |
Launchpad bug 1411820 in Evergreen "Expose authority records with one or more public web interface" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1411820 |
| 15:15 |
* dbs |
pluralizes that |
| 15:16 |
jeffdavis |
I'm planning to have a "fix" for 1411819 by the end of the month. I outlined my proposal in the bug report but happy to hear about alternative approaches/objections. |
| 15:20 |
|
Sally joined #evergreen |
| 15:30 |
tsbere |
jeffdavis: An alternative might be another "result" field in the circ matrix for ignoring penalty blocks. Then you wouldn't be limited to just "by org unit" but could mix in other details like patron type. And easily cover item owning lib vs circ lib differences, for that matter. |
| 15:31 |
* tsbere |
shakes his fist at launchpad throwing login errors at him |
| 15:31 |
eeevil |
jeffdavis: I've been thinking about the hardcoded penalties for a while, actually, and was thinking that a "penalty event map" would be a good way to address it. each org could map an event to a penalty, including custom ones. it would default to the current hard-coded ones if no penalty was mapped |
| 15:31 |
Dyrcona |
tsbere jeffdavis: And, though most ignore it, there is a is_renewal flag on circ_matrix_matchpoints, so it could apply only to renewals. |
| 15:38 |
eeevil |
kmlussier: the third bug is part of another, I just didn't move it. it's the grid sorting feature |
| 15:39 |
eeevil |
kmlussier: the forth, there was a bug about how you could select, say, "current copy" on the hold pull list and it would show a pile of JSON data. now we hide that column from selection |
| 15:41 |
kmlussier |
eeevil: Thanks! |
| 16:06 |
* Dyrcona |
always feels like he should put "I" before this: DO $$DECLARE |
| 16:16 |
* dbs |
is pretty happy with current iteration of http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=shortlog;h=refs/heads/feature/in-database-marc-update which now handles an exception when enriching a MARC record, records the problem, and plugs along to the next record |
| 16:17 |
dbs |
(takes a given record, does a lookup using OCLC's xID service by LCCN, ISBN, or OCLC number, and adds any identifiers that might be missing so we can then link out to them) |
| 16:18 |
dbs |
along with other miscellaneous cleanup. going to take forever at the default 1,000 xID api calls per day though :) |
| 16:28 |
eeevil |
dbs: you should totally harass royt until he gets you an unlimited key |
| 16:29 |
dbs |
eeevil: heh, yeah, somehow I don't think he's interested in doing me any favours |
| 16:30 |
dbs |
"Dude I'm trying to use your API to show you how deficient WorldCat is from a discoverability perspective!" |
| 16:30 |
* dbs |
turns that around |
| 16:31 |
dbs |
"Dude I'm trying to use your API to show you via Evergreen how WorldCat discoverability could be even better!" |
| 17:59 |
|
buzzy joined #evergreen |
| 18:26 |
|
buzzy joined #evergreen |
| 18:30 |
|
edoceo joined #evergreen |
| 20:49 |
|
Sally joined #evergreen |
