Bug 26993 - Allow StoreLastBorrower to retain up to 2 previous patrons
Summary: Allow StoreLastBorrower to retain up to 2 previous patrons
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P2 enhancement with 5 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 14945
Blocks:
  Show dependency treegraph
 
Reported: 2020-11-10 16:25 UTC by Andrew Fuerste-Henry
Modified: 2022-08-17 20:05 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
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 Andrew Fuerste-Henry 2020-11-10 16:25:37 UTC
Various workflows and circumstances can result in the "last returned by" value stored by StoreLastBorrower getting overwritten sooner than a library might like. For example, a patron may find the item they've checked out was damaged by the previous patron. They put the item in the bookdrop on their way into the library and then alert staff to the damage when they check out their next batch of items. By that time, the damaged item has been checked in, our imaginary patron shows as "last returned by," and we have no record there of who had it previously.

We could alleviate this by adding a third option to the StoreLastBorrower system preference, so that one can choose "Do not store," "store 1," or "store 2." 

This entire feature would still be optional for libraries that don't want to keep this data. Additionally, bug 23260 is adding the ability to clear this data after a period of time using cleanup_database. These factors help mitigate the privacy concerns inherent to the matter.
Comment 1 Wally DesChamps 2020-11-10 19:14:45 UTC
From an accountability perspective, having the option for libraries to be able to "track" an item's [relatively recent] check-out history would be very helpful.  We're not asking to breach anyone's privacy regarding their reading preferences; i.e., we're not asking to see a patron's reading history.  We're merely trying to maintain a item's history (at least for a while) to determine accountability for damages.  I like the idea of a scheduled clean-up database option (that can be determined by library as a cron job of sorts) as a method of making an effort to offer good-faith efforts of privacy.  All this said, though, [our] items are government property, and we have an obligation to the taxpayers to be able to manage and track accountability of those items (at least for a window of time).
Comment 2 Marcel de Rooy 2020-11-18 12:08:44 UTC
If we are extending from 1 to 2, why not extend to a defined limit or for a defined period of time? Makes it a bit more flexible?
Comment 3 Erik Stevens 2022-08-17 19:35:46 UTC
We would love to see this feature. It has come up several times that the item was damaged by the 2nd-to last patron, and we have no record of who that was.
Comment 4 Wally DesChamps 2022-08-17 20:05:44 UTC
Here are two reports we use.  They are effective unless the patron marks their account to not keep their history.

Check-Outs in a date range

1	SELECT i.barcode as 'Item Barcode',
2	b.title as 'Title',
3	i.itemcallnumber as 'Item Call Number',
4	a.timestamp as 'Date and Time',
5	concat(borr.surname,", ",borr.firstname) as 'Patron Name',
6	borr.cardnumber as 'Patron Barcode'
7	FROM action_logs a
8	LEFT JOIN borrowers borr on (borr.borrowernumber=a.object)
9	LEFT JOIN items i on (i.itemnumber=a.info)
10	INNER JOIN biblio b on (b.biblionumber=i.biblionumber)
11	WHERE a.action='ISSUE' AND DATE(a.timestamp) BETWEEN <<Between (yyyy-mm-dd)|date>> AND <<and (yyyy-mm-dd)|date>>
12	ORDER BY borr.firstname asc 


Circulation History of an Item.

NOTE:  Must edit/save the SQL of the report with the target item’s barcode (in line 14 below).

1	SELECT  
2	borrowers.cardnumber as "Cardnumber",
3	borrowers.othernames as "Othername",
4	borrowers.surname as "Surname",
5	items.itype,
6	items.barcode,
7	items.itemcallnumber as "Call Number",
8	date(statistics.datetime) as "Transaction Date",
9	statistics.type as "Transaction Type"
10	FROM borrowers 
11	LEFT JOIN statistics on (statistics.borrowernumber=borrowers.borrowernumber) 
12	LEFT JOIN items on (items.itemnumber = statistics.itemnumber) 
13	LEFT JOIN biblioitems on (biblioitems.biblioitemnumber = items.biblioitemnumber) 
14	WHERE items.barcode='21900004456'
15	ORDER BY statistics.datetime DESC