Search History On/Off Configuration

[dl-maura]

Following up on a discussion in the slack, this ticket is for the work to make search history collection configurable -- my feeling would be default off, configure to be on but I put it to the community on the choice there as I'm not a core committer. This is both to allow for better user privacy and if it's off it's less having to cron cleanup search histories that may be collected that we don't want (bots etc).

[seanaery]

Adding my thoughts I expressed in #blacklight slack:

Like many others, my library has been prioritizing adding more protections around patron privacy lately, and efforts to either purge search history or not collect it in the first place seem relevant to that effort. Out of the box, Blacklight does keep session search history in a searches table. Whether your UI links to it or not, your app exposes a route /search_history and when you visit that page you can see your recent queries. A standard Blacklight UI does use this data to power prev/next navigation from item page to item page within the context of a query. In our catalog app, this is actually useful and desirable. In our arclight app, it's neither. Unchecked, we have run into problems with database bloat with all this saved search history accumulating, whether our apps intentionally use it or not. Blacklight ships with a delete_old_searches Rake task (here) that will purge the data, but it needs to be set up to run on a schedule; we now have cronjobs that do this regularly.

[jrochkind]

I believe that having next/previous buttons on individual item pages depends on this being on.

There have been ideas to implemeent next/previous in a different way, but they have not come to fruition.

In my app, I do override BL to turn this off, and give up on next/previous buttons on item pages.