When a hold is placed on an item as "next available" and then a hold is placed on same item, but it is placed on a specific copy, Koha will show the specific copy hold on the status screen of the item incorrectly and sometimes give the hold to that specific copy before next available. On 16.11.07 Steps: 1. Place a "next available" hold on an item with only one copy. 2. Place a "specific item" hold this same record. 3. Looking at the holds- they are in the correct order 4. Look at the status of the item in the holdings table you can see that the hold for the "specific copy" is next- not the next available. 5. Check this item in and see which hold gets filled first. 6. Results vary on the process of who gets the hold when checking in this item . Sometimes the specific item will get filled before the hold that was placed as next available even though the "Next available" hold was placed first.
Could settings like preferring local holds play into that?
Katrin, This library that felt the process did not work is a single branch library- so local holds don't really come into play with her process. Kelly
I was wondering because you said it's not consistent, if there was another factor.
Created attachment 76099 [details] [review] Bug 19288: Only display holds if next in queue or waiting To test: 1 - Place a title level hold on a biblio for a patron 2 - View the details, the item(s) has no info about holds 3 - Place an item level hold for an item on the same biblio for another patron 4 - View the details page, note the item indicates it is held for the second patron 5 - Apply patch 6 - Refresh details, the hold is not indicated 7 - Set the item specific hold to be priority #1 8 - Refresh details, the hold should now be indicated 9 - Confirm the hold 10 - Refresh details, the hold should show as waiting
This patch will only show the hold if it is next in the priority list, however, localholds priority and other settings may mean the hold triggered at checkin is not the one listed. Would it be reasonable to only show "there is a hold on this item" unless the hold is waiting?
Created attachment 76100 [details] [review] Bug 19288: [Alternate] Only show existence of item level hold unless waiting To test: 1 - Please a biblio level hold for one patron, and an item level hold for another on same record 2 - Note that you patron name for item lvel hold 3 - Apply patch 4 - You should now see 'There is a hold on this item' with no patron detail 5 - Confirm hold, patron detail should be visible
Please rebase on master.
(In reply to Michal Denar from comment #7) > Please rebase on master. Either patch seems to apply, you should not apply both, they are alternate options I suggest the second patch, but want opinions
Created attachment 89059 [details] [review] Bug 19288: [Alternate] Only show existence of item level hold unless waiting To test: 1 - Please a biblio level hold for one patron, and an item level hold for another on same record 2 - Note that you patron name for item lvel hold 3 - Apply patch 4 - You should now see 'There is a hold on this item' with no patron detail 5 - Confirm hold, patron detail should be visible Signed-off-by: Liz Rea <wizzyrea@gmail.com> I like the 2nd approach better. :)
I am not sure here if less information is better. Maybe the original message should just be phrased a bit better? We switch from: Item-level hold (placed 05/11/2019) for delivery at Centerville. Hold for: katrin koha (42) To: There is a hold on this item I am also not sure how this related to the initial bug report, where Kelly reported that sometimes the item level hold would be filled first, even if not first in the queue. Can you explain? While the first message is very 'talkative', maybe we can find some middle ground? Something like: Item-level hold for .... (priority x) (similar to how we display the priority in the OPAC) And I would leave out the hold placed and pickup location.
(In reply to Katrin Fischer from comment #10) > I am not sure here if less information is better. Maybe the original message > should just be phrased a bit better? > > We switch from: > > Item-level hold (placed 05/11/2019) for delivery at Centerville. Hold for: > katrin koha (42) > > To: > > There is a hold on this item > > I am also not sure how this related to the initial bug report, where Kelly > reported that sometimes the item level hold would be filled first, even if > not first in the queue. Can you explain? > > While the first message is very 'talkative', maybe we can find some middle > ground? Something like: > > Item-level hold for .... (priority x) (similar to how we display the > priority in the OPAC) > > And I would leave out the hold placed and pickup location. As I understand the main issue, the problem is that Koha shows one hold on the details page, and triggers another at checkin. Different factors can affect which hold will be triggered at checkin, and we don't want to do too many calculations to show the item details, so we are getting a simple 'what's in the queue' and showing the wrong name. Trying to show the correct name is the issue. Until the hold is actually waiting it can fluctuate. I think this solution gives the library the info they need "Check this item in to trigger a hold" without adding info that may be wrong
Can you explain why the displayed patron would not be the one receiving the next item? I have thought about it, but fail to come up with a use case. And if it's not something that depends on environment (current library location or something) we should be able to fix it. Our libraries are mostly single branch and I think for them this works well and they would not like it being removed for some less informative text.
We should not make such a change without fully understanding the why and how here. That's why I pick 'in discussion'. If we end up doing it, I want to be able to explain to the libraries why.
(In reply to Katrin Fischer from comment #13) > We should not make such a change without fully understanding the why and how > here. That's why I pick 'in discussion'. If we end up doing it, I want to be > able to explain to the libraries why. Imagine Patron A has a 'next available' hold and Patron B has an item level hold on Item A To find the holds on an item we call Koha::Item::current_holds - this will returnholds on the specific item, it will never find 'next available' holds because they are not on a specific item - We will display Patron B At checkin we actually check the holds, and we check hold_fill_targets at some level. The effect being that if you have not run the holds queue the item will fill the higher priority hold for Patron A, however, if you have built the holds queue it could do a few things: If there are multiple items available then Patron A may get assigned Item B for the queue and Patron B will get Item A - for this scenario Item A will trigger for patron B If there is only one available item then Patron A will be assigned Item A and Item A will trigger Patron A This scenario seems reasonable, the holds queue is going to try and fill the holds so that both patrons can get the item they want if it can. For display though we would need to check the DB for both hold_fill_targets and specific holds. I don't think this information of who gets the hold is so important on details, since we will resolve it at checkout, I think simply letting the librarian know this item is held should suffice. I will ask around internally for more opinions
First thought: the inconsistent capturing behavior is the more pressing issue here. Let's not lose that while addressing the wording on the item details. Second: I like changing the item details message to just "there is a hold on this item." The greater context of who the hold is for, where it will be picked up, and what priority it's at is all just a click away on the Holds tab, where it is presented in a clearer, more contextualized fashion. Making the note in item details try to give all that information is trying to shove a lot of detail into a small box, which sets us up for misunderstandings when folks don't read that information carefully.
Bug 20948 has hit PQA in favor of this one, sorry ;) Please reopen and explain if this cannot be closed. *** This bug has been marked as a duplicate of bug 20948 ***
Created attachment 95898 [details] [review] Bug 19288: Don't show patron info for item level holds on details.pl unless hold is waiting This persists after bug 20948 - we can still display patron information even if this patron is not the one who will receive the item upon checkin. The holds tab can give an overview of holds and information - I think on the details page the only info we need is whether there might be a item level hold, not who it is for To test: 1 - Place an item level hold for delivery at a branch not matching home branch of item 2 - Place a record level hold for delivery at homebranch of item placed on hold above 3 - Enable LocalHoldsPriority with 'pickup library' matches the item's 'home library' 4 - View the details for the page, it says the item has a hold for the patron with an item level hold 5 - Check in the item, the hold triggered is for the next available patron, ignore the hold 6 - Apply patch 7 - Check details page, 'There is an item-level hold (priority=1)' with no patron info 8 - Check in, next available hold is still the one triggered
Nick, does it depend on 20948 now ?
(In reply to Marcel de Rooy from comment #18) > Nick, does it depend on 20948 now ? Yes :-)
FAIL koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt FAIL filters missing_filter at line 367 ( There is an item level hold on this item (priority = [% hold.priority %]).)
Created attachment 100328 [details] [review] Bug 19288: Don't show patron info for item level holds on details.pl unless hold is waiting This persists after bug 20948 - we can still display patron information even if this patron is not the one who will receive the item upon checkin. The holds tab can give an overview of holds and information - I think on the details page the only info we need is whether there might be a item level hold, not who it is for To test: 1 - Place an item level hold for delivery at a branch not matching home branch of item 2 - Place a record level hold for delivery at homebranch of item placed on hold above 3 - Enable LocalHoldsPriority with 'pickup library' matches the item's 'home library' 4 - View the details for the page, it says the item has a hold for the patron with an item level hold 5 - Check in the item, the hold triggered is for the next available patron, ignore the hold 6 - Apply patch 7 - Check details page, 'There is an item-level hold (priority=1)' with no patron info 8 - Check in, next available hold is still the one triggered Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Had to rebase this to apply it.. works as expected.. Signing off
Signed off as it does what's described.. would be interested in an update from Andrew or Kelly regarding the requirements however prior to a QA run.
Created attachment 100632 [details] [review] Bug 19288: Don't show patron info for item level holds on details.pl unless hold is waiting This persists after bug 20948 - we can still display patron information even if this patron is not the one who will receive the item upon checkin. The holds tab can give an overview of holds and information - I think on the details page the only info we need is whether there might be a item level hold, not who it is for To test: 1 - Place an item level hold for delivery at a branch not matching home branch of item 2 - Place a record level hold for delivery at homebranch of item placed on hold above 3 - Enable LocalHoldsPriority with 'pickup library' matches the item's 'home library' 4 - View the details for the page, it says the item has a hold for the patron with an item level hold 5 - Check in the item, the hold triggered is for the next available patron, ignore the hold 6 - Apply patch 7 - Check details page, 'There is an item-level hold (priority=1)' with no patron info 8 - Check in, next available hold is still the one triggered Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 100633 [details] [review] Bug 19288: Don't show patron info for item level holds on details.pl unless hold is waiting This persists after bug 20948 - we can still display patron information even if this patron is not the one who will receive the item upon checkin. The holds tab can give an overview of holds and information - I think on the details page the only info we need is whether there might be a item level hold, not who it is for To test: 1 - Place an item level hold for delivery at a branch not matching home branch of item 2 - Place a record level hold for delivery at homebranch of item placed on hold above 3 - Enable LocalHoldsPriority with 'pickup library' matches the item's 'home library' 4 - View the details for the page, it says the item has a hold for the patron with an item level hold 5 - Check in the item, the hold triggered is for the next available patron, ignore the hold 6 - Apply patch 7 - Check details page, 'There is an item-level hold (priority=1)' with no patron info 8 - Check in, next available hold is still the one triggered Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Amended patch: fix indentation
Nice work everyone! Pushed to master for 20.05
Backported to 19.11.x branch for 19.11.05
backported to 19.05.x for 19.05.10
Minor patch will not be backported to 18.11.1x series