Bug 19741 - parcel.pl only shows holds on items in received orders, we should (also) count holds on the title
Summary: parcel.pl only shows holds on items in received orders, we should (also) coun...
Status: RESOLVED DUPLICATE of bug 19812
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-04 13:59 UTC by Nick Clemens
Modified: 2017-12-15 17:19 UTC (History)
1 user (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 Nick Clemens 2017-12-04 13:59:19 UTC
On parcel.pl we show a count of holds on a bib for pending orders, however, after receiving an order we show a count of holds on the order items specifically. I think we should show both number, something like:

0(3)

or

0 (3 on title)

or 

0 on order items (3 on title)

depending on recommended verbosity/
Comment 1 Sandre Cunha 2017-12-05 16:30:32 UTC
Although not impossible, in our workflow it would be rare for an on order item to have an item-level hold. We do not assign barcodes until items are received and catalogued. 

For us, the main purpose of being able to see the holds at the time an item is received is to know whether or not to give it priority processsing. For this purpose, it doesn't matter whether the holds are bib- or item-level. The total number of holds is sometimes also useful for prioritizing. What is not useful is when the total number of holds is mulitplied by the item number.

Any of the suggested ways of showing the holds would work. The first is most succinct, and as long as everyone knows the difference between the number in and outside of the parentheses, that's fine. The second option is short, and perhaps less open to misinterpretation, so that is the one I would choose.
Comment 2 Nick Clemens 2017-12-15 17:19:07 UTC

*** This bug has been marked as a duplicate of bug 19812 ***