Bug 15504 - Track Patron's Last Activity
Summary: Track Patron's Last Activity
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P1 - high enhancement with 30 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL: http://devs.bywatersolutions.com/proj...
Keywords:
: 14513 27243 (view as bug list)
Depends on: 18625 28455 28630
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-06 16:48 UTC by Nicole C. Engard
Modified: 2021-12-06 20:03 UTC (History)
21 users (show)

See Also:
Change sponsored?: Seeking cosponsors
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2016-01-06 16:48:40 UTC
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/
Comment 1 Christopher Brannon 2016-03-18 22:38:33 UTC
Please consider having another field that would record the type of activity logged, just like you have in your list.

Christopher
Comment 2 David Cook 2019-02-18 04:53:15 UTC
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.
Comment 3 Jonathan Druart 2019-02-22 12:16:30 UTC
(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 ***
Comment 4 David Cook 2019-02-24 23:23:08 UTC
(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.
Comment 5 David Cook 2019-02-24 23:24:03 UTC
So I don't think this is a duplicate at all. I'm going to change the status back.
Comment 6 Jonathan Druart 2019-03-04 18:03:19 UTC
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.
Comment 7 Martha Fuerst 2019-05-17 20:46:55 UTC
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.
Comment 8 Katrin Fischer 2020-01-08 22:45:57 UTC
*** Bug 14513 has been marked as a duplicate of this bug. ***
Comment 9 Agnes Rivers-Moore 2020-01-09 02:22:11 UTC
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.
Comment 10 Christopher Brannon 2020-01-09 18:14:26 UTC
(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.
Comment 11 Agnes Rivers-Moore 2020-01-09 18:39:02 UTC
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.
Comment 12 Christopher Brannon 2020-01-09 18:55:00 UTC
So maybe:

* Patron record modification
* Any patron activity (login/checkouts through any connection)
* SIP patron activity (part of previous count)
Comment 13 Christopher Brannon 2020-06-29 22:40:53 UTC
Folks, this is a rather important issue.  Would love to see this progress beyond 4 years of rare discussion.  :D
Comment 14 Christopher Brannon 2020-06-29 22:46:12 UTC
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.
Comment 15 David Cook 2020-06-30 00:00:44 UTC
(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.
Comment 16 Victor Grousset/tuxayo 2020-06-30 03:05:24 UTC
(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)
Comment 17 Christopher Brannon 2020-06-30 15:11:27 UTC
(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"?
Comment 18 Martha Fuerst 2020-06-30 15:42:51 UTC
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
Comment 19 Agnes Rivers-Moore 2020-06-30 15:56:32 UTC
(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!
Comment 20 Victor Grousset/tuxayo 2020-06-30 19:03:42 UTC
(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?)
Comment 21 Christopher Brannon 2020-06-30 19:14:29 UTC
(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.
Comment 22 Victor Grousset/tuxayo 2020-06-30 19:34:10 UTC
(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
Comment 23 Christopher Brannon 2020-06-30 19:48:01 UTC
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.
Comment 24 Victor Grousset/tuxayo 2020-06-30 21:16:12 UTC
(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
Comment 25 Victor Grousset/tuxayo 2020-06-30 21:18:04 UTC
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.
Comment 26 David Cook 2020-07-01 02:49:09 UTC
(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 :).
Comment 27 Cab Vinton 2020-09-10 18:54:22 UTC
Agreeing w/ Martha & Agnes that lastseen dates should also reflect patron checkout, renewal, & return activity.
Comment 28 Magnus Enger 2020-09-14 13:01:41 UTC
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.
Comment 29 Agnes Rivers-Moore 2020-09-17 22:53:22 UTC
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
Comment 30 Jonathan Druart 2020-12-17 11:09:12 UTC
*** Bug 27243 has been marked as a duplicate of this bug. ***
Comment 31 Magnus Enger 2020-12-28 11:55:23 UTC
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 }
Comment 32 Andrew Fuerste-Henry 2021-06-25 11:37:56 UTC
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.
Comment 33 Christopher Brannon 2021-08-06 19:13:37 UTC
(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.