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