If you have an item that meets the holds requirement by the decreaseloanhighholds preference, but doesn’t get a decrease in the actual checkout period; you still get a popup notification that the high demand feature is being used and the loan period will be decreased. The notification shouldn't populate if the decreased loan period matches or is higher than the original loan period. The current behavior in the system looks at the the number of holds and doesn't take the loan periods with an equal value into consideration when enforcing the preference.
This is an annoyance and is confusing to staff. We may even be seeing some shorter period loans getting hit by this message, but I have yet to get my hands on examples. Just word of mouth right now. But we are definitely seeing the popup with equal loan periods.
I just added some information to bug 16387 that may be related to this. 1178 my $issuedate = DateTime->now( time_zone => C4::Context->tz() ); 1179 1180 my $calendar = Koha::Calendar->new( branchcode => $branch ); 1181 1182 my $itype = 1183 ( C4::Context->preference('item-level_itypes') ) 1184 ? $biblio->{'itype'} 1185 : $biblio->{'itemtype'}; 1186 1187 my $orig_due = C4::Circulation::CalcDateDue( $issuedate, $itype, $branch, $borrower ); 1188 1189 my $decreaseLoanHighHoldsDuration = C4::Context->preference('decreaseLoanHighHoldsDuration'); 1190 1191 my $reduced_datedue = $calendar->addDate( $issuedate, $decreaseLoanHighHoldsDuration ); 1192 1193 if ( DateTime->compare( $reduced_datedue, $orig_due ) == -1 ) { 1194 $return_data->{exceeded} = 1; 1195 $return_data->{duration} = $decreaseLoanHighHoldsDuration; 1196 $return_data->{due_date} = $reduced_datedue; I think because the time index in $reduced_datedue isn't the same as the time index in $orig_due, the two will never be equal, unless checked out at the time indicated in the $org_due. Therefore, if the original due date is in 14 days, and reduced due date is set to 14 days, the two are not going to match because of the time index. I'm thinking that if the other bug is resolved, this will be as well.
(In reply to Christopher Brannon from comment #2) > I'm thinking that if the other bug is resolved, this will be as well. Was it? Looks like bug 16387 is CLOSED FIXED now.