From 4f32ba432320f71f46b1d36d5846549b9e2de14f Mon Sep 17 00:00:00 2001
From: Martin Renvoize <martin.renvoize@openfifth.co.uk>
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.
---
 C4/Reserves.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/C4/Reserves.pm b/C4/Reserves.pm
index ee2fa3e059..a16c088b58 100644
--- a/C4/Reserves.pm
+++ b/C4/Reserves.pm
@@ -1730,7 +1730,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