From 2c6cee5490c8a6043e85172c5e466db25d7df718 Mon Sep 17 00:00:00 2001 From: Martin Renvoize Date: Mon, 9 Mar 2026 09:29:26 +0000 Subject: [PATCH] Bug 41801: (QA follow-up) Guard lowestPriority rank clamping against empty rank When FixPriority is called with a reserve_id but no rank (rank defaults to ''), the empty string evaluates to 0 numerically, satisfying `$rank <= $highest_non_lowest_priority`. This caused the clamping block to unexpectedly set rank to a positive value, which then triggered an unintended splice and moved the hold. Add `$rank > 0` to the guard condition so the block only fires when an explicit positive rank was requested, matching the pre-existing semantics of the splice block below it. (cherry picked from commit 4f32ba432320f71f46b1d36d5846549b9e2de14f) Signed-off-by: Jacob O'Mara --- C4/Reserves.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/C4/Reserves.pm b/C4/Reserves.pm index 8750d3dd04..9a5add0e85 100644 --- a/C4/Reserves.pm +++ b/C4/Reserves.pm @@ -1812,7 +1812,7 @@ sub FixPriority { } # if this hold is marked lowest priority, we can only move it so far - if ( $hold && $hold->lowestPriority && $rank ne 'del' ) { + if ( $hold && $hold->lowestPriority && $rank ne 'del' && $rank > 0 ) { my $query = " SELECT max(priority) FROM reserves