Bug 22753 - Move hold to top button doesn't work if waiting holds exist
Summary: Move hold to top button doesn't work if waiting holds exist
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: master
Hardware: All All
: P5 - low major (vote)
Assignee: Nick Clemens
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-22 21:56 UTC by Barton Chittenden
Modified: 2019-10-14 20:02 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:
19.05.00, 18.11.05


Attachments
Bug 22753: Fix hold priority adjustment, move to top (9.24 KB, patch)
2019-04-23 18:11 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 22753: Fix hold priority adjustment, move to top (9.28 KB, patch)
2019-04-23 18:57 UTC, Liz Rea
Details | Diff | Splinter Review
Bug 22753: (QA follow-up) fixing tabs (2.08 KB, patch)
2019-04-23 18:57 UTC, Liz Rea
Details | Diff | Splinter Review
Bug 22753: Fix hold priority adjustment, move to top (9.35 KB, patch)
2019-04-24 20:24 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 22753: Fix tabs pointed out by QA script (2.18 KB, patch)
2019-04-24 20:24 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Barton Chittenden 2019-04-22 21:56:40 UTC
On reserve/request.pl, clicking the green up arrow with a bar (the mouseover reads 'Move hold to top') doesn't move a hold up in priority if there is a waiting hold on the bib.

This is a regression between 18.05 and 18.11.

As a work-around, the change priority drop-down *does* work in 18.11.

The 'move hold up', 'move hold down' and 'move hold to bottom' buttons continue to work as well.
Comment 1 Nick Clemens 2019-04-23 18:11:45 UTC
Created attachment 88551 [details] [review]
Bug 22753: Fix hold priority adjustment, move to top

Since the holds table can be split we need to calculate the first priority for each table. However, currently we use the firs tin the loop, not taking into accoutn waiting status. This patchset sets the first_priority to the first non-found hold

Additionally, some cleanmup is done to not display the alter priority arrows for waiting holds

To test:
1 - Place several holds on a title
2 - Confirm one of the holds to be waiting
3 - Attempt to move the last hold to the top
4 - Nothing happens
5 - Apply patch
6 - Note that the waiting hold has no options to move in the list
7 - Attempt to move the last hold to the top
8 - It moves as expected!
9 - Split the holds queue by pickup library
10 - PLace some holds for pickup at another branch
11 - Confirm moving these holds works within their own table
12 - Unsplit the queue
13 - Ensure the holds end where you expect (moving in a split table didn't move above holds form another table)
Comment 2 Liz Rea 2019-04-23 18:57:18 UTC
Created attachment 88555 [details] [review]
Bug 22753: Fix hold priority adjustment, move to top

Since the holds table can be split we need to calculate the first priority for each table. However, currently we use the firs tin the loop, not taking into accoutn waiting status. This patchset sets the first_priority to the first non-found hold

Additionally, some cleanmup is done to not display the alter priority arrows for waiting holds

To test:
1 - Place several holds on a title
2 - Confirm one of the holds to be waiting
3 - Attempt to move the last hold to the top
4 - Nothing happens
5 - Apply patch
6 - Note that the waiting hold has no options to move in the list
7 - Attempt to move the last hold to the top
8 - It moves as expected!
9 - Split the holds queue by pickup library
10 - PLace some holds for pickup at another branch
11 - Confirm moving these holds works within their own table
12 - Unsplit the queue
13 - Ensure the holds end where you expect (moving in a split table didn't move above holds form another table)

Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Comment 3 Liz Rea 2019-04-23 18:57:35 UTC
Created attachment 88556 [details] [review]
Bug 22753: (QA follow-up) fixing tabs
Comment 4 Katrin Fischer 2019-04-24 20:24:41 UTC
Created attachment 88641 [details] [review]
Bug 22753: Fix hold priority adjustment, move to top

Since the holds table can be split we need to calculate the
first priority for each table. However, currently we use the
first in the loop, not taking into account the waiting status.
This patchset sets the first_priority to the first non-found hold

Additionally, some clean-up is done to not display the alter
priority arrows for waiting holds.

To test:
1 - Place several holds on a title
2 - Confirm one of the holds to be waiting
3 - Attempt to move the last hold to the top
4 - Nothing happens
5 - Apply patch
6 - Note that the waiting hold has no options to move in the list
7 - Attempt to move the last hold to the top
8 - It moves as expected!
9 - Split the holds queue by pickup library
10 - PLace some holds for pickup at another branch
11 - Confirm moving these holds works within their own table
12 - Unsplit the queue
13 - Ensure the holds end where you expect (moving in a split
     table didn't move above holds form another table)

Signed-off-by: Liz Rea <wizzyrea@gmail.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 5 Katrin Fischer 2019-04-24 20:24:45 UTC
Created attachment 88642 [details] [review]
Bug 22753: Fix tabs pointed out by QA script

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 6 Nick Clemens 2019-04-25 12:02:47 UTC
Awesome work all!

Pushed to master for 19.05
Comment 7 Martin Renvoize 2019-04-26 15:06:05 UTC
Pushed to 18.11.x for 18.11.05
Comment 8 Lucas Gass 2019-05-24 14:51:33 UTC
not necessary in 18.05.x, won't backport