September 2019 - Koha-bugs - lists.koha-community.org

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '19

19 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 David Gustafsson <glasklas(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #92426|0 |1 is obsolete| | --- Comment #131 from David Gustafsson <glasklas(a)gmail.com> --- Created attachment 92959 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92959&action=ed… Bug 8367: Altered expirationdate calc in Koha/Hold.pm and altered C4/Reserves/CancelExpiredReserves() Added check for holidays to expirationdate calculation in Koha/Hold.pm so the expirationdate respects holidays as the lastpickupdate does. Changed C4/Reserve/CancelExpiredReserves() to check the reserves.lastpickupdate rather than rserves.expirationdate. Therefore it will now automatically expire holds if they have not been picked up within the time period specified in the hold pickup delay defined in the issuing rules (which is added to reserves.waitingdate to calculate the reserves.lastpickupdate) AND the ExpireReservesMaxPickUpDelay syspref is enabled. Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '19

19 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 David Gustafsson <glasklas(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #92425|0 |1 is obsolete| | --- Comment #130 from David Gustafsson <glasklas(a)gmail.com> --- Created attachment 92958 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92958&action=ed… Bug 8367: How long is a hold waiting for pickup at a more granular level You can now specify a pickup delay for an hold function of a patron category and/or a item type and/or a library. The lastpickupdate-column is set based on the given instruction and lands only on an open library day. Also cancel_expired_reserves.pl now cancels only on open library days after the last pickup date has expired. And waitingreserves.pl respects the new DB column. If ReservesMaxPickUpDelay is not set prior to the databaseupdate, the holdspickupwait-directive is never defined, thus disabling this feature until the holdspickupwait is set. If the issuingrules holdspickupwait is 0 or less, this feature is disabled. So each issuingrule can disable this feature for the material it matches, while being fully functional with other rules. This patch adds: - a new column in the issuing rules, including help topics. - a new column reserves.lastpickupdate (+old_reserves) It contains the waitingdate + the corresponding "holds pickup wait". Each time the waitingdate is modified, this value will be modified too. - a new field issuingrules.holdspickupwait - a new function C4::Reserves::MoveWaitingdate() to help in testing this feature. - a new function C4::Reserves::GetLastPickupDate() to calculate the proper date from Calendar. This patch removes: - the ReservesMaxPickUpDelay syspref. - the ExpireReservesOnHolidays syspref, because it became obsolete due to the changes in handling the last pickup date with Koha Calendar. - Also removes a code section from C4::Letters::_parseLetter() which worked blatantly disrespectfully towards Koha Calendar. - TODO figure out how to rename existing letter placeholders <<expirationdate>> with <<lastpickupdate>> Unit tests included. $$$$$$$$$$$$$ $ TEST PLAN $ $$$$$$$$$$$$$ 0. BEFORE UPDATING THE DATABASE! MAKE SURE THAT THE SYSPREF 'ReservesMaxPickUpDelay' is bigger than 0. Otherwise existing reserves won't get UPDATEd with the new lastpickupdate-values. ****** ****** *** *** *** TEST: BASIC WORKFLOW * ****** ****** 1. Check there is no regression with a normal reserve workflow. 2. Add one or more issuingrules. 3. Update the new column 'Holds pickup wait' in your issuing rules. 4. In the following 3 templates of staff client, you can see the 'Last pickup date' for a hold -circ/circulation.pl, Circulation>Check outs>Search for Patron>Holds tab -circ/waitingreserves.pl Circulation>Holds awaiting pickup -members/moremember.pl Patrons>Search for patron>Holds tab 5. In opac-user.pl the last pickup date is displayed in the Status column if available. 6. According to a library and an item type, the lastpickupdate value will be equal to the waiting date + the "holds pickup wait" defined moved to the next open library day. ** ** ** ** ** ** *** *** *** TEST: RESPECTING CALENDAR HOLIDAYS * ** ** ** ** ** ** 1) Create and trap a hold 2) View waitingreserves.pl (Circulation>Holds awaiting pickup), note the last pickup date, and the pickup location 3) Cancel this hold 4) Edit the calendar for the given location, and make the pickup date a single, unrepeated, holiday. Then make the next day a weekly repeating holiday. Then make the next two days an annual holiday repeatable every year. 5) Repeat step 2 6) View waitingreserves.pl, the last pickup date for this new hold should now be increased by four days. ** ** ** ** ** ** *** *** *** TEST: LETTER lastpickupdate PLACEHOLDER AND REGRESSION * ** ** ** ** ** ** 1. Modify the HOLD_SLIP, add <<reserves.lastpickupdate>> and <<reserves.waitingdate>> somewhere. 2. Catch a hold for a borrower and print the slip. Verify that the lastpickupdate is actually (currentdate + the 'Holds pickup wait' in your issuing rules) in days. 3. See the members/notices.pl for the message queued and verify that the lastpickupdate-placeholder is set in your desired datetime format and that it is not on a holiday. Verify that the waitingdate is today. Originally Authored-by: Joonas Kylmälä <j.kylmala(a)gmail.com> Taken up by: Hayley Mapley and Alex Buckley (Catalyst IT) Sponsored-by: Brimbank District Council -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13193] Make Memcached usage fork safe
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '19

19 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13193 --- Comment #40 from Joonas Kylmälä <joonas.kylmala(a)helsinki.fi> --- (In reply to David Cook from comment #39) > Talked to Martin on IRC last night, and he was saying that we shouldn't > bother adding a test for this one, since it's too challenging to accurately > reproduce, and the testing I've already done seems sufficient. Ok, so now we just wait for Mirko's opinion on the dependency change. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13193] Make Memcached usage fork safe
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '19

19 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13193 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=23640 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15262] Run Koha Run. Koha search should be fast again.
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '19

19 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15262 --- Comment #8 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Mirko Tietgen from comment #6) > (13:52:14) tcohen: so, put search results in Koha::MetadataRecord object > (13:52:42) tcohen: and pass them through a pipe of Koha::Filter-s using the > Koha::RecordProcessor thing > (13:53:09) tcohen: that's from a perspective in which we re-organize the code > (13:53:29) tcohen: and start abstracting things a bit for a future > multi-metadata schema support ... > (13:55:58) tcohen: if you think about it, we are serializing/deserializing things more than 3 times Exactly. We're doing too much work processing search results. We need to streamline this process to avoid repeated handling, unnecessary lookups, etc. Besides getting performance improvements, we'll also gain some future-proofing by abstracting away from MARC based search result processing. I'd argue that we should be retrieving the bare minimum from Zebra and then doing the minimal amount of transforming possible. Failing that, if we have to fetch whole MARC records from Zebra, let's set up an optimized pipeline. I reckon that there's no *technical* reason that search shouldn't be fast in Koha. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15262] Run Koha Run. Koha search should be fast again.
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '19

19 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15262 --- Comment #7 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Blou from comment #4) > At this moment, hardware requirements to make a search feel "instantaneous" > are unrealistic to most libraries. I heartily disagree. Zebra is actually extremely fast. Often instantly fast. It's Koha that makes search slow, and we have the power to change that. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13193] Make Memcached usage fork safe
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '19

19 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13193 --- Comment #39 from David Cook <dcook(a)prosentient.com.au> --- Talked to Martin on IRC last night, and he was saying that we shouldn't bother adding a test for this one, since it's too challenging to accurately reproduce, and the testing I've already done seems sufficient. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23639] New: Hourly Loan Due Dates and checkin times calculated to the second but displayed to the minute
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '19

18 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23639 Bug ID: 23639 Summary: Hourly Loan Due Dates and checkin times calculated to the second but displayed to the minute Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When checking out an hourly loan, the date due is calculated out to the second, but the user only sees the time to the minute. Likewise, when an item is checked in the checkin time to accurate down to the second but only displayed to the minute. So, imagine: - An item is due at 10:00:00 - The item is checked in at 10:00:30 - The item is considered overdue, and the patron is charged a fine. - the patron record shows the item was due at 10:00 and was checked in at 10:00 and was for some reason considered late -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '19

18 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 Barbara Johnson <barbara.johnson(a)bedfordtx.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |barbara.johnson(a)bedfordtx.g | |ov -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '19

18 Sep '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #176 from David Gustafsson <glasklas(a)gmail.com> --- Rebased against current master and fixed some issues. -- You are receiving this mail because: You are watching all bug changes.

1 0