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.
This commit is contained in:
parent
8e8a5f914e
commit
4f32ba4323
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue