Display aged circulations for copies (was: "virtually aged circulations")
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
This wishlist item is bug #1453974 on steroids.
Here's the idea..
When circulation aging (anonymization) is enabled, all circulations that are eligible for aging, regardless whether they are actually anonymized, should be treated as such in the staff client. To put that another way, just because a patron opts in to retaining their circ history does not mean their entire circ history should be visible to staff, short of running a report.
Fortunately, there aren't many places in the staff client where closed circulations are retrieved. Those that come to mind are the copy status interface, the copy "most recent circulations" interface, and the patron billing history interface.
Looking specifically at the copy status UI, I imagine it working something like this:
1. API looks for most recent circulation, aged or otherwise.
2. If the most recent is aged, then the aged circ is returned.
3. If the most recent is not aged, but would have been, had the patron not opted in, then translate the circ on-the-fly into an aged circulation (in the ML, not the DB) and return that.
4. Otherwise, return the active circulation.
5. The UI would be modified to look for aged circulations. When it received one, it would avoid rendering any user-related info. For example, the "Patron" field in the circ history tab would be empty. When staff selected the "show last few circulations" action from the menu, the circulations would appear, but the patron name / barcode would not be listed.
Input on the general idea appreciated.
Changed in evergreen: | |
milestone: | 2.next → 2.11-beta |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
Do the interfaces that retrieve closed circs all call the same API to retrieve them? It seems to me that it's better to make the changes in the actual API layer rather than teaching the UI that some circs have to be displayed differently.
(If they don't all call the same API, or worse, just throw around JSONQ's or PCRUD calls, perhaps a usable API could be defined to handle this on the back end)