Bug 11956 - Hold priorities not re-calculated when hold is confirmed and transferred on checkin
Summary: Hold priorities not re-calculated when hold is confirmed and transferred on c...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: 3.14
Hardware: All All
: P4 normal (vote)
Assignee: Robin Sheat
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-19 00:38 UTC by HB-NEKLS
Modified: 2015-06-04 23:23 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description HB-NEKLS 2014-03-19 00:38:41 UTC
In the process of testing bug 11947, discovered that if a hold is triggered as in transit to another branch and a new hold is added to the record later, the new hold gets a larger priority number than expected. 

Test plan to recreate:

1. Add six holds to a record, the first one needs to have a pickup location of a different branch than what you are logged in as. 
2. Trigger the hold for the first patron so the item goes into transit. 
3. Note that the holds priority for the record is now In Transit; 1; 2; 3; 4; 5. 
4. Add a hold for another patron to the same record. 
5. You expect a holds priority of 6, but it is set as 7. 
6. Add a hold for another patron to the same record.
7. You expect a holds priority of 7, but it is set as 8.
Comment 1 Robin Sheat 2014-03-21 01:25:39 UTC
I tested with and without the patch from bug 11947, and (in master) it fixes this case too. Can you confirm?
Comment 2 HB-NEKLS 2014-08-12 20:15:55 UTC
Robin, yes I can finally confirm that this patch and/or something in 3.14.8 release appears to fix this bug. I'm marking it resolved.