October 2018 - Koha-bugs - lists.koha-community.org

[Bug 11175] Show the parent record's component parts in the detailed views
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 paxed <pasi.kallinen(a)joensuu.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #79687|0 |1 is obsolete| | --- Comment #34 from paxed <pasi.kallinen(a)joensuu.fi> --- Created attachment 79803 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=79803&action=ed… Bug 11175: Show record component parts in the detail view Shows the component records of a host, on the host detail view in staff client or OPAC, with clickable links to the component records. Host has no linking entries to the components, but the components link to the host record via 773$w. Adds a new search index, Control-number-identifier (aka cni), which indexes the 003 controlfield. Adds a Yet Another System Preference, ShowComponentRecords, which can be used to turn this feature on or off in staff client and/or OPAC, and defaults to off. When looking up the component part records, the code searches for records with (773$w=Host001 and 003=Host003) or 773$w='Host003 Host001'. Except if UseControlNumber syspref is on, then it looks only for the Host field 001. Does not use easyanalytics. Only for MARC21 biblios - UNIMARC has not been updated. staff-global.css and opac.css have not been recreated, so you need to use sass to recreate those from staff-global.scss and opac.scss Test plan: 0) Apply patch 1) perl bulkmarcimport -file /tmp/easypiano.mrc -m MARCXML (This file is an attachment on the bug) 2) rebuild the zebra biblio index 3) Search for "easy piano" in staff client, and go to the biblio detail page. You should not see anything different in the record detail page. 4) Do the same on OPAC. 5) Change the ShowComponentRecords syspref appropriately and check the record detail page in staff client and OPAC. You should see a list of component part records. -- 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 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #105 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Created attachment 79800 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=79800&action=ed… Bug 8367: Removed unneccessary warns and commented code 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 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #104 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Created attachment 79799 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=79799&action=ed… Bug 8367: Template fixes + fixes to C4/Reserves.pm and Koha/Hold.pm Fixed waitingreserves.tt template so the borrowernumber is successfully passed to waitingreserves.pl upon cancelling a hold, so users can now successfully cancel holds from the waitingreserves.pl interface. Removed check for ReserveMaxPickupdateDelay in Koha/Hold.pm as this syspref is removed in the previous patch. Instead the expirationdate is calculated the same way as the lastpickupdatedate that is retrieving the holdpickupwait value for the appropriate issuingrule and then adding that onto the waiting date. Same test plan as main patch 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 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #103 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Created attachment 79798 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=79798&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 3 templates of staff client, you can see the 'Last pickup date' for an hold (circ/circulation.pl, circ/waitingreserves.pl, members/moremember.pl) 5. In opac-user.pl the last pickup date is displayed in the status-column if available. 5. 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: LETTER PLACEHOLDER (no code modifications here, just regression)* ****** ****** 1. Modify the RESERVESLIP->email Letter. Add "Last pickup date<<reserves.lastpickupdate>>" somewhere. 2. Make a hold for a borrower. 3. Catch the hold and print the reserve slip. Verify that the lastpickupdate is actually the (current date + the 'Holds pickup wait' in your issuing rules) in days. ** ** ** ** ** ** *** *** *** TEST: RESPECTING CALENDAR HOLIDAYS * ** ** ** ** ** ** 1) Note your ReservesMaxPickUpDelay setting. 2) Create and trap a hold 3) View waitingreserves.pl, note the last pickup date, and the pickup location 4) Cancel this hold 5) 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. 6) Repeat step 2 7) 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-letter, add <<reserves.lastpickupdate>> and <<reserves.waitingdate>> somewhere. 2. Catch a hold for a borrower. 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. Conflicts: installer/data/mysql/updatedatabase.pl -- 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 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Alex Buckley <alexbuckley(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #79791|0 |1 is obsolete| | -- 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 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Alex Buckley <alexbuckley(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #79790|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14715] Results per page setting for catalog search in staff client and OPAC
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14715 Aleisha Amohia <aleisha(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #79796|0 |1 is obsolete| | --- Comment #61 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- Created attachment 79797 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=79797&action=ed… Bug 14715: (follow-up) some code changes 1) adds sysprefs to sysprefs.sql 2) removes a merge conflict error that should not have been added -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14715] Results per page setting for catalog search in staff client and OPAC
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14715 --- Comment #60 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- Created attachment 79796 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=79796&action=ed… Bug 14715: (follow-up) some code changes 1) adds sysprefs to sysprefs.sql 2) removes a merge conflict error that should not have been added -- 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 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #102 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Created attachment 79791 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=79791&action=ed… Bug 8367: Template fixes + fixes to C4/Reserves.pm and Koha/Hold.pm Fixed waitingreserves.tt template so the borrowernumber is successfully passed to waitingreserves.pl upon cancelling a hold, so users can now successfully cancel holds from the waitingreserves.pl interface. Removed check for ReserveMaxPickupdateDelay in Koha/Hold.pm as this syspref is removed in the previous patch. Instead the expirationdate is calculated the same way as the lastpickupdatedate that is retrieving the holdpickupwait value for the appropriate issuingrule and then adding that onto the waiting date. Same test plan as main patch 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 02 Oct '18

02 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #101 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Created attachment 79790 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=79790&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 3 templates of staff client, you can see the 'Last pickup date' for an hold (circ/circulation.pl, circ/waitingreserves.pl, members/moremember.pl) 5. In opac-user.pl the last pickup date is displayed in the status-column if available. 5. 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: LETTER PLACEHOLDER (no code modifications here, just regression)* ****** ****** 1. Modify the RESERVESLIP->email Letter. Add "Last pickup date<<reserves.lastpickupdate>>" somewhere. 2. Make a hold for a borrower. 3. Catch the hold and print the reserve slip. Verify that the lastpickupdate is actually the (current date + the 'Holds pickup wait' in your issuing rules) in days. ** ** ** ** ** ** *** *** *** TEST: RESPECTING CALENDAR HOLIDAYS * ** ** ** ** ** ** 1) Note your ReservesMaxPickUpDelay setting. 2) Create and trap a hold 3) View waitingreserves.pl, note the last pickup date, and the pickup location 4) Cancel this hold 5) 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. 6) Repeat step 2 7) 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-letter, add <<reserves.lastpickupdate>> and <<reserves.waitingdate>> somewhere. 2. Catch a hold for a borrower. 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. Conflicts: installer/data/mysql/updatedatabase.pl -- You are receiving this mail because: You are watching all bug changes.

1 0