Work to be done: Add new timestamp field ‘last_activity’ to the ‘borrowers’ table Update the field if one of the following ocurrs: Patron checks out item Patron renews an item Patron returns an item Patron is authenticated via SIP2 Patron logs into OPAC Seeking Co-sponsors: http://devs.bywatersolutions.com/projects/track-patrons-last-activity/
Please consider having another field that would record the type of activity logged, just like you have in your list. Christopher
I noticed recently that "lastseen" updates for "Patron logs into OPAC" and "Patron is authenticated via SIP2" and that's it. I've had libraries interested in the field being updated for the other activities Nicole mentioned as well.
(In reply to David Cook from comment #2) > I noticed recently that "lastseen" updates for "Patron logs into OPAC" and > "Patron is authenticated via SIP2" and that's it. I've had libraries > interested in the field being updated for the other activities Nicole > mentioned as well. Which ones? I do not understand what's missing. Marked as duplicate of bug 16276 as borrowers.lastseen has been added by this bug. *** This bug has been marked as a duplicate of bug 16276 ***
(In reply to Jonathan Druart from comment #3) > (In reply to David Cook from comment #2) > > I noticed recently that "lastseen" updates for "Patron logs into OPAC" and > > "Patron is authenticated via SIP2" and that's it. I've had libraries > > interested in the field being updated for the other activities Nicole > > mentioned as well. > > Which ones? I do not understand what's missing. > > Marked as duplicate of bug 16276 as borrowers.lastseen has been added by > this bug. > > *** This bug has been marked as a duplicate of bug 16276 *** Nicole listed 5 activities: Patron checks out item Patron renews an item Patron returns an item Patron is authenticated via SIP2 Patron logs into OPAC Only the last two update "lastseen". If you're a borrower who never uses a self-checkout or logs into the OPAC, but you frequently check out materials via a staff member, your "lastseen" value will be really old even though you're a frequent user of the library. I've had libraries complain that they're trying to find inactive borrowers using "lastseen" but it's including active borrowers who don't log into Koha.
So I don't think this is a duplicate at all. I'm going to change the status back.
Indeed, you are right. The description of bug 16276 says: """ We would like to automate the delation of expired patrons to comply to french laws regarding privacy. But we don't want to delate an expired patron which is still using the OPAC for bibliographical purpose, like managing lists. We would like to be able to say when the patron logged himself for the last time to permit this. """ It could be renamed last_login to avoid ambiguity.
Except that calling it last_login doesn't indicate the SIP2 connection, which is important. In our case, a patron may use their card 100% for databases or digital materials, so tracking the SIP2 is key for this.
*** Bug 14513 has been marked as a duplicate of this bug. ***
Summary so far - A timestamp, updated by checkout / renew / return / SIP2 / OPAC login. (Nicole) The type of activity needs to be indicated as well as the timestamp. (Christopher) SIP2 activity needs to be tracked. (Martha) Noted "Lastseen" seems to capture OPAC login and authenticated by SIP. This would be the "updated" timestamp displayed in the patron summary. My thoughts - It would help to know more about how people want to use this timestamp. Is it for reports (inactive patrons for weeding, or activity for statistics), or to be visible to staff in the patron record, like the "Updated" timestamp? We would need clearer labels - "updated" implies but does not actually indicate when the borrower record was renewed or edited. Checkout / renew / return (whether through intranet, OPAC or SIP) are one kind of activity, and are captured already in circulation history. OPAC login and SIP (e.g. for authentication of outside systems like Overdrive) are another, and they are also already captured somewhere but not clear to staff. Should they be handled separately or feed into a single last activity date? I would also like a way to update that activity timestamp without checking out. Something like the "statistical borrower" but a "statistical item" that could be scanned to record library activity not connected to Koha. For example, people who use computers or sign up for programmes. Maybe there is one I have missed. I agree with Martha that tracking SIP2 connections is important, and perhaps should be addressed in more detail. We use it for self-checkout, computer booking (in-library activities) and authentication for accessing Overdrive, RBDigital (external resources). Some label suggestions - last-login (OPAC or self-checkout), updated (patron details changed through OPAC or Intranet), last-activity (activity from any channel including SIP), remote-use (outside resource SIP connections and OPAC login). Just suggestions, for wider discussion.
(In reply to Agnes Rivers-Moore from comment #9) > Some label suggestions - last-login (OPAC or self-checkout), updated (patron > details changed through OPAC or Intranet), last-activity (activity from any > channel including SIP), remote-use (outside resource SIP connections and > OPAC login). > Just suggestions, for wider discussion. I'm concerned with over complicating the information. In my opinion, there are a couple things we want to track here: * Patron record modification * Patron activity (login/checkouts through any connection) Timestamps are generic, and a catch-all. That is good for logs, but the two above are more specific. These are two that need to be recorded in the patron record, that we don't have to scrounge for in logs that are not necessarily recorded, or are purged on a regular basis. I'm not sure about last-activity or remote-use. Those are a little more granular and bleed over into the other two mentioned above and might make it more confusing. But this is my opinion.
Agree with Christopher about the library activities - we just want the labels to clearly describe what activity sets the timestamp. To clarify - Martha and I definitely want the SIP2 activity to be tracked separately from checkouts, because SIP2 includes activities that are outside Koha circulation.
So maybe: * Patron record modification * Any patron activity (login/checkouts through any connection) * SIP patron activity (part of previous count)
Folks, this is a rather important issue. Would love to see this progress beyond 4 years of rare discussion. :D
To add to this, it is really holding us back on tracking active patrons. We cannot clean out our patron databases on inactive accounts, because currently Koha is not tracking activity through 3rd party databases or computer checkouts via SIP authentication. This really needs some momentum.
(In reply to Christopher Brannon from comment #13) > Folks, this is a rather important issue. Would love to see this progress > beyond 4 years of rare discussion. :D I agree that it's important, but it's not a priority for us at this time. I notice this issue is marked as "Seeking cosponsors". It might be worthwhile to send an email to the koha-devel list to see if someone wants to work on it, or if you have funds - look to hire someone to do the work.
(In reply to David Cook from comment #2) > I noticed recently that "lastseen" updates for "Patron logs into OPAC" and > "Patron is authenticated via SIP2" and that's it. IIUC all the data is already there albeit in various tables right? So, is the functionality achievable via a report? (which could be included by default & upgrades)
(In reply to David Cook from comment #15) > (In reply to Christopher Brannon from comment #13) > > Folks, this is a rather important issue. Would love to see this progress > > beyond 4 years of rare discussion. :D > > I agree that it's important, but it's not a priority for us at this time. > > I notice this issue is marked as "Seeking cosponsors". It might be > worthwhile to send an email to the koha-devel list to see if someone wants > to work on it, or if you have funds - look to hire someone to do the work. The link to dev list is a dead link. "Not a priority for us"...who is "US"?
Chiming in again. This is ESPECIALLY important for us now, with COVID-19 and social distancing procedures, we have more people using 100% online resources - and people who have gotten cards using online registration, verified via email, to use those resources. Tracking last patron activity via SIP2/OPAC login is definitely a priority for US at Huntsville-Madison County. Best, -Marti Fuerst
(In reply to Martha Fuerst from comment #18) > Chiming in again. > > This is ESPECIALLY important for us now, with COVID-19 and social distancing > procedures, we have more people using 100% online resources - and people who > have gotten cards using online registration, verified via email, to use > those resources. > > Tracking last patron activity via SIP2/OPAC login is definitely a priority > for US at Huntsville-Madison County. > > Best, > > -Marti Fuerst +1 - COVID-19 has certainly increased the urgency on this!
(In reply to Christopher Brannon from comment #17) > The link to dev list is a dead link. http://devs.bywatersolutions.com/projects/track-patrons-last-activity/ isn't the dev list. It was a page ByWater Solutions had on this topic. The mailing lists are here: https://koha-community.org/support/koha-mailing-lists/ «General List» and «Koha Developers List» seems to me the good ones to seek organizations to cosponsor or/and to contract to work on this. (assuming SQL report are not enough?)
(In reply to Victor Grousset/tuxayo from comment #20) > (assuming SQL report are not enough?) As was mentioned, pulling stuff from activity logs is hit or miss. Depending on how often information is purged, you won't get very accurate results. This is data that is best recorded in the patron record or related table.
(In reply to Christopher Brannon from comment #21) > (In reply to Victor Grousset/tuxayo from comment #20) > > > (assuming SQL report are not enough?) > > As was mentioned, pulling stuff from activity logs is hit or miss. I missed that part. What do you mean by activity logs? The issues and old_issues tables? Because if I understand correctly, the following data is in the above tables + borrowers.lastseen > Patron checks out item > Patron renews an item > Patron returns an item > Patron is authenticated via SIP2 > Patron logs into OPAC
I must be missing something here. Where is the information on patron logins to OPAC or authentication via SIP2 that isn't in a log? I'm not sure what tables I should be looking at for this information.
(In reply to Christopher Brannon from comment #23) > I must be missing something here. Where is the information on patron logins > to OPAC or authentication via SIP2 that isn't in a log? borrowers.lastseen IIUC
Please double check, as a non-native speaker, misunderstandings are bound to happen someday :) (In reply to David Cook from comment #2) > I noticed recently that "lastseen" updates for "Patron logs into OPAC" and > "Patron is authenticated via SIP2" and that's it. I've had libraries > interested in the field being updated for the other activities Nicole > mentioned as well.
(In reply to Christopher Brannon from comment #17) > "Not a priority for us"...who is "US"? Ah, fair question! I mean the vendor I work for Prosentient Systems and the libraries that it supports. None of our libraries are signalling this as a priority for us, so we're working on other things that are more important for them. I should've been more precise with my language :).
Agreeing w/ Martha & Agnes that lastseen dates should also reflect patron checkout, renewal, & return activity.
In order to be complete, I think we need to expand this: Patron is authenticated via SIP2 into at least this: Patron is authenticated via SIP2, ILS-DI, REST API We have ebook services that authenticate patrons via ILS-DI, and if that is all they use the library for they will not be counted as active users.
I would like to suggest, respectfully, that the bug title be changed to describe this topic more accurately. As it stands it appears to be about tracking last Koha activity, but we really need tracking activity in outside resources via SIP2, ILS-DI, REST API
*** Bug 27243 has been marked as a duplicate of this bug. ***
Relevat code: C4/SIP/ILS/Patron.pm: 476 =head2 update_lastseen 477 478 $patron->update_lastseen(); 479 480 Patron method to update lastseen field in borrower 481 to record that patron has been seen via sip connection 482 483 =cut 484 485 sub update_lastseen { 486 my $self = shift; 487 my $kohaobj = Koha::Patrons->find( $self->{borrowernumber} ); 488 $kohaobj->track_login if $kohaobj; # track_login checks the pref 489 } Koha/Patron.pm: 910 =head3 track_login 911 912 $patron->track_login; 913 $patron->track_login({ force => 1 }); 914 915 Tracks a (successful) login attempt. 916 The preference TrackLastPatronActivity must be enabled. Or you 917 should pass the force parameter. 918 919 =cut 920 921 sub track_login { 922 my ( $self, $params ) = @_; 923 return if 924 !$params->{force} && 925 !C4::Context->preference('TrackLastPatronActivity'); 926 $self->lastseen( dt_from_string() )->store; 927 }
Bug 28455, signed off, adds checkouts to lastseen. So we're kinda working in two different directions here. I'm in favor of a simple approach here: a single field with a datetime that updates each time a patron does any of the listed actions (log in to OPAC, SIP, ILSDI, API, checkout, checkin). The batch patron deletion tool already knows how to filter by both lastseen and circ activity. The need I run into here relates to reports rather than the deletion tool itself. We get regular requests for a report that will give a column of the last date on which a patron either logged in to something or checked something in or out. That's much messier SQL than it needs to be with the current data structure.
(In reply to Andrew Fuerste-Henry from comment #32) > Bug 28455, signed off, adds checkouts to lastseen. So we're kinda working in > two different directions here. > > I'm in favor of a simple approach here: a single field with a datetime that > updates each time a patron does any of the listed actions (log in to OPAC, > SIP, ILSDI, API, checkout, checkin). > > The batch patron deletion tool already knows how to filter by both lastseen > and circ activity. The need I run into here relates to reports rather than > the deletion tool itself. We get regular requests for a report that will > give a column of the last date on which a patron either logged in to > something or checked something in or out. That's much messier SQL than it > needs to be with the current data structure. +1. I would add, if it is a need for anyone to define what triggers this field, a permission with checkboxes of actions that would trigger it would finish this off nicely.