| Time |
Nick |
Message |
| 01:11 |
|
zerick joined #evergreen |
| 01:44 |
|
stevenyvr2 joined #evergreen |
| 01:44 |
|
stevenyvr2 left #evergreen |
| 01:53 |
|
Mark__T joined #evergreen |
| 02:29 |
|
Callender joined #evergreen |
| 04:50 |
|
pinesol_green joined #evergreen |
| 06:43 |
|
b_bonner joined #evergreen |
| 06:43 |
|
mtcarlson_away joined #evergreen |
| 07:02 |
|
timf joined #evergreen |
| 07:24 |
|
jboyer-isl joined #evergreen |
| 07:38 |
|
rjackson-isl joined #evergreen |
| 07:59 |
|
Rish joined #evergreen |
| 08:17 |
|
akilsdonk_ joined #evergreen |
| 08:20 |
|
kmlussier joined #evergreen |
| 08:25 |
|
kbeswick joined #evergreen |
| 08:40 |
|
Shae joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:48 |
|
ericar joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:18 |
kmlussier |
@later tell eeevil Can the fix for bug 1174860 be applied to 2.3 too? The original bug was reported on a 2.3 system, but you only mentioned 2.4+ when you posted the branch. |
| 09:18 |
pinesol_green |
kmlussier: The operation succeeded. |
| 09:19 |
kmlussier |
https://bugs.launchpad.net/evergreen/+bug/1174860 |
| 09:19 |
pinesol_green |
Launchpad bug 1174860 in Evergreen "tpac: search filter groups don't play nicely with facets" (affected: 3, heat: 20) [Undecided,Triaged] |
| 09:24 |
|
mrpeters joined #evergreen |
| 09:30 |
|
yboston joined #evergreen |
| 09:37 |
|
mllewellyn joined #evergreen |
| 09:40 |
paxed |
anyone know why "Salt" shows up here: http://62.148.106.91/eg/opac/browse?bterm=0;qtype=title |
| 09:42 |
tsbere |
Because it is in your database, I presume... |
| 09:42 |
tsbere |
Perhaps there is a non-printable char before it? |
| 09:47 |
paxed |
doesn't look like it. |
| 09:48 |
|
joanne joined #evergreen |
| 09:52 |
|
RoganH joined #evergreen |
| 09:59 |
phasefx |
paxed: I think that's controlled by metabib.browse_entry? may be interesting to see the corresponding row for that and adjacent entries |
| 10:06 |
dbs |
@marc 130 |
| 10:06 |
pinesol_green |
dbs: A uniform title used as a main entry in a bibliographic record. [a,d,f,g,h,k,l,m,n,o,p,r,s,t,6,8] |
| 10:06 |
paxed |
phasefx: the first entry in the list, and Salt have metabib.browse_entry.sort_value of ... empty space? |
| 10:06 |
paxed |
ahhah |
| 10:07 |
dbs |
paxed: it's a 130 field, with a first indicator of 4 |
| 10:07 |
paxed |
yes, i just noticed |
| 10:07 |
dbs |
4 non-filing characters for a title with only four characters :) |
| 10:07 |
paxed |
yup |
| 10:07 |
|
mixo joined #evergreen |
| 10:08 |
paxed |
and the first entry has weird 2nd indicator. title is 'I' and we skip 2 chars. |
| 10:09 |
mixo |
hi. ihave problem with staff client. I can't book change status from transit to available. it says "template tried to change 'Status', wich is not allowd currently" |
| 10:10 |
mixo |
I can't change book status from transit to available. it says "template tried to change 'Status', wich is not allowd currently" |
| 10:11 |
mixo |
how can I fix this problem? |
| 10:17 |
phasefx |
mixo: you can either cancel the transit or check the item in at the location it wants to transit to. A Cancel option is available in the Item Status interface |
| 10:21 |
mixo |
thank you |
| 10:23 |
Dyrcona |
My question is why would one apply a template to a copy that exists and is in transit? I don't understand that work flow. |
| 10:26 |
|
akilsdonk_ joined #evergreen |
| 10:34 |
|
mrpeters joined #evergreen |
| 10:36 |
kmlussier |
paxed: Could it be the 130 field? It looks like you have 4 as the first indicator, which is used to set the number of nonfiling characters. |
| 10:36 |
kmlussier |
paxed: Oops. Sorry, I see dbs already answered it. |
| 10:37 |
dbs |
Might be nice to have a soft constraint for bad data situations like that. Not a real database constraint, which would reject records entirely, but perhaps an insert/update trigger that populated a "data quality problem" table for subsequent review. |
| 10:49 |
|
krvmga joined #evergreen |
| 10:49 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "For bshum RE Boopsie" (223 lines) at http://paste.evergreen-ils.org/10 |
| 10:50 |
krvmga |
all the mail about IRC, you'd think no one had ever heard of AOL chat rooms |
| 10:51 |
Dyrcona |
AOL? What's that? ;) |
| 10:51 |
* Dyrcona |
remembers eternal September, so needs no explanation. :) |
| 10:51 |
krvmga |
lol |
| 10:52 |
krvmga |
i'm sure that in my garage in my piles of "computer memorabilia" i have more than one AOL disk |
| 10:52 |
jeff |
Dyrcona++ always nice to see other approaches to the same thing |
| 10:52 |
Dyrcona |
bshum: What I pasted might actually make a good base for a new marc_export. Whaddya think? |
| 10:52 |
senator |
those free disks made good skeet |
| 10:53 |
Dyrcona |
skeet++ |
| 10:53 |
Dyrcona |
I reformatted and used some of their floppies back in the day. |
| 10:53 |
krvmga |
i taught people how to make ninja knives from them |
| 10:53 |
bshum |
Dyrcona: Hmm, certainly interesting. |
| 10:53 |
jeff |
when we were still using boopsie, we used bzip2 for compression, but other than that a pretty similar approach. :-) |
| 10:53 |
bshum |
Probably have to adapt some more of it, like changing the hardcoded bib source compares |
| 10:54 |
bshum |
But it does look nice and simple. |
| 10:54 |
Dyrcona |
bshum: yeah, the bib sources could be could configured. |
| 10:54 |
jeff |
in our case, we were doing more "do the bibs have holdings at these libraries and their descendants that aren't in an excluded circ mod / shelving location" |
| 10:55 |
bshum |
jeff: We were told to put holdings on our extracts for boopsie. The current marc_export tool takes us 16+ hours of sequential extraction to run. Less if I do it in parallel but still crazy long. |
| 10:55 |
jeff |
ouch. |
| 10:55 |
Dyrcona |
also, instead of using XML::XPath and my JSONPrefs it could be modified to do use the OpenSRF settings module. |
| 10:55 |
bshum |
And then they asked for it "weekly" or so |
| 10:55 |
jeff |
we were doing daily, iirc. |
| 10:56 |
bshum |
I think they wanted it daily, I got them to commit to weekly. And then I never ran more extracts because it took too darned long and I didn't want to burn my life on marc exporting. |
| 10:56 |
Dyrcona |
marc_export is just too damned slow, which is partly why I've never tried using it until recently. |
| 10:56 |
krvmga |
just so everyone knows, we've now turned off autosuggest in our catalog because of the accessibility issues |
| 10:56 |
Dyrcona |
bshum I run that program in a cron job every Sunday morning around 10 am. |
| 10:57 |
Dyrcona |
I think I will start with it as a basis for what I need for a new vendor. |
| 10:57 |
Dyrcona |
They have the option of doing full dumps or updates. |
| 10:59 |
jeff |
hrm. more hidden code. |
| 11:00 |
jeff |
our special-snowflake export scripts for melcat do similar, and i've thought "this would be handy to generalize" |
| 11:00 |
Dyrcona |
jeff: I've got another that is publicly available that I use for exporting records to Backstage. |
| 11:01 |
jeff |
in update files, we're expected to send a new bib with all the holdings on it when the status of any of the holdings changes. |
| 11:01 |
jeff |
so we maintain a copy status table in the reporting db. |
| 11:01 |
Dyrcona |
That's ridickerous! |
| 11:02 |
jeff |
update it where the current select doesn't match that copy's most recent status in the copy status table, then use that to select which bibs to extrat for the day's update. |
| 11:02 |
|
mrpeters joined #evergreen |
| 11:02 |
jeff |
Dyrcona: it was the best approach that i could come up with that met the requirements in the time allotted. :-) |
| 11:03 |
Dyrcona |
jeff Understood. I think the requirement is what is ridickerous. :) |
| 11:03 |
jeff |
aha! :-) |
| 11:03 |
jeff |
also, to avoid "we batch updated a bunch of copies into a new location that is not in-scope", the copy status table doesn't rely on acp.edit_time |
| 11:03 |
Dyrcona |
Anyway... I'll bounce back to work, and maybe start a git branch or repo for a new marc export tool. |
| 11:04 |
bshum |
Dyrcona++ |
| 11:04 |
|
zerick joined #evergreen |
| 11:04 |
dbs |
Dyrcona: yeah, I was thinking doing most of the export work in-database would probably be wayyyy faster |
| 11:07 |
dbs |
Going with in-database export logic would enable JDBC, Perl DBI, python-db, what have you for the front end with nice consolidated logic |
| 11:07 |
dbs |
And seems much more likely to keep pace with changes like parts, prefixes, etc than an external script |
| 11:08 |
bshum |
kmlussier: Hey I haven't complained about parts in awhile. Maybe this is a good sign? :) |
| 11:09 |
dbwells |
Dyrcona: possible Hack-a-Way project? Seems like a good style of project for such a thing, self-contained and universally applicable. |
| 11:09 |
|
dboyle joined #evergreen |
| 11:10 |
Dyrcona |
dbwells: I plan to work on NCIP at the hackaway, but maybe. |
| 11:10 |
kmlussier |
bshum++ |
| 11:10 |
Dyrcona |
bshum kmlussier Neither have I. |
| 11:12 |
eeevil |
kmlussier: re https://bugs.launchpad.net/evergreen/+bug/1174860 ... it applies without conflict to rel_2_3. I have not attemtped to test its efficacy in that situation, but I don't think it will hurt. if reordering the query so that user input is last and widget-derived input comes first makes your 2.3 tests work, then yes, it should be backported |
| 11:12 |
pinesol_green |
Launchpad bug 1174860 in Evergreen "tpac: search filter groups don't play nicely with facets" (affected: 3, heat: 20) [Undecided,Triaged] |
| 11:13 |
kmlussier |
eeevil: OK, thanks. I'll see if I can test it on a 2.3 system. |
| 11:17 |
|
csharp_mtg joined #evergreen |
| 11:17 |
csharp_mtg |
ssh_port_blocking_on_wifi-- |
| 11:20 |
dbs |
running_an_ssh_server_on_port_443++ |
| 11:21 |
_bott_ |
Any ideas on forcing items in transit to a different destination? Trying to manually move some items that have "over floated". Right now they just bag them up and send them, but I'd prefer that we actually track where they physically reside. |
| 11:21 |
csharp_mtg |
dbs: great idea! I think I'll set one up |
| 11:22 |
tsbere |
_bott_: Pile o force or recall holds? |
| 11:23 |
_bott_ |
hmm... had considered holds, but not recall holds specifically |
| 11:25 |
* senator |
pictures sad little books clinging to a raft on the open water somewhere |
| 11:25 |
tsbere |
_bott_: note that recall holds (at least since they were made more than just another name for copy holds) drop things to cataloging when they show up...which may not be desired. <_< |
| 11:27 |
_bott_ |
tsbere: was just reading up on them. We don't currently use them at all. |
| 11:30 |
|
gdunbar joined #evergreen |
| 11:31 |
|
gdunbar left #evergreen |
| 11:34 |
eeevil |
tsbere: that is the point of recall holds, btw. the proper name should be "cataloger recall hold", but it seemed silly at the time to force extra typing. cut-in-line is the copy-hold-but-go-first functionality |
| 11:35 |
eeevil |
in hind-sight, perhaps forcing the extra typing of "cataloger" everywhere would have been good. such is life... |
| 11:36 |
tsbere |
eeevil: Would have made my life explaining it (and figuring out what the intent was) easier... |
| 11:37 |
dbwells |
eeevil: thanks for speaking up. I now don't have to post my "please call them 'cataloger recalls' because 'recalls' already means something else blah blah blah" rant ;) |
| 11:38 |
eeevil |
dbwells++ |
| 11:38 |
|
smyers_ joined #evergreen |
| 11:38 |
eeevil |
I'll accept the blame for lazy labeling in the code ... but, I'm always here for "what is this thing" questions, and (as dbs and I are both fond of saying) patches are welcome! ;) |
| 11:39 |
|
fparks joined #evergreen |
| 11:39 |
eeevil |
(that was meant with less snark that I see having typed it out) |
| 11:49 |
|
kbutler joined #evergreen |
| 11:57 |
bshum |
Oh that's fun, KPAC holds don't have notification options. |
| 11:58 |
bshum |
Err, holds placed through KPAC have no options for notification |
| 11:58 |
bshum |
So with the default being no email notify and nothing gets entered for phone or SMS, so... nothing :) |
| 11:58 |
bshum |
That's entertaining. |
| 11:58 |
bshum |
Sigh |
| 11:58 |
jeff_ |
do you mean that they fall back to the user's preferences, or something else? |
| 11:58 |
|
jdouma joined #evergreen |
| 11:59 |
bshum |
That's worth testing I guess |
| 12:00 |
bshum |
I think if they don't have preferences, it defaults to no notification |
| 12:00 |
bshum |
Which is confusing the library |
| 12:00 |
bshum |
And the patrons too I guess |
| 12:00 |
bshum |
Since they'll never find out they have holds ready for them |
| 12:02 |
|
acoomes joined #evergreen |
| 12:03 |
dbs |
kraftsman-pac |
| 12:03 |
bshum |
Pretty much :) |
| 12:04 |
bshum |
Two options I could think of, adding notification options to the get it, or just ripping out holds entirely from KPAC if it's not supposed to be a use case. |
| 12:04 |
bshum |
We're going to discuss it in-house I guess. |
| 12:09 |
|
Callender joined #evergreen |
| 12:29 |
tsbere |
@hate holds |
| 12:30 |
pinesol_green |
tsbere: But tsbere already hates holds! |
| 12:30 |
bshum |
jeff: And interesting... the user in question does have email|phone as their opac.hold_notify preference |
| 12:30 |
bshum |
So they probably should have gotten something... |
| 12:31 |
bshum |
Maybe KPAC doesn't take those into consideration at all |
| 12:31 |
bshum |
In addition to not displaying notification options during hold placement |
| 12:36 |
jeff |
it could be useful to have those defaults referened at the ML, rather than relying on the "client" (in this case TPAC/KPAC) to look up the preference and set it. |
| 12:36 |
tsbere |
bshum: I think the backend hold code that kpac is triggering assumes that the frontend looked at the defaults and prefs... |
| 12:37 |
bshum |
Hmm |
| 12:37 |
* tsbere |
assumes the backend code doesn't look that stuff up because if the frontend had, say, email deselected we don't want the fact it was the user's default to re-enable it |
| 12:38 |
tsbere |
perhaps one solution would be the load the user's prefs into hidden fields in the kpac? At least then any defaults will apply... |
| 12:41 |
jeff |
that would be the quickest short-term solution, assuming that the kpac handlers will do anything with it. a quick experiment would be to manually create the hidden fields with values in them hardcoded in the appropriate template file in a test environment. |
| 12:42 |
jeff |
you might even find that the defaults / user settings have already been looked up and are available to the template with no handler-side modifications. |
| 12:42 |
jeff |
but if they aren't already there, that would be your next step. :-) |
| 12:43 |
|
mrpeters joined #evergreen |
| 12:47 |
bshum |
Alright, I guess I'll start looking a little at that. |
| 12:48 |
bshum |
Thanks jeff and tsbere |
| 12:50 |
|
mrpeters joined #evergreen |
| 13:02 |
|
kbeswick joined #evergreen |
| 13:04 |
|
Ndrew joined #evergreen |
| 13:06 |
|
mrpeters left #evergreen |
| 13:07 |
|
guest222 left #evergreen |
| 13:10 |
|
Ndrew joined #evergreen |
| 13:13 |
|
kmlussier joined #evergreen |
| 13:13 |
|
Ndrew left #evergreen |
| 13:16 |
|
stevenyvr2 joined #evergreen |
| 13:17 |
|
Ndrew joined #evergreen |
| 13:17 |
|
akilsdonk_ joined #evergreen |
| 14:03 |
jeff |
can configuration option names be passive aggressive? |
| 14:03 |
jeff |
broker_conflates_patron_visible_and_unique_id = yes |
| 14:03 |
jeff |
i think so. |
| 14:08 |
jeffdavis |
no_thats_fine_i_dont_mind_if_you_conflate_patron_visible_and_unique_id_ill_just_add_it_to_the_list_of_problems_i_need_to_deal_with |
| 14:08 |
berick |
no_thats_fine_i_dont_mind_if_you_conflate_patron_visible_and_unique_id_ill_just_add_it_to_the_list_of_problems_i_need_to_deal_with_also_IE_sucks |
| 14:08 |
jeffdavis |
ha! |
| 14:09 |
berick |
i mean, while yr at it ;) |
| 14:10 |
jeff |
jeffdavis++ |
| 14:10 |
jeff |
berick++ |
| 14:10 |
jeff |
thanks. :-) |
| 14:24 |
jboyer-isl |
Is anyone planning on/looking into adding support for Stripe payments in the OPAC? It's really appealing since the CC number never touches our network. |
| 14:28 |
ldwhalen |
Sitka is considering it now. |
| 14:28 |
ldwhalen |
I have spoken with Stripe briefly |
| 14:29 |
jboyer-isl |
That's reassuring. I was trying to figure out where to wedge it in, but following most of that code is currently beyond me. :/ |
| 14:29 |
jeff |
we've already implemented Authorize.net externally of evergreen (and GRPL is using same, and has contributed to the code). I know that HMMPL did authorize.net also, before us. |
| 14:29 |
jeff |
I am interested in stripe as an option as well. |
| 14:30 |
jeff |
Mostly because their API is nicer and I believe their rates are also. |
| 14:31 |
jboyer-isl |
The only problem I can see might be the rolling 7 day delay in deposits, but I'm hoping that's not a dealbreaker for most places. |
| 14:31 |
ldwhalen |
The Stripe code that sends the CC data to their network is Javascript, so integrating it into the staff client shouldn't be too hard. |
| 14:32 |
ldwhalen |
After that a module in the same vein as the PayPal module will have to process the token that Stripe returns to excute the charge. |
| 14:33 |
jboyer-isl |
It's the backend that I'm currently looking into. I don't know how easily it can be worked in with the Business::OnlinePayment module. |
| 14:36 |
ldwhalen |
I would like to consider creating a new OpenSRF application to handle billing, so that processing payments is not dependant on Evergreen |
| 14:36 |
jeff |
oh, the other reason that i was interested in stripe was because we were looking into things like "bill prints and such to patron accounts in the ILS, allow a balance to reach X then auto-charge the card" |
| 14:36 |
ldwhalen |
In that case, the Evergreen backend would send payment requests to this application. |
| 14:36 |
jeff |
which would also be possible for overdues, though i'm not sure what the patron interest in that would be. |
| 14:36 |
jeff |
(if any) |
| 14:39 |
senator |
looking at this for the first time, but to me using stripe.js, so that payment card numbers never have to go to an EG site's servers at all (and nothing has to be done keep them out of logs, etc), seems like it would be the big win |
| 14:40 |
jboyer-isl |
senator: That's the angle I'm coming from. (Also, Stripe's rates are fixed and attractively low) |
| 14:40 |
jeff |
yes. that was one of the reasons we did credit card payments the way we did. it greatly reduces your compliance requirements (and thus overhead). |
| 14:41 |
senator |
jboyer-isl: aye, and we can avoid the B::OP stuff altogether |
| 14:42 |
jboyer-isl |
That's also nice, since more than one of the CPAN links on that module's page goes to a dead link. D: |
| 14:43 |
senator |
smallish to moderate amount of new EG code to take a stripe "token" (their term) and validate that with stripe and maybe then ultimately give the user final confirmation (depending on how that part works exactly; like i said, just reading it for the first time now but finding it very promising) |
| 14:44 |
jeff |
stripe's api and their api docs is worth review for anyone creating an api or docs. |
| 14:45 |
Dyrcona |
Cataloging at the circ. desk, and people wonder why MARC record are such shit. |
| 14:50 |
jboyer-isl |
Well, I'm really hoping to get a lot done at the hackaway re: OPAC mobile friendly-ness, but does anyone else have any interest in getting basic stripe support started if there's time/tuits? |
| 14:52 |
bshum |
Sigh |
| 14:53 |
bshum |
Sorry jboyer-isl, not you. That idea sounds worthy of being added to the list. |
| 14:53 |
bshum |
Sighing about other things :) |
| 14:53 |
jboyer-isl |
bshum: I was going to ask if the KPAC holds testing went poorly. :) |
| 14:53 |
bshum |
jboyer-isl: I haven't even had time to get back to that yet. |
| 14:54 |
jboyer-isl |
One of those days, then, eh? |
| 14:58 |
senator |
jboyer-isl: i owe serials some attention and plan to be dbwells' best friend for some of that time, but as a #2 thing to slot in, yeah i would work on that |
| 14:58 |
bshum |
General opinion... should we keep https://bugs.launchpad.net/evergreen/+bug/1086458 open? Now that someone filed https://bugs.launchpad.net/evergreen/+bug/1224042 ? |
| 14:58 |
pinesol_green |
Launchpad bug 1086458 in Evergreen "Staff client memory leaks in 2.3 and later" (affected: 8, heat: 56) [High,Fix committed] |
| 14:58 |
pinesol_green |
Launchpad bug 1224042 in Evergreen "Staff client memory leaks in 2.4" (affected: 1, heat: 6) [Undecided,New] |
| 14:59 |
bshum |
The 2.3 one has lots of things we've tested/tried |
| 14:59 |
bshum |
But the 2.4 one is most recent and does have additional test information attempted by SITKA I guess. |
| 14:59 |
* jeff |
frowns at 1224042 |
| 14:59 |
bshum |
jeff: That's kind of what I was thinking. |
| 14:59 |
jboyer-isl |
senator: I can work on css/html later if I have to, so if time becomes available just let me know. I don't think I've really got enough experience with eg's guts to get going alone. (i.e. none at all with most of EGCatLoader...) |
| 15:00 |
bshum |
At the end of the 2.3 bug I did suggest starting new bugs with specific areas to repair for memory leak targeting. That way we can focus on individual measures to improve things. |
| 15:01 |
bshum |
Since it seemed clear we weren't going to be nailing it with one big fix it all. |
| 15:01 |
bshum |
(other than wiping it out and starting over with something new) |
| 15:02 |
|
yboston_test joined #evergreen |
| 15:02 |
senator |
jboyer-isl: cool. i'll try to make it happen so we can work on it (not to discourage anybody else to jump up too, of course) |
| 15:05 |
|
dboyle joined #evergreen |
| 15:07 |
jeffdavis |
bshum: Part of the challenge is that it's hard to tell where a memory leak is coming from, which makes separate tickets for memory leaks in different areas kinda tricky. |
| 15:08 |
bshum |
Well, in the interests of keeping things in one place so that we have all the information together, I'm marking the new bug a duplicate and copying all the details to the old ticket. |
| 15:08 |
jeffdavis |
The old one is marked Fix Committed/Fix Released, I wonder if that is misleading if there are additional memory leak issues? |
| 15:08 |
jeffdavis |
Not sure what the correct approach is in that situation. |
| 15:10 |
bshum |
jeffdavis: It was marked that way because we did apply some moderate fixes that did improve upon (but not resolved all) of the memory leak issues. That's why it was still marked fix committed, and not complete. |
| 15:10 |
bshum |
released* |
| 15:11 |
bshum |
But we can always change the status. I just marked it back to "triaged" pending further discussion |
| 15:11 |
jeffdavis |
OK, I see. |
| 15:12 |
senator |
best policy i can think of in cases like that would be to open a separate bug (or amend another bug if an appropriate one happens already to be open) to list the still-unresolved parts of the problem |
| 15:12 |
senator |
and note the second bug in a comment on the first for ease of reference |
| 15:14 |
bshum |
senator: Eh, we could do that too, but it seems that every time that happens, either we miss dealing with the initial opened bugs or whatnot. Unless the bug has been put to a completed state, I don't think we should open too many new bugs. |
| 15:14 |
bshum |
Unless there's a specific new identified area or target to be fixed that is. |
| 15:14 |
bshum |
That's not covered in the original bug |
| 15:14 |
bshum |
Otherwise, we could also have bugs like "make the opac better" that never get closed forever? |
| 15:15 |
* bshum |
hates Launchpad |
| 15:15 |
paxed |
you too?! ;) |
| 15:22 |
senator |
bshum: oh i see, 1086458 had/has mixed statuses |
| 15:22 |
senator |
confusing in overview, but that makes sense i guess |
| 15:22 |
bshum |
Yeah it's one of those bugs that I wish was easier to explain :) |
| 15:22 |
bshum |
But I guess that's what makes it hard to fix too ;) |
| 15:25 |
|
stevenyvr2 joined #evergreen |
| 15:34 |
|
gsams joined #evergreen |
| 15:53 |
jboyer-isl |
Ick. I'm not certain that all of the memory problems are leak-related. I messed with the client a bit to shoot the ram usage up, closed everything to see how low usage would go, and then checked about:memory... |
| 15:54 |
|
RBecker joined #evergreen |
| 15:54 |
jboyer-isl |
Huh, paste didn't seem to come through: http://paste.evergreen-ils.org/11 |
| 15:55 |
phasefx |
I need to update bug 1110817; the memory usage goes up and down while idle, but doesn't seem to leak |
| 15:55 |
pinesol_green |
Launchpad bug 1110817 in Evergreen 2.3 "staff client patron search results continuously eats memory" (affected: 5, heat: 26) [High,Confirmed] https://launchpad.net/bugs/1110817 |
| 15:55 |
jboyer-isl |
That value for heap-committed-fragmentation is not at all good. |
| 15:57 |
jboyer-isl |
Rather than leaking objects explicitly, I suspect the allocations that take place are leaving odd (and large-ish) gaps in ram that new allocations juuust don't fit in, causing heap growth that never goes away. That's horrible to change. |
| 15:58 |
jboyer-isl |
(Though if any mozilla devs wanted to move xulrunner to a process-per-tab separation model like chrome...) |
| 16:01 |
* phasefx |
updates the bug |
| 16:17 |
|
kbeswick joined #evergreen |
| 16:35 |
hopkinsju |
bshum: I'm just now getting to look at the new site. Great job dude! |
| 16:35 |
hopkinsju |
bshum++ |
| 16:35 |
bshum |
hopkinsju: Still a work in progress, but thank you :) |
| 16:36 |
bshum |
dbwells: Is there anything in the logs that indicates why an LDAP authentication might be failing? |
| 16:36 |
bshum |
I'm trying to set up a connection for one of our schools and now I'm not sure if it's the AD user creds I was given or improper test account credentials. |
| 16:37 |
dbwells |
bshum: there are a number of different error messages. One second... |
| 16:38 |
dbwells |
bshum: looks like they are all debug level, and all start with "User login failed:". |
| 16:39 |
bshum |
dbwells: Okay, so I need to bump up opensrf_core.xml to debug level (4?) and then try again |
| 16:39 |
dbwells |
sound right |
| 16:39 |
dbwells |
sounds right, that is |
| 16:39 |
bshum |
I'll see what I can find out. Thanks much. This LDAP stuff is giving me a headache :) |
| 16:41 |
dbwells |
bshum: I know you stay pretty current, but probably worth mentioning that there were a few important bug fixes within the last couple months for the LDAP stuff. |
| 16:42 |
bshum |
dbwells: It's a master system, from a few weeks ago |
| 16:42 |
bshum |
But yeah hopefully sidestepped those :) |
| 16:42 |
dbwells |
cool |
| 16:43 |
senator |
dbwells: jfyi i appealed to you in an open-ils-general email, but forgot to actually CC you so as to get your attention |
| 16:44 |
bshum |
Ah there we go |
| 16:44 |
bshum |
"User login failed: The LDAP server is misconfigured or unavailable" |
| 16:45 |
bshum |
So I guess that's that |
| 16:45 |
dbwells |
senator: I'll check it out, thanks |
| 16:45 |
bshum |
Now I just have to figure out why that is and what it means... heh |
| 16:45 |
senator |
no, thank you |
| 16:46 |
dbs |
bshum: port may not be open... credentials could be bad... lots of possibilities with LDAP :) |
| 16:46 |
bshum |
dbs: Yep, that's what I figured. |
| 16:47 |
bshum |
I wish there was an easier way to test this stuff. Stupid LDAP |
| 16:52 |
jeff |
Dyrcona++ for JSONPrefs -- interesting |
| 16:54 |
pastebot |
"dbwells" at 64.57.241.14 pasted "test LDAP bind credentials" (8 lines) at http://paste.evergreen-ils.org/12 |
| 16:55 |
dbwells |
bshum: your LDAP stuff is failing at the admin bind stage, so I would use something simple like the paste above to test the credentials. |
| 16:55 |
dbwells |
bshum: If you can bind, you will get a '0' to print out. |
| 16:55 |
bshum |
dbwells: Thank you sir, that will be mighty helpful indeed. |
| 16:56 |
dbwells |
bshum: obviously, you will need to change the hardcoded stuff in there to whatever your values are for hostname, authid, and password. |
| 16:57 |
bshum |
dbwells: Yep, just tried that and got 49 back. Which looks to be a basic bind error |
| 16:57 |
bshum |
Guess I'll ask the IT folks to try again to give me credentials that actually work... |
| 16:57 |
bshum |
More emails! Whee :) |
| 17:02 |
dbwells |
bshum: the 'authid' should be the whole LDAP DN (distinguished name) for the user who is trying to bind, not just the 'username'. So maybe if you ask for the DN, you might be more likely to get back what you need. Good luck! |
| 17:04 |
bshum |
Hmm |
| 17:07 |
bshum |
dbs: So... when we removed the password reset, do we need to update the URL for the lost password A/T definition to something new? |
| 17:08 |
bshum |
Someone just asked me why we're getting 404's or internal server errors. |
| 17:08 |
bshum |
And it seems to point back to me removing the PasswordReset.pm stuff as per eda67ed |
| 17:08 |
pinesol_green |
[evergreen|Dan Scott] Remove JSPAC-oriented PasswordReset.pm interface - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eda67ed> |
| 17:10 |
bshum |
I'm adding it back for the time being. |
| 17:10 |
bshum |
Oops :\ |
| 17:11 |
|
mmorgan left #evergreen |
| 17:18 |
bshum |
And yep. |
| 17:18 |
bshum |
Reverting that commit fixes the existing password reset requests sent out by email |
| 17:19 |
bshum |
Hmm, guess we just need to figure out how to change the A/T definition to have the emails sent point at the newer password reset stuff |
| 17:19 |
|
BigRig_ joined #evergreen |
| 17:19 |
* bshum |
will file a new bug |
| 17:21 |
|
BigRig__ joined #evergreen |
| 17:22 |
|
gsams joined #evergreen |
| 17:31 |
bshum |
Bah, or it's just me |
| 17:31 |
bshum |
And something is wrong with our templates :) |
| 17:33 |
bshum |
Yeah it's our templates are still wrong... nevermind me.... |
| 18:00 |
|
BigRig joined #evergreen |
| 18:01 |
csharp |
so... asset.copy has a non-null constraint on location (copy/shelving location), defaulting to asset.copy_location.id 1... |
| 18:02 |
csharp |
a library system has set up many copy locations, but has no location with id 1 - looks like the id val was set higher at some point |
| 18:03 |
csharp |
pre-cats are created with no copy location specified, so it defaults to id 1, which in this case doesn't exist |
| 18:03 |
csharp |
bug? or just a "don't do that!" issue? |
| 18:05 |
csharp |
the library system in question had a database corruption/mismanagement issue at some point too, (perhaps a DROP CASCADE that shouldn't have happened), so that may be why there's no copy location with id 1 |
| 18:07 |
jeffdavis |
csharp: the relevant record asset.copy_location.id = 1 is in the seed data |
| 18:09 |
csharp |
oh - I didn't see that |
| 18:10 |
csharp |
now I do |
| 18:10 |
csharp |
jeffdavis: thanks |
| 18:10 |
csharp |
okay - so not a bug |
| 18:10 |
csharp |
or at least, it's probably reasonable to assume that a standard EG installation has a copy location 1 |
| 18:12 |
jeffdavis |
I wonder what other "special" records like that are assumed to exist - the other that comes immediately to mind is having an admin user where actor.usr.id = 1 |
| 18:12 |
|
acoomes joined #evergreen |
| 18:14 |
csharp |
jeffdavis: there are a lot of hardcoded ids assumed to exist for various functions to work |
| 18:15 |
jeffdavis |
yeah I'm trying to think of a way to clarify the distinction |
| 18:15 |
jeffdavis |
stuff like item statuses you can more or less reasonably expect those to be hard-coded |
| 18:15 |
jeffdavis |
shelving location 1 and user 1 are a bit different to me |
| 18:15 |
jeffdavis |
it's probably not worth thinking about too hard though :) |
| 18:18 |
|
acoomes joined #evergreen |
| 18:31 |
bshum |
csharp: 1 is usually supposed to be stacks |
| 18:31 |
bshum |
It's just assumed to be there all the time I thought. |
| 18:34 |
csharp |
yeah, I think it's because of the DB drop issue this library faced |
| 18:34 |
csharp |
DROP CASCADE gone rong |
| 19:18 |
|
RBecker joined #evergreen |
| 19:50 |
|
artunit joined #evergreen |
| 20:26 |
|
linda-15d joined #evergreen |
| 20:27 |
linda-15d |
:-* |
| 20:27 |
|
linda-15d left #evergreen |
| 20:41 |
|
smyers_ joined #evergreen |
| 23:12 |
|
stevenyvr2 joined #evergreen |
| 23:12 |
|
stevenyvr2 left #evergreen |
| 23:12 |
|
zerick joined #evergreen |
