User activity tracking should be transient by default

Bug #1570909 reported by Bill Erickson on 2016-04-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen circa 2.10 -- Affects all versions.

The config.usr_activity.transient column, which determines whether to keep all or only the most recent user activity entry (per activity type) should be set to true by default, so that only the most recent entry is retained.

For starters, we should default to collecting less patron data where feasible for patron privacy. Additionally, this table gets really big really fast if all event types are non-transient.

Kathy Lussier (klussier) wrote :


Bill Erickson (berick) on 2016-04-15
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

Code pushed to change the default value for the transient column from FALSE to TRUE.;a=shortlog;h=refs/heads/user/berick/lp1570909-usr-activity-transient

This branch (as is) only affects new installs. It does not modify activity types on existing systems. My concern here was that, depending on the size of the actor.usr_activity table, some manual data cleanup may be needed/preferred before toggling the transient value, since setting an activity type to transient could result in huge numbers of deletes in a short period of time.

Would it be helpful to have a tool (SQL script) to clean up the usr_activity table by deleting all but the most recent entry per user per activity type that people can run off-hours before modifying their transient settings?

Bill Erickson (berick) wrote :

Additional commits pushed:

1. Adds a new function for purging user activity rows by activity type, leaving the most recent row per user, consistent with transience.

2. pgtap test for the above.

3. release notes.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
tags: added: pullrequest
Changed in evergreen:
milestone: none → 2.10.2
Bill Erickson (berick) wrote :

Adding pullrequest and targeting all active releases, since it only affects new installs, while providing tools to optionally affect existing installs.

Changed in evergreen:
milestone: 2.10.2 → 2.10.3
Changed in evergreen:
milestone: 2.10.3 → 2.10.4
Changed in evergreen:
milestone: 2.10.4 → 2.10.5
Changed in evergreen:
milestone: 2.10.5 → 2.10.6
Chris Sharp (chrissharp123) wrote :
tags: added: signedoff
Mike Rylander (mrylander) wrote :

Master has it now! I've decided against backporting this myself -- the db change pushed me over the line. If back-branch RMs feel differently, I leave it to them.

Thanks, Bill!

Changed in evergreen:
milestone: 2.10.6 → 2.11-beta
status: New → Fix Committed
Galen Charlton (gmc) wrote :

For my part, I've decided against backporting this to 2.10.

no longer affects: evergreen/2.8
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers