http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 bondiurbano <costalc@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - low |P3 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Melissa Lefebvre <melissa@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |melissa@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #3 from Jonathan Druart <jonathan.druart@biblibre.com> --- Could you check with the master branch please? Maybe bug 11336 fixes your issue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #5 from bondiurbano <costalc@gmail.com> --- Created attachment 24551 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=24551&action=edit Updating reserve priority A brief process description of this bug. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #7 from Jonathan Druart <jonathan.druart@biblibre.com> --- Created attachment 24582 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=24582&action=edit 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #9 from Jonathan Druart <jonathan.druart@biblibre.com> --- Created attachment 24584 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=24584&action=edit 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff --- Comment #11 from Jonathan Druart <jonathan.druart@biblibre.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #12 from bondiurbano <costalc@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #14 from bondiurbano <costalc@gmail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #16 from bondiurbano <costalc@gmail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #18 from Kyle M Hall <kyle@bywatersolutions.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #20 from bondiurbano <costalc@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #22 from Christopher Brannon <cbrannon@cdalibrary.org> --- (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 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #24 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 25943 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25943&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #26 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 25945 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25945&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=11956 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply CC| |katrin.fischer@bsz-bw.de --- Comment #30 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Alex Arnaud <alex.arnaud@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25942|0 |1 is obsolete| | --- Comment #31 from Alex Arnaud <alex.arnaud@biblibre.com> --- Created attachment 36811 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=36811&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Alex Arnaud <alex.arnaud@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25944|0 |1 is obsolete| | --- Comment #33 from Alex Arnaud <alex.arnaud@biblibre.com> --- Created attachment 36813 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=36813&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Alex Arnaud <alex.arnaud@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25946|0 |1 is obsolete| | --- Comment #35 from Alex Arnaud <alex.arnaud@biblibre.com> --- Created attachment 36815 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=36815&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |In Discussion --- Comment #36 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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". -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 --- Comment #38 from Christopher Brannon <cbrannon@cdalibrary.org> --- (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 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=14364 CC| |kyle.m.hall@gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 bondiurbano <costalc@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |RESOLVED Resolution|--- |DUPLICATE --- Comment #40 from bondiurbano <costalc@gmail.com> --- See bug#14364. *** This bug has been marked as a duplicate of bug 14364 *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.