Evergreen ILS Website

IRC log for #evergreen, 2013-11-19

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
05:56 stevenyvr2 joined #evergreen
05:57 stevenyvr2 left #evergreen
06:48 stevenyvr2 joined #evergreen
06:48 stevenyvr2 left #evergreen
06:59 timlaptop joined #evergreen
07:21 akilsdonk joined #evergreen
07:42 gdunbar joined #evergreen
07:43 phasefx2 joined #evergreen
07:43 goooood joined #evergreen
07:57 goood joined #evergreen
08:04 collum joined #evergreen
08:07 kmlussier joined #evergreen
08:33 RoganH joined #evergreen
08:34 csharp kmlussier: I was looking at bug 1234220 and started wondering... do we have *any* renewal block messages?
08:35 pinesol_green Launchpad bug 1234220 in Evergreen "Renewal blocked due to holds ratio does not display block message" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1234220
08:35 kmlussier csharp: Off the top of my head, I know if you use the OU setting to block renewals for titles with holds, there is a nice user friendly message that displays.
08:35 csharp I got a PINES ticket about a patron who tried to renew, was blocked because there was a hold on the item, but was not *told* that was why.  She only saw that she had 2 renewals left
08:36 csharp oh
08:36 csharp I'm pretty sure that's set in PINES - lemme check
08:37 csharp yes it is
08:37 csharp hmm
08:37 kmlussier csharp: I'm pretty sure a message displays. I kept forgetting to turn off that OU setting when testing the holds ratio, so I saw it a few times.
08:37 mmorgan joined #evergreen
08:38 csharp yeah - that was my original assumption - then I started digging around in the template code and didn't see anything :-/
08:42 ericar joined #evergreen
08:43 akilsdonk joined #evergreen
08:48 csharp okay, yeah, I see "Copy is needed to fulfill a hold" in red
08:48 csharp but I can see how a patron might miss it
08:48 csharp kmlussier: thanks
09:10 hopkinsju joined #evergreen
09:16 Shae joined #evergreen
09:18 jbfink joined #evergreen
09:51 paxed like you can search for foo* to find words-starting-with-foo, is there *foo for words-ending-with-foo?
09:53 yboston joined #evergreen
10:22 jbfink joined #evergreen
10:33 ldwhalen joined #evergreen
10:35 ericar joined #evergreen
10:39 Bmagic what is the recommended setting for PATRON_EXCEEDS_OVERDUE_COUNT when you dont want the system to check out a book to anyone who has a single overdue?
10:42 Bmagic We have this setting set to 0.90 - we have a problem where the patron does not get that penalty applied until his account is pulled up into the Staff Client and the refresh button is pressed. What process should be adding the standing penalty? Fine Generator?
11:07 serflog joined #evergreen
11:07 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org
11:08 Bmagic jeff: Are you saying that the fine generator should be applying that penalty to the account even if it doesnt add fines
11:09 jeff the grace period is likely at play here. the overdue_circs sub called by open-ils.storage.action.circu​lation.overdue.generate_fines excludes circs that are within the grace period.
11:09 jeff thus, unless there are other overdue circs that are past the grace period, the fine generator will not trigger a calcualtion of system penalties.
11:10 jeff that's probably what's causing what you're seeing.
11:10 Bmagic jeff: That is the issue then
11:11 jeff and it's a bit of an inconsistency, since a manual recalc will add the penalty. we should probably determine if the penalty should count overdues within the grace or not.
11:11 jeff while this is based on a reading of the code and my current understanding of things, please keep in mind that i haven't tested this theory. :-)
11:12 Bmagic jeff: right on, sound like an interesting debackle
11:12 Bmagic jeff: right on, sound like an interesting debacle
11:19 Bmagic jeff: For now, it sounds like I can use that script that you directed me to on a cronjob? Long term, perhaps the code for fine_generator.pl could be discussed in dev?
11:26 jeff i wouldn't recommend that script from cron. for one thing, it relies on you to manually supply a list of users to recalc and relies on you providing a manual auth token.
11:26 jeff it was meant for one-time batch update style use.
11:27 jeff we had a need to recalc a bunch of users when we changed some thresholds, and we also had no access to the server at the time, so it runs through the gateway, same as the staff client.
11:59 smyers_ joined #evergreen
12:05 gsams joined #evergreen
12:06 dMiller joined #evergreen
12:08 ldwhalen joined #evergreen
12:11 paxed ~/win 22
12:11 paxed oops
12:14 gmcharlt joined #evergreen
12:16 gsams joined #evergreen
12:16 smyers_ joined #evergreen
12:17 dMiller__ joined #evergreen
12:18 jeff anyone present using non-3M SIP-based self checkout terminals? i'm wondering how other vendors react to "charge privileges denied" in the patron status field.
12:19 jboyer-isl JCPL was running Bibliotheca machines when I left. If you've some simple steps to test what you're interested in I could pass them on.
12:20 jeff in evergreen, standing penalties 1 and 2, as well as any standing penalty with a non-empty block list will result in "charge privileges denied" being set to Y.
12:20 jeff (this is for standing penalties with an org_unit based on the home_ou and ancestors of the patron in question)
12:21 jeff so, if you define a max items out limit of 40, a patron with 40 items out has a standing penalty which blocks circ.
12:21 jeff the patron scans their card on a 3M SelfCheck workstation, and receives an error message and is directed to the desk.
12:21 jeff this prevents them from using the self checkout terminal to renew items.
12:22 jeff i'm interested in changing the behavior on the evergreen side of things, and would like to better understand how other SIP clients react to "charge privileges denied"
12:23 jeff so, it would be interesting to know if patrons with the max number of items out can use a bibliotheca terminal, or if they're refused outright.
12:27 eeevil jeff: sound primarily like the impedance mismatch between SIP2 and ILSen, where the latter has a separate idea of "renewal" but the former does not, and ties renewal to "charge privileges" ... some ILSs lie about the patron's status and deny circs at attempt time, which the EG SIPServer driver could do, I suppose
12:30 jeff huge impedance mismatch, yes.
12:30 jeff and eg does reject at attempt time, of course.
12:31 jeff and (at least in our environment) we do have at least one case where we want to alert when the patron scans their card -- when they're expired.
12:31 jeff i'm going to reach out to 3M to see if they can provide more details, but thought i'd seek out others with other vendors here. i don't see sal_, but maybe I'll e-mail her.
12:33 jeff incidentally, there is also a "renewal privileges denied", which... oh hey, which evergreen sets to match the charge privileges denied value. i suppose it's time to test.
12:34 jeff because if i can make evergreen "do the right thing" with regard to renewals being permitted as long as there isn't a RENEW-blocking ausp, that would be logical and would avoid a new config for "don't report these standing penalties" or similar.
12:35 jeff semi-related, does anyone know if we've ever populated a csp block value of INET, or is that just something in our db?
12:37 jeff _bott_: any idea about the INET block type on some standing penalties? was that a GRPL/ME thing?
12:38 linuxhiker1 joined #evergreen
12:39 tsbere jeff: First I have heard of such a thing
12:45 hopkinsju_ joined #evergreen
12:53 csharp jeff: yeah - we don't have that type either
12:53 hopkinsju_ joined #evergreen
12:54 plux joined #evergreen
12:56 jeff and the pickaxe confirms -- doesn't seem to have ever been in seed data.
13:00 eeevil jeff: I don't recall INET being a block type, but it seems valuable. and +1 to doing the right thing in the face of a RENEW block, and not using CIRC
13:01 csharp @praise the pickaxe
13:01 * pinesol_green` the pickaxe is the very model of a modern major hacker
13:01 csharp @nick pinesol_green
13:01 pinesol_green` csharp: Error: You don't have the admin capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
13:01 csharp pinesol_green`: dude
13:01 pinesol_green` csharp: Mr. Spock: Something fascinating just happened.
13:08 smyers__ joined #evergreen
13:21 linuxhiker1 joined #evergreen
13:24 RoganH joined #evergreen
13:29 stevenyvr2 joined #evergreen
13:41 mjingle joined #evergreen
13:44 smyers__ joined #evergreen
13:49 dMiller_ joined #evergreen
14:07 kmlussier joined #evergreen
14:18 bshum eeevil: I'm finally reading back what you last commented in bug 1185865.  When you say sparing DB server CPU cycles, does that refer to a system where hold_targeter is run on the same server as DB?  Or do you just mean that because there's in-db logic at play, that we'll use up processing either way.
14:18 pinesol_green Launchpad bug 1185865 in Evergreen "Hold targeter taking a long time to run" (affected: 2, heat: 10) [Undecided,New] https://launchpad.net/bugs/1185865
14:22 DPearl1 I'm specifying OCLC as a record source in Z39.50.  What log, if any, are these requests logged in? (OCLC is only returning 4 records when the code asks for more, and I want to figure out why.)
14:35 eeevil bshum: no, I mean that the in-database part is more complex now. if the load on your db would support more concurrent retargetting, increasing the parallel targeters would help
14:36 bshum eeevil: Okay, worth looking into then.  I don't think our DB load is significantly high, but I'm never entirely sure what that is.
14:36 bshum Thanks!
14:36 eeevil np
14:37 bshum DPearl1: If you mean that you're choosing OCLC as the record source for importing records and you're doing searches on them and not seeing the results you expect?
14:38 bshum DPearl1: I'm not sure those system requests are logged anywhere in the GUI (doubt it).  But maybe there's something in the osrf logging
14:38 bshum I imagine if you had access to OCLC's z39.50 log that could be fun to see :D
14:39 jeff do we have too much logic in the db these days?
14:39 bshum I occasionally dabble looking at our yaz logs to see what people search against when they look at our z39.50 from EG
14:39 jeff not a particularly focused or productive question, but something i've been thinking about a little bit.
14:40 tsbere jeff: I find that answer varies. Including on "who you ask". Some people insist that no logic should be done in the DB other than what is required for things like foreign key relationships and not null constraints and such, after all.
14:41 jeff sure, there's purists like that. i wasn't asking from that point of view. :-)
14:42 jeff i suspect that things like in-db ingest are not cpu bound, but haven't tested. it might be.
14:55 mceraso This may be a silly question, but I'm asking anyway :) Would it be okay to join the merchandising committee for Evergreen? Rogan sent out an email yesterday
14:55 mceraso Apologies, wrong window :)
14:55 mrpeters joined #evergreen
14:55 DPearl1 bshum: Yeah. OCLC is record source.  It looks like there is a functionality change (a.k.a. degredation) with the new opensrf, I'd guess.  I have one system EG2.3/OS2.13 which works as expected, and another EG2.4/OS2.2.1 which doesn't work.  Can't spot a log yet...
14:59 dbs DPearl1: different versions of yaz, too, maybe?
15:03 bshum Yeah my first gut reaction is to learn what versions of Yaz were being employed.
15:06 bshum There are some known weirdness with packaged yaz from Precise systems
15:07 eeevil jeff: in-db ingest is aprox 10x faster than the old way, and breaks a lot less (and when it does, it doesn't leave a mess behind) ... just fwiw
15:07 jeff eeevil: and that's the kind of experienced perspective i was fishing for. thanks. :-)
15:07 DPearl1 dbs, bshum: I'll check on yaz...
15:08 dbs Would be fabulous if PostgreSQL could be more parallel, mind
15:10 kmlussier eeevil: I'm curious. Would MVF work open up the door to future work to add format facets?
15:13 tfaile joined #evergreen
15:14 eeevil kmlussier: not "facet" in the exact way we mean internally in EG today, but yes, a sidebar filter based on MVF would be more useful than one based on SVF.
15:14 kmlussier eeevil: Thanks!
15:15 bshum Speaking of Postgres
15:15 eeevil np
15:15 bshum Has anyone else read these posts about Ubuntu 12.04 and newer kernel versions?
15:15 bshum Like http://frosty-postgres.blogspot.com/2013/1​1/ubuntu-has-released-3110-kernel-for.html
15:15 eeevil dbs: we should write a background worker to shred xml for us, and have a bunch going at the same time! :)
15:15 bshum Not sure how many that impacts, we're still bouncing around on Ubuntu 10.04 for our DB server.
15:16 eeevil bshum: that's why I use debian ;) (in all seriousness, it does look nasty, but we've avoided it afaict)
15:17 bshum eeevil: Since we're talking redoing our whole server system next year for 14.04, I've been giving some thought towards switching us to Debian instead.
15:17 bshum But good to know ;)
15:20 dbs win 19
15:20 dbs meh
15:21 * jeff transforms paxed's earlier ~ into a / and hands it to dbs
15:26 Bmagic jeff: Do you think that I could alter your perl script to create the auth token with something similar to this: my $script = OpenILS::Utils::Cronscript->new;
15:26 Bmagic my $authtoken = $script->authenticate(
15:26 jeff Bmagic: yes, certainly.
15:26 jeff and if you were going to do that, you could always move away from using LWP and the gateway altogether.
15:27 jeff it's a very simple script, in terms of it just walks over a bunch of values and calls an opensrf call with that value as an argument.
15:28 dMiller__ joined #evergreen
15:28 Bmagic jeff: I have only touched my toes in working with opensrf, so I need some guidance. I haven't been able to make heads or tails of the opensrf documentation that I have found. At least in this context
15:29 csharp bshum: FWIW, we've been running fine on 12.04 since March
15:30 jeff csharp: did you see higher-than-before cpu utilization as mentioned in those threads?
15:35 collum Making sure I'm not missing the obvious.  I'm looking for last inhouse checkin for an copy in the staff client.  Do you guys know if this is available on any of the copy screens?
15:35 tsbere collum: "Last inhouse checkin"?
15:35 * tsbere can think of at least two ways, possibly more, to define that one
15:36 collum In house use
15:36 csharp jeff: nope, but we also doubled our RAM along with the upgrade, so that may have mitigated the issue
15:36 collum Easy enough to pull the most current date out of the in_house_use table, but I was hoping it was in the client.
15:37 csharp we did see some crazy high load a few months ago, before we moved our data directory to a separate array
15:37 csharp since early September we've been stable
15:37 * csharp sacrifices goat to sys admin gods
15:37 jeff collum: nothing comes to mind other than the reporter or the db. we don't use in-house-use here much if at all, though.
15:38 tsbere collum: Never actually paid a lot of attention to that functionality, though I would say that is more of a "checkout" then a "checkin" ;)
15:39 collum Thanks jeff and tsbere.
15:40 tsbere collum: I don't actually see any significant use of that table, nor do I see any "retrieve" style functions for it in use anywhere. Looks like a "write only, use reporting to get it out" table as a result?
15:40 tsbere (same for the noncat side, for that matter)
15:40 * collum defines his terms on how his staff has decided to use the software. :-)
15:41 collum Thanks tsbere.  I will write a jasperreport for them to use.
15:41 jeff yay! another JasperReports user!
15:42 jeff collum: how are you liking JasperReports?
15:42 tsbere collum: For note, when I think "inhouse checkin" I have two scenarios that jump to mind. "The last time the item was checked in at home" and "the last time the item was touched by a computer at home". The first can be determined fairly easily, the latter isn't always obtainable for a large number of reasons right now.
15:42 RBecker joined #evergreen
15:42 * jeff still wants a "last seen time" value for copies somewhere. poor man's inventory, among other things.
15:43 collum jeff:  Indeed I do.  It's easy for the staff to use, and it's convenient.
15:43 jboyer-isl A quick Parts mystery. When placing a hold on a title with parts, what determines if choosing a part is required or not? I'm looking at 2 titles, placing a hold on one forces you to choose a part, the other has an "-All Parts-" entry selected initially.
15:43 jeff collum: excellent. how long have you been using it, and what brought it to your attention?
15:43 jboyer-isl The only difference I can see is that the one that forces you to choose has all of its items checked out.
15:43 collum tsbere: we defined in-house-use as an item that was found used in the library, but not checked out.  "Found on a table"
15:44 tsbere collum: We define that entire functionality as "something we don't use" ;)
15:45 collum jeff: I started using around June 2012.  We came live on EG in August.   My staff was used to a web based reporting package, so I wanted to have something familiar for them.
15:45 collum Uh.  August 2012
15:48 jeff cool. did you come to it independently, or based on some of TADL's experience with it?
15:52 collum The sequence of events is a blur.
15:53 collum I believe I came to it because I knew TADL was using it, and I thought I would check it out.
15:53 jeff heh. got it.
15:54 jeff well, glad to hear that there's at least one other evergreen library using it. that should motivate me to put up some more of our reports.
16:17 eeevil jboyer-isl: if the bib has any part-less copies, you can choose the "all parts" option. if all copies are attached to parts, you must choose a part. IIRC, not looking at the code ATM
16:18 bshum Yeah that sounds about right.
16:19 bshum "All parts" is basically a title level hold if I remember right.  Targeting all the copies that don't have parts.
16:19 bshum It could be that the bib has a monographic part on it
16:19 bshum And yet none of the underlying copies have connected parts to them?
16:20 jboyer-isl I see. So if a single location has a "regular" item, everyone with parts sees the All Parts option?
16:20 bshum Yes
16:20 bshum (I still hate the terminology)
16:20 bshum See this kmlussier!
16:20 bshum parts--
16:20 bshum I said, parts-- !!!!!!!!!!!!!!!!!!
16:21 * kmlussier is paying attention and formulating a response. ;)
16:21 kmlussier parts++
16:21 kmlussier parts++
16:21 bshum Heh
16:21 jboyer-isl The cataloger that asked the question will be thrilled to hear that as soon as another location gets the same copy of this TV show that All Parts will be back. (they like requiring the choice, but I couldn't see why it was being offered.)
16:21 kmlussier jboyer-isl: The idea is that, in most cases, if a library added an item without parts, they are most likely circulating it as a whole set. That's where the "All Parts" label comes from.
16:23 kmlussier jboyer-isl: We have one consortium that requires all branches to add parts to their items on records with parts as a way to require users to select parts. However, that can be problematic when there are already title-level holds on the part.
16:23 kmlussier Our other two consortia don't make the same requirement.
16:24 jboyer-isl I see. I guess there's some confusion here since most locations don't use parts, but the ones that do
16:24 jboyer-isl didn't realize why things were different.
16:24 jboyer-isl on a single record, that is.
16:26 bshum In our consortium, it's policy that once a lib starts using parts, everybody has to assign parts to their items as well for that given bib record.
16:27 bshum We kind of force their hand by changing the code to disallow further new title holds via the all parts option.
16:27 bshum And making the all parts just a signaler that they need to pick a real part.
16:27 bshum Wasn't really my choice, just part of how policy was enacted.
16:28 jboyer-isl I don't think enough libs use them here for that to gain traction, but I may pass it along to the cataloging group.
16:31 linuxhiker joined #evergreen
16:36 kmlussier bshum: You don't have issues where there are pre-existing title holds on the record?
16:36 bshum kmlussier: Pre-existing title holds will slowly fill based on their order using copies that aren't yet parts.
16:36 bshum So they'll slowly filter out over time.
16:36 bshum It's the new holds that must be applied once copies are converted to parts.
16:36 kmlussier Ah, I see.
16:37 linuxhiker1 joined #evergreen
16:37 bshum It's generally more likely that the holds finish filling with existing copies from other libs before people realize that new holds aren't targeting their copies anymore
16:37 bshum Due to them not using parts.
16:37 bshum The libs that switch to parts quickly never use their copies for parts, but their parts get used for all the new holds
16:38 bshum So I guess they consider that balanced?
16:38 bshum Or perhaps libraries are manually canceling title holds and remaking them as part holds once they convert to parts.
16:41 * kmlussier thinks it's easier to let title holds be placed for people who want the whole thing and parts holds for people who want a part.
16:42 kmlussier Though I think the interface could use some improvement so the whole parts selector is more visible. NOBLE did some nice custom work for their parts selector to make it  more visible. I should think about making a branch out of that someday.
17:03 bshum Hmm, people grumbly about not having hold shelf expire time or some other wording saying pickup before it expires as part of SMS texts.
17:04 bshum 140 characters really doesn't give alot of room to get wordy
17:04 bshum Or 160?
17:04 bshum Either way, *big sigh*
17:08 phasefx_ start including a tiny url :)
17:09 phasefx_ might be able to click on it with a smartphone, not sure
17:10 bshum We probably could click on those with a smartphone
17:10 bshum Sigh
17:11 kmlussier bshum: I think the maximum count varies based on carriers. I remember we set the maximum character lower than 140 in our requirements docs after I had done some investigating.
17:11 bshum Then everybody would want individualized SMS texts with a link to their own policies or whatnot.
17:12 bshum Maybe we need to include this as extra information around the parts where SMS are setup in patron accounts.  Or on each hold.
17:12 bshum By the way, pick it up in 5 days or else
17:12 bshum kmlussier: That wouldn't surprise me at all.
17:20 mmorgan left #evergreen
17:56 dMiller_ joined #evergreen
18:02 mtcarlso- joined #evergreen
18:42 kbeswick joined #evergreen
18:46 dMiller joined #evergreen
18:50 stevenyvr2 left #evergreen
19:29 hopkinsju joined #evergreen
19:43 hopkinsju_ joined #evergreen
19:54 hopkinsju_ joined #evergreen
20:20 mjingle joined #evergreen
20:21 rangi joined #evergreen
20:23 mjingle left #evergreen
21:41 stevenyvr2 joined #evergreen
21:42 stevenyvr2 left #evergreen
23:31 mrpeters joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat