December 2021 - Koha-bugs - lists.koha-community.org

[Bug 14210] Manage staged marc records deletes replaced item when undoing import into catalog
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14210 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew(a)bywatersolutions.com --- Comment #5 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- This is still true and still bad. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29740] New: New Organization field
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29740 Bug ID: 29740 Summary: New Organization field Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Would suggest we add a new field to the patron record called "organization". Currently we are storing organization names in the surname field. This is inaccurate, and causes some issues between validation (maybe custom validation) and switching from a patron type record and an organization record, especially if anything was left in a first name field at the time. Having a separate organization field would also allow us to correctly record an organization name and a contact at that organization. There are ways around this currently, but typical databases usually include a separate field for an organization name. This would also allow us to more accurately identify organizations with a specific contact person and include lines like "c/o: Joe Smith" under the organization name in notifications. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 9565] Deleting a record should alert or fail if there are current subscriptions
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9565 --- Comment #30 from marion.durand(a)biblibre.com --- (In reply to Andrew Fuerste-Henry from comment #28) > Doesn't apply cleanly to 21.05. Please rebase if needed. Thanks! The first 3 patch apply correctly. I attached the rebased version of the patch "Bug 9565: Use Koha::Biblio" I hope it will do. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9565] Deleting a record should alert or fail if there are current subscriptions
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9565 --- Comment #29 from marion.durand(a)biblibre.com --- Created attachment 128764 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128764&action=e… Bug 9565: Use Koha::Biblio (rebase for 21.05.x) Signed-off-by: Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10591] Why do we allow holds on restricted items (952$5=Use restrictions)? Place a hold for reference?
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10591 Florian <florian.bontemps(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |florian.bontemps(a)biblibre.c | |om --- Comment #5 from Florian <florian.bontemps(a)biblibre.com> --- Any news on this? We're trying to fix the weird traps behaviors (952$0, $1, $4 and $5) and the fact that there's nothing to prevent a hold on a restricted item seems weird to me. Not even a syspref. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14364] Allow automatically canceled expired waiting holds to fill the next hold
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 --- Comment #53 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 128759 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128759&action=e… Bug 14364: (follow-up) Cleanup duplicate code and adjust notices and prefs This patch removes a duplicated stanza left form moving routine Changes the routines to use inbound_library_address Improves the display if the system preferences Updates the update file Moves smaple notice -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14364] Allow automatically canceled expired waiting holds to fill the next hold
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 --- Comment #52 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 128758 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128758&action=e… Bug 14364: (QA follow-up) Generate message for transfers as well -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14364] Allow automatically canceled expired waiting holds to fill the next hold
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #120941|0 |1 is obsolete| | Attachment #120942|0 |1 is obsolete| | --- Comment #51 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 128757 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128757&action=e… Bug 14364: Allow automatically canceled expired waiting holds to fill the next hold Right now, if a library automatically cancels expired waiting holds, a librarian must still re-checkin an item to trap the next available hold for that item. It would be better if the next hold was automatically trapped and the librarians receive an email notification so they can make any changes to the item if need be ( hold area, hold slip in item, etc ). Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with one item 4) Place two holds on that record 5) Check in the item and set it to waiting for the first patron 6) Set ReservesMaxPickUpDelay to 1 7) Enable ExpireReservesMaxPickUpDelay 8) Enable ExpireReservesAutoFill 9) Set an email address in ExpireReservesAutoFillEmail 10) Modify the holds waitingdate to be in the past 11) Run misc/cronjobs/holds/cancel_expired_holds.pl 12) Note the hold is now waiting for the next patron 12) Note a waiting hold notification email was sent to that patron 13) Note a hold changed notification email was sent to the library Signed-off-by: Victoria Faafia <vfaafia29(a)gmail.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14364] Allow automatically canceled expired waiting holds to fill the next hold
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29727] New: Koha should respect NoRenewalBeforePrecision when No Renewal Before is unset
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '21

20 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29727 Bug ID: 29727 Summary: Koha should respect NoRenewalBeforePrecision when No Renewal Before is unset Change sponsored?: --- Product: Koha Version: master 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 To recreate: - create a circ rule for item type A, automatic renewal, No Renewal Before=0 - create a circ rule for item type B, automatic renewal, No Renewal Before unset - set NoRenewalBeforePrecision to Exact Time - check out an item of type A with a due date of today, 23:59 - check out an item of type B with a due date of today, 23:59 - perl /kohadevbox/koha/misc/cronjobs/automatic_renewals.pl -v - confirm neither checkout would have renewed, both would get auto_too_soon error - set NoRenewalBeforePrecision to Date - perl /kohadevbox/koha/misc/cronjobs/automatic_renewals.pl -v - confirm that item type A, where No Renewal Before=0, would have renewed - confirm that item type B, where No Renewal Before is unset, would have renewed We generally treat an unset No Renewal Before as equivalent to zero for automatic renewal. We should do the same here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2