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 4f32ba4323)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
This commit is contained in:
Martin Renvoize 2026-03-09 09:29:26 +00:00 committed by Jacob O'Mara
parent 590f1360eb
commit 2c6cee5490
No known key found for this signature in database
1 changed files with 1 additions and 1 deletions

View File

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