| 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 |
