Evergreen ILS Website

IRC log for #evergreen, 2017-05-16

| 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
02:47 remingtron joined #evergreen
02:47 dbwells joined #evergreen
04:30 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:01 JBoyer joined #evergreen
07:03 genpaku joined #evergreen
07:14 rjackson_isl joined #evergreen
07:22 agoben joined #evergreen
07:24 rlefaive joined #evergreen
08:12 kmlussier joined #evergreen
08:14 kmlussier Is anyone around this morning who can give webby a kick? I'm getting a 504 gateway time-out when I try to connect.
08:30 collum joined #evergreen
08:40 mmorgan joined #evergreen
08:45 Dyrcona joined #evergreen
09:04 Dyrcona joined #evergreen
09:45 maryj joined #evergreen
10:09 mmorgan I'm trying to delete a patron account and it's timing out. I see this all the time with staff accounts, but haven't had any trouble with patrons before.
10:09 mmorgan Any suggestions?
10:20 Dyrcona You could delete the user in the database or use the actor.usr_purge_data() function on the user, also in the database.
10:20 Dyrcona Though might want to check in the database to make sure that the patron is not already deleted.
10:21 Dyrcona A lot of times when I've seen staff client timeouts, the backend process finished anyway.
10:21 bshum Could be a popup?
10:26 mmorgan I can still retrieve the patron in the client, so not deleted.
10:26 mmorgan bshum: What kind of popup?
10:30 mmorgan Does usr_delete() happen before usr_purge_data() when deleting from the client? I see usr_delete() in the logs, but not usr_purge_data()
10:31 berick mmorgan: usr_delete() calls usr_purge_data() internally
10:32 Dyrcona mmorgan: You see usr_delete in the postgres logs, but not usr_purge_data()?
10:33 mmorgan Ah. ok, I see where it's called.
10:33 berick if it's timing out in the middle layer and client (thus not committing the transaction), deleting directly in the DB is what i'd do.
10:33 * Dyrcona wonders if you would normally see both.
10:34 Dyrcona yeah, that's what I thought was happening.
10:34 mmorgan Dyrcona: Yes, only usr_delete() appears in the logs
10:35 mmorgan Ok, will try directly in the db.
10:35 Dyrcona That may be normal depending on the log settings.
10:35 * Dyrcona isn't sure.
10:45 mmorgan Ok, ran the usr_delete() in the db and it took over 3 minutes, but it worked.
10:46 mmorgan Dyrcona++
10:46 mmorgan berick++
10:47 Dyrcona That user must have a lot of history.
10:47 mmorgan over 2000 checkouts, is that considered a lot?
10:52 berick mmorgan: for staff accounts in particular, checkouts are only a small part of what has to be migrated/deleted.
10:53 kmlussier But this one is a patron account.
10:53 mmorgan Yes, I've had those issues with staff, but this is the first patron account that has been a problem.
10:53 berick oh, i misread mmorgan's opening comment
10:55 * mmorgan will settle for success rather than understanding on this one for the moment. :)
10:57 berick yeah, we'd need an 'explain analyze' on the data purge to see what the hold up is
10:59 mmorgan so that would need to be done before the purge?
10:59 pinesol_green [evergreen|Bill Erickson] LP#1672824 A/T complete_time set on grouped events - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ddd5d45>
11:04 miker mmorgan: lots of overdue items? rewriting the billing and payment summary tables can be time consuming
11:04 Christineb joined #evergreen
11:08 mmorgan miker: all transactions were closed, but I didn't check billing and payment tables prior to purging. Will keep that in mind if this happens again.
11:10 Dyrcona Five cent fine rates are not very efficient in the database. :)
11:10 Dyrcona Yes, I've seen them as recently as yesterday.
11:11 mmorgan Agreed, neither are 2 cent fines. :)
11:12 Dyrcona Two cent fines? What is this, 1917? :)
11:13 * mmorgan prefers no cent fines :)
11:13 Dyrcona No fines! :)
11:13 Dyrcona At MVLC, roughly half of the libraries do not charge fines. I think it is slightly more than half.
11:15 mmorgan NOBLE has a few that don't charge fines. Fewer than half.
11:16 Dyrcona It kind of depends on your definition of not charging fines. Some might charge for overdue DVDs, but not books, for instance.
11:17 mmorgan Yes, we have a "No fines for books" library.
11:37 collum_ joined #evergreen
11:45 _adb joined #evergreen
11:55 kmlussier graced++ jeff++ #Following up with web site contributors on Creative Commons licensing consent. Just down to three now.
11:55 jwoodard joined #evergreen
11:56 graced kmlussier++  #herding the cats who are hunting the mice
11:58 khuckins joined #evergreen
12:11 csharp hmm - wondering about why libbusiness-edi-perl is present in the ubuntu-trusty makefile but not the ubuntu-xenial makefile for Evergreen - does anyone know?
12:12 csharp git history shows that that package wasn't included when bshum first created the xenial file, so I'm a little confused
12:13 berick csharp: no longer needed
12:13 csharp berick: ah - ok
12:13 berick circa 2.3 it would appear
12:14 csharp we're working on our xenial deb and I'm reconciling the deb control files with the makefiles
12:17 csharp one more: libnet-https-any-perl
12:17 csharp in trusty but not in the initial xenial file
12:22 berick i see no references to https::any in the code
12:27 csharp same here - ok - that solves that one too :-)
12:27 csharp berick: thanks
12:28 Dyrcona Some things may have been added because some other package needed it at one point, but don't quote me on that. :)
12:39 jeff commit 65a7584 points to Business::OnlinePayment::PayPal as requiring the libnet-https-any-package be installed. ymmv, especially since 2012.
12:39 pinesol_green jeff: [evergreen|Jason Stephenson] Add libnet-https-any-perl as precise deb requirement in Makefile.install. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=65a7584>
12:39 csharp one more perl question... is Class::DBI::Frozen::301 still required, and if so, what would we need to make plain old Class::DBI do the job?
12:40 csharp jeff: thanks!
12:41 berick jeff++ Dyrcona++
12:41 berick csharp: yes, Frozen is still required.
12:41 * csharp sees "Class::DBI::Frozen::301'->use or 'Class::DBI'->use or die $@;" in all but one file referencing it
12:42 jihpringle joined #evergreen
12:42 csharp we use "dh_make_perl --cpan" to build the deb, so not really a big deal time/effort-wise, just wondering
13:08 bshum csharp: berick: Hmm, if that package isn't listed for any of the other makefiles, we really should nuke it from Trusty too.  That is libbusiness-edi-perl I mean.
13:11 rlefaive joined #evergreen
13:15 Dyrcona These community "fests" always fall when I'm otherwise swamped.
13:17 csharp Dyrcona: that's true for me this week too :-/
13:31 berick bshum: agreed
13:32 bshum jeff: berick: csharp: and if what jeff says is right about the PayPal stuff needing that other package, then we should add that to the Xenial builder too
13:32 bshum Probably should just do a check against all the makefiles
13:32 bshum And remove/add stuff to make them consistent
13:32 bshum (and reorder things for my sanity while I'm at it)
13:38 kmlussier Dyrcona: There are times when you're not swamped?
13:38 Dyrcona Only up to my neck most of the time. :)
13:45 bshum Dyrcona: Then you're not really in danger yet.  Just uncomfortable.
13:45 bshum :D
13:45 Dyrcona No, this week, I'm treading water. :)
14:07 berick make a wave when you can, Dyrcona
14:45 Dyrcona Pro Tip: It helps to push to a remote repository before you try to pull the changes elsewhere. :)
14:53 Dyrcona Yay! Timeout error from Launchpad.
14:55 mmorgan So Launchpad is apparently swamped, too...
14:57 Dyrcona Apparently, but it is working for me, now. Just one of those things...
14:57 * Dyrcona is looking up a couple of fix released bugs.
14:59 * Dyrcona wonders if there is a technical reason that user activity tracking does not track checkouts/renewals?
15:03 mmorgan1 joined #evergreen
15:03 kmlussier Dyrcona: Because the project was originally designed as a project to track authentication activity.
15:04 kmlussier http://masslnc.org/node/2393
15:05 Dyrcona Right, but it would be useful to know the date of a patron's last checkout for purposes of purging old data.
15:06 * kmlussier agrees
15:06 Dyrcona I kind of remember some discussion around this feature, but 5-6 years ago is ancient history to me, now. :)
15:07 kmlussier Yeah, it was designed to accommodate more than our particular use case in the hopes that future development would make other uses of it. But, sometimes, that future development doesn't happen. Or it takes a while to happen.
15:07 Dyrcona :)
15:08 kmlussier Dyrcona: But I don't think there is a technical reason. My recollection was that the intent was that those types of things would eventually be built.
15:08 Dyrcona At the time, I don't think MVLC was aging circulations.
15:09 Dyrcona kmlussier: So, I'll open a Lp wishlist bug and work on it when I'm only up to my neck, again. :)
15:09 tsbere__ joined #evergreen
15:09 kmlussier Dyrcona++
15:10 Callender_ joined #evergreen
15:11 Dyrcona I am currently looking at doing the annual patron purge and resuming aging circulations that we haven't done for a while, so it seems like tracking this would be very useful.
15:12 gmcharlt er, and thereby partially subvert patron desires to not have their checkouts tracked? I am confused
15:13 kmlussier It wouldn't be tracking the date, not the details of the checkout.
15:13 kmlussier Now that's good English talking!
15:13 Dyrcona gmcharlt: Yeah, what kmlussier said. I wouldn't even record the time.
15:13 Dyrcona heh.
15:14 Dyrcona Just the date, set to midnight.
15:14 Dyrcona All actor.usr_activity has is an activity type and a timestamp.
15:14 Dyrcona Well, and the usr id.
15:19 Dyrcona Lp 1691246 is anyone wants to shoot it down before it even taxis to the runway. :)
15:19 pinesol_green Launchpad bug 1691246 in Evergreen "Tracking Patron's Last Checkout/Renewal Date" [Wishlist,New] https://launchpad.net/bugs/1691246
15:19 Dyrcona What's funny is when I filed that, it suggested the original bug as an alternative. :)
15:19 gmcharlt it would have to be set as transiet
15:19 gmcharlt er
15:19 gmcharlt I CAN ENGLISH AS GUD AS KMLUSSIER
15:19 gmcharlt ;)
15:19 gmcharlt *transient
15:19 Dyrcona Yeah, I thought about that.
15:20 tsbere I solved that with a DB trigger and date_trunc to month before updating an extend_reporter table. ;)
15:20 Dyrcona Yeah, I knew MVLC had some solution.
15:20 tsbere I figure if you can actually say "this patron checked something out in the same month this item was checked out, so it must have been them!" with any real accuracy your non anoning well enough. ;)
15:20 tsbere er, not anoning
15:21 Dyrcona With 30,000+ transactions/day, I think daily granularity would be OK. If anyone has suggestions, like a granularity setting, please add them in comments.
15:21 * kmlussier would support not even having the transient option and just making all activity transient.
15:22 kmlussier Dyrcona: It doesn't track the OU, right?
15:22 Dyrcona Everything is transient so far.
15:22 Dyrcona No, there's no provision for that in the table.
15:22 Dyrcona Just usr, etype (event type), and event_time.
15:23 kmlussier Then I think daily granularity would be OK for your system.
15:23 Dyrcona I think YAOUS or a flag for granularity would be a good idea.
15:24 Dyrcona Or maybe a flag to turn it on or off with ti off by default?
15:26 abneiman Dyrcona: from the small-library perspective, +1 for a YAOUS related to granularity, in case a smaller system would want to bump that up to (say) month instead of day
15:27 kmlussier +1
15:28 Dyrcona OK. Thanks for the feedback. I've added a comment.
15:28 Dyrcona Anyway, back to what I am supposed to be working on.
15:58 jeff Anyone know offhand why the validator for the stock event def '6 Month Overdue Mark Long-Overdue' is PatronNotInCollections?
16:21 dbs joined #evergreen
16:31 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
16:39 mmorgan joined #evergreen
16:54 Jillianne joined #evergreen
16:57 mmorgan jeff: I guessed that it was because the next step in the process after long overdue was referring to a collection agency.
17:08 mmorgan left #evergreen
17:08 kmlussier Sigh...Two emails in one day where I claim that the EOB meeting is tomorrow.
21:31 rlefaive joined #evergreen
21:57 jboyer-isl joined #evergreen
22:20 genpaku joined #evergreen

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