Bug 20948 - Item-level hold info displayed regardless its priority (detail.pl)
Summary: Item-level hold info displayed regardless its priority (detail.pl)
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: master
Hardware: All All
: P5 - low major (vote)
Assignee: Jonathan Druart
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on:
Blocks: 19288
  Show dependency treegraph
 
Reported: 2018-06-14 21:03 UTC by Christopher Brannon
Modified: 2021-06-14 21:28 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
20.05.00, 19.11.02, 19.05.07, 18.11.13


Attachments
Misleading Hold Info (98.04 KB, image/jpeg)
2018-06-18 16:38 UTC, Christopher Brannon
Details
Misleading Hold Info - In Transit (12.62 KB, image/png)
2018-06-20 17:56 UTC, Lisette Scheer
Details
Bug 20948: Simplify existing code (3.47 KB, patch)
2019-11-18 09:38 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 20948: Only display item-level hold info if first hold (2.61 KB, patch)
2019-11-18 09:38 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 20948: Simplify existing code (3.53 KB, patch)
2019-11-20 23:15 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 20948: Only display item-level hold info if first hold (2.66 KB, patch)
2019-11-20 23:15 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 20948: Simplify existing code (3.62 KB, patch)
2019-11-29 08:04 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 20948: Only display item-level hold info if first hold (2.76 KB, patch)
2019-11-29 08:04 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 20948: Add missing html filter (1.33 KB, patch)
2019-12-10 10:18 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2018-06-14 21:03:04 UTC
The next hold request showing on the detail.pl page next to items is useless and should be removed or fixed.  The information for requests on an item is misleading.  It shows the next item level hold rather than showing the next hold it will fulfill.  I understand how this might be useful in some obscure circumstances, but for the most part it leads staff to believe that this is the next hold it will fill, and that is not the case.  

Case in point...we have a new item, only one in the collection.  33 next available holds, and 1 item level hold at the very end of the list, going to a different library.  With all the other holds ahead of it, and the fact that we have local holds priority enabled, this looks very wrong, and leads staff to confusion and panic.  

It might be helpful to some libraries to see that there is a specific hold on a particular item, but around here, most libraries will view this as misleading.  There should be a setting to change the behavior, or turn it off.
Comment 1 Jonathan Druart 2018-06-18 15:02:44 UTC
Does it concern 17.05 only?

I do not understand what you are referring to on master, can you provide screenshots?
Comment 2 Christopher Brannon 2018-06-18 16:38:03 UTC
Created attachment 76145 [details]
Misleading Hold Info

Screenshot of misleading hold.  Shows the only item-level hold in the 35 current holds.  This is not who the item will be going to when checked in.  Would prefer to not show this information if it is meaningless to us.
Comment 3 Christopher Brannon 2018-06-18 17:11:58 UTC
I realize that it may be impossible to display next available holds, but if there are next available holds and local hold priorities, I fail to see how showing the next item level hold helps.
Comment 4 Lisette Scheer 2018-06-20 17:56:00 UTC
Created attachment 76216 [details]
Misleading Hold Info - In Transit

I noticed today that there is also misleading hold info on the 'Holds' table on moremembers.pl and circulation.pl. It will list "In Transit from X branch since Y" even if that patron is not the next patron. This also only happens with item level holds. 
I'm happy to fill out a different bug, but I thought it might be related based on how the information is getting pulled. 
Lisette Scheer
Comment 5 Jonathan Druart 2019-11-14 10:56:12 UTC
I would be happy to have a look at this one if someone can provide a step-by-step plan to recreate the problem.
Comment 6 Christopher Brannon 2019-11-14 15:26:53 UTC
(In reply to Jonathan Druart from comment #5)
> I would be happy to have a look at this one if someone can provide a
> step-by-step plan to recreate the problem.

Place several next available holds on a single item record.  Then place an item level hold on the item.  Look at the detail.pl page.  The item will show the item level hold.  Many staff interpret this to mean this is where the hold is going next.

It is preferred if it just said "There is an item level hold on this item", without any specific details.
Comment 7 Jonathan Druart 2019-11-18 09:38:53 UTC
Created attachment 95476 [details] [review]
Bug 20948: Simplify existing code

No changes expected here.
Comment 8 Jonathan Druart 2019-11-18 09:38:56 UTC
Created attachment 95477 [details] [review]
Bug 20948: Only display item-level hold info if first hold

On the item list of the catalogue detail page we display next item-level
hold info even if it is not the next hold. That leads to confusion as it
will not necessarily be the accurate info.

This patch makes the following changes:
- Display the item-level hold only if it is the next hold (priority ==
1)
- Display "There is an item level hold on this item (priority=X)"
if there is at least 1 item-level hold placed on this item

Test plan:
- Place several next available holds on a single item record
- Place an item level hold on the item
- Go the the biblio detail page
=> Without this patch, the item will show the item level hold
=> With the patch you see "There is an item level hold on this item"
- Check the item in, confirm the hold
=> No changes, the item will show the waiting hold info
- Cancel all the holds except the item-level one
=> No changes, the item will how the item-level one
Comment 9 ByWater Sandboxes 2019-11-20 23:15:10 UTC
Created attachment 95636 [details] [review]
Bug 20948: Simplify existing code

No changes expected here.

Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Comment 10 ByWater Sandboxes 2019-11-20 23:15:13 UTC
Created attachment 95637 [details] [review]
Bug 20948: Only display item-level hold info if first hold

On the item list of the catalogue detail page we display next item-level
hold info even if it is not the next hold. That leads to confusion as it
will not necessarily be the accurate info.

This patch makes the following changes:
- Display the item-level hold only if it is the next hold (priority ==
1)
- Display "There is an item level hold on this item (priority=X)"
if there is at least 1 item-level hold placed on this item

Test plan:
- Place several next available holds on a single item record
- Place an item level hold on the item
- Go the the biblio detail page
=> Without this patch, the item will show the item level hold
=> With the patch you see "There is an item level hold on this item"
- Check the item in, confirm the hold
=> No changes, the item will show the waiting hold info
- Cancel all the holds except the item-level one
=> No changes, the item will how the item-level one

Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Comment 11 Marcel de Rooy 2019-11-21 07:10:36 UTC
 FAIL   koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt
   FAIL   filters
                missing_filter at line 365 (                                There is an item level hold on this item (priority = [% hold.priority %]).)

Work on qa tools ?
Comment 12 Marcel de Rooy 2019-11-21 07:34:23 UTC
There is an item level hold on this item (priority = 2). 

Personally, I think we'd better not show this at all. Please explain why we need this.
Comment 13 Jonathan Druart 2019-11-21 10:26:56 UTC
(In reply to Marcel de Rooy from comment #12)
> There is an item level hold on this item (priority = 2). 
> 
> Personally, I think we'd better not show this at all. Please explain why we
> need this.

I used Christopher's suggestion:

(In reply to Christopher Brannon from comment #6)
> It is preferred if it just said "There is an item level hold on this item",
> without any specific details.
Comment 14 Marcel de Rooy 2019-11-21 10:44:19 UTC
(In reply to Jonathan Druart from comment #13)
> (In reply to Marcel de Rooy from comment #12)
> > There is an item level hold on this item (priority = 2). 
> > 
> > Personally, I think we'd better not show this at all. Please explain why we
> > need this.
> 
> I used Christopher's suggestion:
> 
> (In reply to Christopher Brannon from comment #6)
> > It is preferred if it just said "There is an item level hold on this item",
> > without any specific details.

Well, Christopher is invited to reply too.
Comment 15 Christopher Brannon 2019-11-21 16:31:40 UTC
(In reply to Marcel de Rooy from comment #12)
> There is an item level hold on this item (priority = 2). 
> 
> Personally, I think we'd better not show this at all. Please explain why we
> need this.

I would have suggested removing it altogether, but there are those that want to know if there are item level holds on items. Particularly if items are lost or missing or damaged. That way they can easily see them and do something about the holds.
Comment 16 Lisette Scheer 2019-11-21 18:29:28 UTC
(In reply to Christopher Brannon from comment #15)
> I would have suggested removing it altogether, but there are those that want
> to know if there are item level holds on items. Particularly if items are
> lost or missing or damaged. That way they can easily see them and do
> something about the holds.

This is why I would find the message helpful as well. Are there any performance issues from having it show?
Comment 17 Katrin Fischer 2019-11-24 12:45:06 UTC
Is this similar/related to Bug 19288?
Comment 18 Jonathan Druart 2019-11-25 10:07:22 UTC
(In reply to Katrin Fischer from comment #17)
> Is this similar/related to Bug 19288?

Yes, at first glance they refer to the same problem.
Comment 19 Jonathan Druart 2019-11-25 10:07:58 UTC
(In reply to Lisette Scheer from comment #16)
> (In reply to Christopher Brannon from comment #15)
> > I would have suggested removing it altogether, but there are those that want
> > to know if there are item level holds on items. Particularly if items are
> > lost or missing or damaged. That way they can easily see them and do
> > something about the holds.
> 
> This is why I would find the message helpful as well. Are there any
> performance issues from having it show?

Absolutely not.
Comment 20 Marcel de Rooy 2019-11-29 08:04:12 UTC
Created attachment 95870 [details] [review]
Bug 20948: Simplify existing code

No changes expected here.

Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 21 Marcel de Rooy 2019-11-29 08:04:16 UTC
Created attachment 95871 [details] [review]
Bug 20948: Only display item-level hold info if first hold

On the item list of the catalogue detail page we display next item-level
hold info even if it is not the next hold. That leads to confusion as it
will not necessarily be the accurate info.

This patch makes the following changes:
- Display the item-level hold only if it is the next hold (priority ==
1)
- Display "There is an item level hold on this item (priority=X)"
if there is at least 1 item-level hold placed on this item

Test plan:
- Place several next available holds on a single item record
- Place an item level hold on the item
- Go the the biblio detail page
=> Without this patch, the item will show the item level hold
=> With the patch you see "There is an item level hold on this item"
- Check the item in, confirm the hold
=> No changes, the item will show the waiting hold info
- Cancel all the holds except the item-level one
=> No changes, the item will how the item-level one

Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 22 Marcel de Rooy 2019-11-29 08:55:34 UTC
*** Bug 19288 has been marked as a duplicate of this bug. ***
Comment 23 Martin Renvoize 2019-12-09 14:35:37 UTC
Nice work everyone!

Pushed to master for 20.05
Comment 24 Jonathan Druart 2019-12-10 10:18:03 UTC
Created attachment 96137 [details] [review]
Bug 20948: Add missing html filter
Comment 25 Martin Renvoize 2019-12-10 10:40:28 UTC
Nice work everyone!

Pushed to master for 20.05
Comment 26 Martin Renvoize 2019-12-10 10:40:57 UTC
Thanks for catching that Jonathan.. you beat me to it :)
Comment 27 Martin Renvoize 2019-12-10 10:43:46 UTC
Nice work everyone!

Pushed to master for 20.05
Comment 28 Joy Nelson 2019-12-31 17:10:49 UTC
Pushed to 19.11.x branch for 19.11.02

Thanks,
joy
Comment 29 Lucas Gass 2020-01-06 22:47:59 UTC
backported to 19.05.x for 19.05.07
Comment 30 Hayley Pelham 2020-01-10 00:31:11 UTC
Backported to 18.11.x for 18.11.13