Bug 17143 - Popup Notification for decreaseloanhighholds preference
Summary: Popup Notification for decreaseloanhighholds preference
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: 3.22
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 16387
Blocks:
  Show dependency treegraph
 
Reported: 2016-08-18 01:28 UTC by Jessie Zairo
Modified: 2020-04-16 12:07 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jessie Zairo 2016-08-18 01:28:33 UTC
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.
Comment 1 Christopher Brannon 2016-08-18 14:23:51 UTC
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.
Comment 2 Christopher Brannon 2016-08-19 21:02:06 UTC
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.
Comment 3 Magnus Enger 2020-04-16 12:07:10 UTC
(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.