Extend patron expire date with activity

[Bill Erickson]

Wishlist:

Automatically extend a patron's expire date if the patron is using the system. "Using the system" can be defined as having entries in actor.usr_activity, which captures the simplest patron activity (e.g. logging in to the catalog, via SIP, etc.), which is important for patrons that may never actually enter a library, but are clearly using it.

Providing a way to avoid updating certain groups (e.g. a bool on permission.grp_tree) would also be needed. Perhaps this would be set to false for all groups by default.

The update interval would be the perm_interval on permission.grp_tree or potentially a static configured value.

I could see this happening in a nightly process or in real time, assuming the real-time version doesn't cause any delays. I'd lean toward nightly batches, because it's not an urgent process. IOW, if the patron can log in, and thus have not expired, updating the expire date *right now* serves little purpose.

[Mike Rylander (mrylander)]

Is it part of the plan to add hooks to circ and hold biz logic to insert entries on those actions? AFAICT, there are no activity types for those, though they're supported by the ENUM that constrains the table. Then we'd pretty much only have to look at that table to decide on "active-ness".

[Bill Erickson (berick)]

Ah, good point! Patrons that interact via the circ desk may never log in, so we'll need to capture those too.

[Terran McCanna (tmccanna)]

Interesting idea. I could see it being useful in some situations as long as it is configurable to prevent it from happening in other situations. We currently use the expiration to make sure our patrons periodically update their contact information with us, so we would opt not to automate it at this time - however, if we work out a way to keep our patron addresses updated against the NCOA database, that might become less important.

[Andrea Neiman (aneiman)]

See additional comments on duplicate bug 1823728