[Bug 23054] New: Unable to change priority after reverting hold waiting status
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23054 Bug ID: 23054 Summary: Unable to change priority after reverting hold waiting status Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: andrew@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com Target Milestone: --- To Test: - Place a hold for Patron A - Place a hold on same item for Patron B - Check item in, triggering Patron A's hold - Revert waiting status on hold - Confirm holds list shows Patron A at priority 1, Patron B at priority 2 - Use arrow buttons to move Patron B to priority 1 - Query reserves table to confirm Patron B at priority 1, Patron A at priority 2 - Check item in - Patron A's hold triggers, even though Patron B was first in priority -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23054 --- Comment #1 from Andrew <andrew@bywatersolutions.com> --- Possible this behavior is actually an offshoot of bug 19288. Following my test plan, we start with two bib-level holds, but Patron A's hold becomes item-level when reverted (see bug 9834). At that point we have one bib hold and one item hold, which bug 19288 says will perform inconsistently. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23054 Esther Melander <esther.melander@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |esther.melander@bywatersolu | |tions.com --- Comment #2 from Esther Melander <esther.melander@bywatersolutions.com> --- This problem still exists. I was able to replicate the example scenario. But the problem persists even after canceling the hold for patron A. To replicate: 1. Follow all of the steps of the scenario from Andrew. 2. Delete the hold for Patron A 3. Place the hold for Patron A again and move them to the top of the list. 4. Try trapping the hold The hold traps for Patron B, skipping the newly placed hold for Patron A at the top of the list. The overall problem is the Holds List priority that is seen on screen is not being respected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org