Bug 13125 - Total holds does not tally holds / items.reserves is not populated
Summary: Total holds does not tally holds / items.reserves is not populated
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 12530 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-10-22 03:00 UTC by Danielle Elder
Modified: 2023-07-11 13:32 UTC (History)
7 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 Danielle Elder 2014-10-22 03:00:22 UTC
The items.reserves field in Koha is not working. It does not tally the total number of holds. I have checked several libraries with books that are usually on hold an all do not have any holds in the total ... at all.
Comment 1 Owen Leonard 2016-07-21 18:47:27 UTC
(In reply to Danielle Elder from comment #0)
> The items.reserves field in Koha is not working.

Did this ever work? This sounds like it is an enhancement request, although I wouldn't think an item-level count of holds would be useful unless you also required item-level holds all the time.
Comment 2 Katrin Fischer 2016-07-21 21:55:26 UTC
Hm, maybe we could use it to count how many holds a specific item has filled - it might be interesting to see.
Comment 3 Barton Chittenden 2018-11-27 19:14:11 UTC
items.reserves shows on the koha-to-marc mapping, and is also documented in https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx)

For the sake of supportability, I would like to see this either fully implemented or removed.
Comment 4 Katrin Fischer 2019-02-10 22:10:01 UTC
*** Bug 12530 has been marked as a duplicate of this bug. ***
Comment 5 Christopher Brannon 2020-01-27 15:36:04 UTC
I would like to see this implemented.  Doesn't make sense to keep running totals of checkouts and renewals and not reserves.

I guess we need to start with, what counts?

Personally, I want to know every hold, whether cancelled or filled.  Some might want only filled, and others might say only those that have been picked up.  I say all combinations should be a preference, but all should be an option for the tally.

Logistically, it would be easiest to add to the tally at the time of creation for all holds placed.  But for only filled holds or picked up holds to be tallied, that would probably need to be added at the time of fulfillment, or at time of pickup, and not at the time of creation.
Comment 6 Katrin Fischer 2023-07-09 11:10:53 UTC
It feels like the unresolved question here is how to treat record level holds vs. item level holds. That makes it different to renewals and issues counts that are always item specific.

Thinking of a serial with a lot if issue items... it doesn't seem to make sense to always increment the number in all items. But only item level holds might not be useful... 

A total number of issues/renewals might be able to tell you something about the 'wear' of an item, but holds doesn't help here. The number would just keep increasing without the context of a date range.

I think we should remove the column actually because I don't see a way to make this number generally useful compared to what we can query from the logs.
Comment 7 Christopher Brannon 2023-07-10 15:28:58 UTC
I don't agree with doing away with it.

Perhaps the simple answer is to have the following options:

A) uptick the count in this field if a hold is triggered on the specific item.  First available or item specific is moot.  If the hold is triggered, it is assigned to a specific item at that point.

B) decide if a cancelled hold leaves the count as is, or downticks the count.