Bug 10827 - List of holds does not update correctly
Summary: List of holds does not update correctly
Status: RESOLVED DUPLICATE of bug 14364
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P3 normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-05 12:13 UTC by Claudio Costales
Modified: 2015-11-25 17:48 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Updating reserve priority (148.88 KB, application/force-download)
2014-01-19 02:00 UTC, Claudio Costales
Details
Bug 10827: Regression tests (6.94 KB, patch)
2014-01-20 16:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 10827: Change prototype for ModReserveAffect (8.54 KB, patch)
2014-01-20 16:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 10827: Check if the item should be transfered in ModReserveAffect (4.74 KB, patch)
2014-01-20 16:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 10827: Update item-level holds if deletion (1.07 KB, patch)
2014-01-20 16:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 10827: destBranch tt param is useless (3.01 KB, patch)
2014-01-20 16:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 10827: Regression tests (7.01 KB, patch)
2014-03-07 17:07 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10827: Change prototype for ModReserveAffect (8.59 KB, patch)
2014-03-07 17:07 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10827: Check if the item should be transfered in ModReserveAffect (4.79 KB, patch)
2014-03-07 17:07 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10827: Update item-level holds if deletion (1.14 KB, patch)
2014-03-07 17:07 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10827: destBranch tt param is useless (3.07 KB, patch)
2014-03-07 17:08 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10827: Regression tests (7.00 KB, patch)
2015-03-11 16:09 UTC, Alex Arnaud
Details | Diff | Splinter Review
Bug 10827: Change prototype for ModReserveAffect (8.66 KB, patch)
2015-03-11 16:09 UTC, Alex Arnaud
Details | Diff | Splinter Review
Bug 10827: Check if the item should be transfered in ModReserveAffect (4.81 KB, patch)
2015-03-11 16:10 UTC, Alex Arnaud
Details | Diff | Splinter Review
Bug 10827: Update item-level holds if deletion (1.12 KB, patch)
2015-03-11 16:10 UTC, Alex Arnaud
Details | Diff | Splinter Review
Bug 10827: destBranch tt param is useless (3.12 KB, patch)
2015-03-11 16:10 UTC, Alex Arnaud
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Claudio Costales 2013-09-05 12:13:07 UTC
When an item has many patron's holds and it is checked-in, the first priority patron hold in the list of holds is set as "waiting". Then when this hold expires o is cancelled the hole list of holds doesn't update: the next patron in the list of holds "keeps on hold" but not "waiting" and no email is inserted in the message queue table.
Comment 1 Jonathan Druart 2013-12-24 13:15:44 UTC
Is this still valid in 3.14?
Comment 2 Claudio Costales 2014-01-15 23:05:57 UTC
Yes, it still happens for 3.14.1.

The same diagnostic.
Comment 3 Jonathan Druart 2014-01-16 09:58:04 UTC
Could you check with the master branch please? Maybe bug 11336 fixes your issue.
Comment 4 Claudio Costales 2014-01-17 22:40:31 UTC
Jonathan, thanks for being patient with me. I am not a programmer and sadly can not help you in the way you ask me for. I can help you in "process" analisys. Anyway I read the bug 11336. As long as I understand the issue I am reporting is not included in 11336. The issue is constrained to hold status/prioriry  "Waiting", i.e., anywhere in Koha (Staff or OPAC) when a hold with status "Waiting" is cancelled or deleted the next hold that follows the cancelled or deleted hold SHOULD BE UPDATED to status/prioriry "Waiting" and a mail sould be sent to the patron.
I was testing this issue locally at /cgi-bin/koha/reserve/request.pl?biblionumber=383

Hope this helps...(my english is not the best. I can write in spanish)
Comment 5 Claudio Costales 2014-01-19 02:00:25 UTC
Created attachment 24551 [details]
Updating reserve priority

A brief process description of this bug.
Comment 6 Jonathan Druart 2014-01-20 16:25:07 UTC Comment hidden (obsolete)
Comment 7 Jonathan Druart 2014-01-20 16:25:19 UTC Comment hidden (obsolete)
Comment 8 Jonathan Druart 2014-01-20 16:25:26 UTC Comment hidden (obsolete)
Comment 9 Jonathan Druart 2014-01-20 16:25:32 UTC Comment hidden (obsolete)
Comment 10 Jonathan Druart 2014-01-20 16:25:37 UTC Comment hidden (obsolete)
Comment 11 Jonathan Druart 2014-01-20 16:28:15 UTC
Easy to reproduce but not easy to fix.
I really would like to have some feedback.

I did not manage to deal with biblio-level holds.
Comment 12 Claudio Costales 2014-01-20 17:33:55 UTC
Jonathan, I don't know how biblio-level works about reserves because I can't imagine this. It doesn't seem relevant for reserves. I can't think how a biblio may be reserved..

Reserves are referred to holding's barcode, i.e., at item-level. 

The difference between reserves and regular issues is that reserves are not involved in circulation rules as fines policy are (that is where biblio-level may fit..). They work independently.

Reserves and fines have no relation between them. Both are included in each circulation rule but it's a design matter.
Comment 13 Jonathan Druart 2014-01-21 08:55:26 UTC
(In reply to bondiurbano from comment #12)
A biblio-level hold is a reserve on the next available item.
An item-level hold is a reserve on a specific item.
Comment 14 Claudio Costales 2014-01-21 11:31:43 UTC
(In reply to Jonathan Druart from comment #13)
> (In reply to bondiurbano from comment #12)
> A biblio-level hold is a reserve on the next available item.
> An item-level hold is a reserve on a specific item.

Ok Jonathan, thanks for the information. The important matter is that priority "Waiting" always refers to an item because an item has just been checked-in. Look at the document I uploaded: step 2 says "next available" but step 4 ("Waiting" priority) says barcode 200. So when a reserve in priority "Waiting" for barcode 200 is deleted or cancelled next reserve in the holds queue should be updated to priority "Waiting" for barcode 200 for the next patron. There's no confusion about it. At this point difference between biblio or item level should be irrelevant. The program must procedure at item level.
Comment 15 Jonathan Druart 2014-01-21 11:47:06 UTC
Kyle, could you give me your opinion on the solution I proposed please?
Comment 16 Claudio Costales 2014-01-21 12:06:20 UTC
(In reply to bondiurbano from comment #14)
> (In reply to Jonathan Druart from comment #13)
> > (In reply to bondiurbano from comment #12)
> > A biblio-level hold is a reserve on the next available item.
> > An item-level hold is a reserve on a specific item.
> 
> Ok Jonathan, thanks for the information. The important matter is that
> priority "Waiting" always refers to an item because an item has just been
> checked-in. Look at the document I uploaded: step 2 says "next available"
> but step 4 ("Waiting" priority) says barcode 200. So when a reserve in
> priority "Waiting" for barcode 200 is deleted or cancelled next reserve in
> the holds queue should be updated to priority "Waiting" for barcode 200 for
> the next patron. There's no confusion about it. At this point difference
> between biblio or item level should be irrelevant. The program must
> procedure at item level.

Jonathan, a tip: now, when a reserve with priority "Waiting" is deleted or cancelled you can check-in the item AGAIN, Koha will ask for confirmation and next reserve in the holds queue is updated correctly!! Yes, it is possible to check-in items not issued but with reserves in holds queue...

1) Delete or cancel "Waiting" priority reserve
2) Check-in the item again
3) Confirm reserve for next patron
4) Priority for next patron reserve is updated correctly.
Comment 17 Kyle M Hall 2014-01-21 12:35:58 UTC
(In reply to bondiurbano from comment #14)
> (In reply to Jonathan Druart from comment #13)
> > (In reply to bondiurbano from comment #12)
> > A biblio-level hold is a reserve on the next available item.
> > An item-level hold is a reserve on a specific item.
> 
> Ok Jonathan, thanks for the information. The important matter is that
> priority "Waiting" always refers to an item because an item has just been
> checked-in. Look at the document I uploaded: step 2 says "next available"
> but step 4 ("Waiting" priority) says barcode 200. So when a reserve in
> priority "Waiting" for barcode 200 is deleted or cancelled next reserve in
> the holds queue should be updated to priority "Waiting" for barcode 200 for
> the next patron. There's no confusion about it. At this point difference
> between biblio or item level should be irrelevant. The program must
> procedure at item level.

If I am interpreting your assertion correctly, you are incorrect. You are only looking at a single possible scenario. What if the next hold is for pickup at a different library, what if the next hold is cannot be filled by this item because of issuing rules? We cannot simply assume the next hold can be filled automatically by a canceled waiting hold item.
Comment 18 Kyle M Hall 2014-01-21 12:38:10 UTC
(In reply to bondiurbano from comment #14)
> > So when a reserve in
> > priority "Waiting" for barcode 200 is deleted or cancelled next reserve in
> > the holds queue should be updated to priority "Waiting" for barcode 200 for
> > the next patron. There's no confusion about it. At this point difference
> > between biblio or item level should be irrelevant. The program must
> > procedure at item level.

I should also mention Koha has *never* automatically set a hold to waiting. It has always been a manually triggered process where a library checks in an item, and chooses to trap the item for the hold request.
Comment 19 Jonathan Druart 2014-01-21 12:46:32 UTC
(In reply to Kyle M Hall from comment #18)
> I should also mention Koha has *never* automatically set a hold to waiting.

But should it be managed or not?
Comment 20 Claudio Costales 2014-01-21 13:05:56 UTC
Kyle, read "my" tip in comment #16. I had never said that it was a simple matter. I'd tried to focus on "priority concept". (Im not a programmer).

I'm not assuming only one scenario. When the next hold is tried to be updated (to priority "Waiting") it enters in regular basis of control as a reserve creation is done when an item is checked-in. So it may be possible or not to update the priority. It depends on the same factors that checked-in items depends.
Comment 21 Christopher Brannon 2014-02-21 17:11:33 UTC
I would like to chime in.  If I am understanding the request of this "bug", I agree with Kyle in that an item should only be set to Waiting status if it is checked in.  Simply cancelling the top hold request, whether waiting, in transit, or other should not automatically set the next request to Waiting, unless perhaps the ReservesNeedReturns preference is set to Automatic, and all conditions are met.

The condition of this "bug" and the intent for change is unclear and needs more clarification.

Christopher
Comment 22 Christopher Brannon 2014-02-21 17:14:05 UTC
(In reply to Christopher Brannon from comment #21)
> I would like to chime in.  If I am understanding the request of this "bug",
> I agree with Kyle in that an item should only be set to Waiting status if it
> is checked in.  Simply cancelling the top hold request, whether waiting, in
> transit, or other should not automatically set the next request to Waiting,
> unless perhaps the ReservesNeedReturns preference is set to Automatic, and
> all conditions are met.
> 
> The condition of this "bug" and the intent for change is unclear and needs
> more clarification.
> 
> Christopher

Nevermind.  I got caught up and read comment 16.  Sorry.

Christopher
Comment 23 Kyle M Hall 2014-03-07 17:07:30 UTC Comment hidden (obsolete)
Comment 24 Kyle M Hall 2014-03-07 17:07:49 UTC Comment hidden (obsolete)
Comment 25 Kyle M Hall 2014-03-07 17:07:53 UTC Comment hidden (obsolete)
Comment 26 Kyle M Hall 2014-03-07 17:07:57 UTC Comment hidden (obsolete)
Comment 27 Kyle M Hall 2014-03-07 17:08:01 UTC Comment hidden (obsolete)
Comment 28 Jonathan Druart 2014-03-10 08:26:00 UTC
(In reply to Kyle M Hall from comment #27)
> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Do you finally agree with this patch?
Comment 29 HB-NEKLS 2014-03-19 15:24:37 UTC
Jonathan, did you see this patch, too? bug 11947? Is that related to this, too?
Comment 30 Katrin Fischer 2014-04-20 11:47:22 UTC
I looked at this code a while ago, but had to stop testing in the midst of it. 
Now the patches no longer apply as we have changed a lot of other things in this area in the last few days, so I can't test.

From memory: the removal of destBranch didn't seem quite right.

Also the described behaviour worried me:

"- Verify the hold list:
  The item is waiting for B and C has a priority 2
- Delete the hold for B
- Now you can see the item is not waiting for C. He has not been
  notified neither.

If you apply all patches from this bug, at the next step, the item is
marked as waiting for C and C has been notified when the hold for B has
been deleted."

If I read this correctly, the item would be set to waiting automatically and trigger the notice to the patron. I am not sure if this is a good idea. I think setting the waiting status should always require a check in. This way the correct slip can be printed and mistakes are much less likely. - Like sending the book back to the shelf, when it should remain at the circulation desk.
Comment 31 Alex Arnaud 2015-03-11 16:09:42 UTC
Created attachment 36811 [details] [review]
Bug 10827: Regression tests

The unit tests in the file db_dependent/Reserves/priorities.t describe
the issue.

To reproduce using the interface:
- Create 3 patrons A, B and C
- Check an item out to A
- Place a hold on this item for B and C
- Check the item in
- Confirm the hold
- Verify the hold list:
  The item is waiting for B and C has a priority 2
- Delete the hold for B
- Now you can see the item is not waiting for C. He has not been
  notified neither.

If you apply all patches from this bug, at the next ste, the item is
marked as waiting for C and C has been notified when the hold for B has
been deleted.

/!\Important note: This patch only manages item-level holds!
The commented UT is for biblio-level holds.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 32 Alex Arnaud 2015-03-11 16:09:53 UTC
Created attachment 36812 [details] [review]
Bug 10827: Change prototype for ModReserveAffect

This patch only changes the prototype for
C4::Reserves::ModReserveAffect.
This modification will allow to simplify future changes.
No change should be expected with this patch.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 33 Alex Arnaud 2015-03-11 16:10:00 UTC
Created attachment 36813 [details] [review]
Bug 10827: Check if the item should be transfered in ModReserveAffect

Before this patch, ModReserveAffect should know if the item have to be
transfered. Now it is checked in the routine.

Moreover, it is possible to pass an item key in parameters.
If it is not given, the item's information is retrieved from
GetBiblioFromItemNumber.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 34 Alex Arnaud 2015-03-11 16:10:06 UTC
Created attachment 36814 [details] [review]
Bug 10827: Update item-level holds if deletion

If a lower level priority hold is deleted, the next on the list should
be marked as 'waiting' and the patron notified.

This patch only affects item-level holds.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 35 Alex Arnaud 2015-03-11 16:10:13 UTC
Created attachment 36815 [details] [review]
Bug 10827: destBranch tt param is useless

With previous changes, the destBranch passed to the template become
useless and can be removed.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 36 Katrin Fischer 2015-03-15 21:30:57 UTC
Please take a look at my comment #30.  I am not in favor of setting the waiting status automatically. In my opinion this should always require a check in, so that we can trigger the printing of the next slip.

Moving this to "In discussion".
Comment 37 Katrin Fischer 2015-03-15 22:07:22 UTC
Apart from the general question if this is desirable behaviour, a quick test showed a problem:

1) Place a title level hold for A
2) Place an item level hold for B
3) Check in item
4) Confirm hold for A
5) Check hold list: Both holds are marked waiting.

Repeated the test after deleting both holds with 2 item level holds, same result.
Comment 38 Christopher Brannon 2015-03-16 14:30:09 UTC
(In reply to Katrin Fischer from comment #36)
> Please take a look at my comment #30.  I am not in favor of setting the
> waiting status automatically. In my opinion this should always require a
> check in, so that we can trigger the printing of the next slip.
> 
> Moving this to "In discussion".

I agree with Katrin on this point.  If this patch automatically triggers a hold when an existing hold is cancelled or expired, this WILL create a big mess.  Libraries like ours put the holds out on a shelf for patrons to pickup.  They are marked with slips for patrons to identify their items.

Having the next hold triggered automatically creates a mess for both staff and patron.  The patron will get notified that their hold is waiting, but won't be able to find it.  Staff will not have any idea what slips need updating.  Items will be lost on the hold shelves.  Cats and dogs will fall in love.  It would be chaos.

What NEEDS to happen is a better notification to staff of these expired and cancelled holds, so we can get to them quicker.  It would be HIGHLY recommended that cancelled holds and expired holds don't show as available in Koha, but show as a status that it is waiting for some sort of handling, so that staff have a clue where the item is.  It would also be HIGHLY recommended if BOTH expired AND cancelled holds showed up on the Holds Over list in the Holds Awaiting Pickup report.  Perhaps even an alert on the staff home page.

That's my two cents.

Christopher
Comment 39 Kyle M Hall 2015-09-22 11:12:01 UTC
I think you will find bug 14364 interesting Christopher!

(In reply to Christopher Brannon from comment #38)
> (In reply to Katrin Fischer from comment #36)
> > Please take a look at my comment #30.  I am not in favor of setting the
> > waiting status automatically. In my opinion this should always require a
> > check in, so that we can trigger the printing of the next slip.
> > 
> > Moving this to "In discussion".
> 
> I agree with Katrin on this point.  If this patch automatically triggers a
> hold when an existing hold is cancelled or expired, this WILL create a big
> mess.  Libraries like ours put the holds out on a shelf for patrons to
> pickup.  They are marked with slips for patrons to identify their items.
> 
> Having the next hold triggered automatically creates a mess for both staff
> and patron.  The patron will get notified that their hold is waiting, but
> won't be able to find it.  Staff will not have any idea what slips need
> updating.  Items will be lost on the hold shelves.  Cats and dogs will fall
> in love.  It would be chaos.
> 
> What NEEDS to happen is a better notification to staff of these expired and
> cancelled holds, so we can get to them quicker.  It would be HIGHLY
> recommended that cancelled holds and expired holds don't show as available
> in Koha, but show as a status that it is waiting for some sort of handling,
> so that staff have a clue where the item is.  It would also be HIGHLY
> recommended if BOTH expired AND cancelled holds showed up on the Holds Over
> list in the Holds Awaiting Pickup report.  Perhaps even an alert on the
> staff home page.
> 
> That's my two cents.
> 
> Christopher
Comment 40 Claudio Costales 2015-11-25 17:48:23 UTC
See bug#14364.

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