May 2017 - Koha-bugs - lists.koha-community.org

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #73 from Alex Arnaud <alex.arnaud(a)biblibre.com> --- And note that CancelExpiredReserves is only caled by the script misc/cronjobs/holds/cancel_expired_holds.pl. Nowhere else if i'm not wrong. So if we remove the check of ExpireReservesMaxPickUpDelay from this sub, we get a kind of "force cancel reserves". -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #72 from Alex Arnaud <alex.arnaud(a)biblibre.com> --- (In reply to Marcel de Rooy from comment #71) > The situation I described is independent of this pref. You could use the > cron job to remove expired reserves based on expiration dates entered by > patrons. > Difficult to decide the issue. The behavior of sub CancelExpiredReserves was before: - Cancel holds with an expiration date (asked by the patron afaik), - Cancel other exipred holds only if ExpireReservesMaxPickUpDelay is set to allow So now we have all waiting reerves with an expiration date, we can't make the difference between those with expiration ask by the patron and those with expiration calculated. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 18291] New: Remove SQL from preferences.pl administrative script
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18291 Bug ID: 18291 Summary: Remove SQL from preferences.pl administrative script Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This bug report requires the removal of SQL code from the preferences.pl administrative script into a separate perl module. It also requires the creation of unit tests and POD for the new subroutines in the perl modules. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #71 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Alex Arnaud from comment #69) > (In reply to Marcel de Rooy from comment #68) > > sub CancelExpiredReserves { > > + return unless C4::Context->preference("ExpireReservesMaxPickUpDelay"); > > This may have a unwanted side-effect. If we do not use the pickup delay, but > > still want to cancel expired reserves. > > You mean: If ExpireReservesMaxPickUpDelay is set to don't allow ? If yes, > this is because we don't want to cancel expired reserves right ? Or i don't > understand the syspref. The situation I described is independent of this pref. You could use the cron job to remove expired reserves based on expiration dates entered by patrons. > > sub set_waiting { > > [...] > > + if ( C4::Context->preference("ExcludeHolidaysFromMaxPickUpDelay") ) { > > + $expirationdate = $calendar->days_forward( > > dt_from_string($self->waitingdate), $max_pickup_delay ); > > + } > > This may cause something weird. If you do a second > > Is it possible that the code of set_waiting (after tranferToDo) should be > called 2 times for the same reserve ? As mentioned, this is exceptional. But it can be easily simulated. Check this book in today and perhaps by accident tomorrow (it was still on the desk or something like that). Two separate checkins, two calls. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9156] itemcallnumber not pulling more than 2 subfields
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9156 Marjorie Barry-Vila <marjorie.barry-vila(a)ccsr.qc.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila(a)ccsr.qc | |.ca -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #70 from Alex Arnaud <alex.arnaud(a)biblibre.com> --- (In reply to Alex Arnaud from comment #69) > (In reply to Marcel de Rooy from comment #68) > > sub set_waiting { > > [...] > > + if ( C4::Context->preference("ExcludeHolidaysFromMaxPickUpDelay") ) { > > + $expirationdate = $calendar->days_forward( > > dt_from_string($self->waitingdate), $max_pickup_delay ); > > + } > > This may cause something weird. If you do a second > > Is it possible that the code of set_waiting (after tranferToDo) should be > called 2 times for the same reserve ? Anyway it doesn't hurt to pass today to days_forward. So i'll fix it -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #69 from Alex Arnaud <alex.arnaud(a)biblibre.com> --- (In reply to Marcel de Rooy from comment #68) > Still working on this one now. > Preliminary results: > > sub CancelExpiredReserves { > + return unless C4::Context->preference("ExpireReservesMaxPickUpDelay"); > This may have a unwanted side-effect. If we do not use the pickup delay, but > still want to cancel expired reserves. You mean: If ExpireReservesMaxPickUpDelay is set to don't allow ? If yes, this is because we don't want to cancel expired reserves right ? Or i don't understand the syspref. > > sub set_waiting { > [...] > + if ( C4::Context->preference("ExcludeHolidaysFromMaxPickUpDelay") ) { > + $expirationdate = $calendar->days_forward( > dt_from_string($self->waitingdate), $max_pickup_delay ); > + } > This may cause something weird. If you do a second Is it possible that the code of set_waiting (after tranferToDo) should be called 2 times for the same reserve ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #68 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Still working on this one now. Preliminary results: sub CancelExpiredReserves { + return unless C4::Context->preference("ExpireReservesMaxPickUpDelay"); This may have a unwanted side-effect. If we do not use the pickup delay, but still want to cancel expired reserves. It is no longer possible. (Note that patrons may have entered expiration dates too.) Not marking this as a blocker, since this is probably exceptional. Do you have an easy fix or can you open a new report for it? sub set_waiting { [...] + if ( C4::Context->preference("ExcludeHolidaysFromMaxPickUpDelay") ) { + $expirationdate = $calendar->days_forward( dt_from_string($self->waitingdate), $max_pickup_delay ); + } This may cause something weird. If you do a second checkin while the waitingdate is say yesterday, the waitingdate is set to today but the expiration date will be based upon the old waitingdate. Again probably exceptional, but still something to fix. I would opt here for basing the expiry on today, since we reset the waitingdate too. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7317] Add an Interlibrary Loan Module to Circulation and OPAC
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317 Magnus Enger <magnus(a)libriotech.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #28 from Magnus Enger <magnus(a)libriotech.no> --- It also looks like there is a missing "use Koha::Illrequests;" in Koha/Illrequest.pm? When I try to use Koha::Illrequest in the Dancer-based NCIPServer I get this error: [24015] error @1.447857> [hit #5]request to POST / crashed: Can't locate object method "search" via package "Koha::Illrequests" (perhaps you forgot to load "Koha::Illrequests"?) at /path/to/kohaclone/Koha/Illrequest.pm line 684. in /usr/share/perl5/Dancer/Handler.pm l. 98 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5456] Create a link to opac-ics.pl
by bugzilla-daemon＠bugs.koha-community.org 03 May '17

03 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5456 --- Comment #14 from Magnus Enger <magnus(a)libriotech.no> --- (In reply to John Andrews from comment #13) > There's a problem with the lack of end time -- when importing this into my > outlook calendar, because there's no end time, outlook automatically creates > an hour long event. Which means that the due date reminder shows up both on > the due date, and on the day AFTER the due date. In our case, the time due > is 11:59 pm, so the appointment gets created in outlook as from 11:59 pm on > the due date until 12:59 am on the next day. Is there a way to force the > appointment to start and end at the same time? Please report this as a new bug/issue. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0