Is this still valid in 3.14?

Yes, it still happens for 3.14.1.

The same diagnostic.

Could you check with the master branch please? Maybe bug 11336 fixes your issue.

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)

Created attachment 24551 [details]
Updating reserve priority

A brief process description of this bug.

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.

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.

(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.

(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.

Kyle, could you give me your opinion on the solution I proposed please?

(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.

(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.

(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.

(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?

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.

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

(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

(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?

Jonathan, did you see this patch, too? bug 11947? Is that related to this, too?

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.

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>

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>

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>

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>

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>

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".

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.

(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

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

See bug#14364.

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