July 2022 - Koha-bugs - lists.koha-community.org

[Bug 29007] New: Prompt for reason when cancelling waiting hold via popup
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '24

08 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29007 Bug ID: 29007 Summary: Prompt for reason when cancelling waiting hold via popup 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 Depends on: 25534 To recreate: - have a HOLD_CANCELLATION auth value - have an item waiting for pickup for a hold - check the item in, prompting the "item is already waiting" popup - on that popup, select "Cancel" - the hold is cancelled and you are not given a chance to apply a reason Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25534 [Bug 25534] Add ability to specifying and store a reason when cancelling a hold -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 23894] New: accountlines.payment_type and accountlines.credit_type should be merged
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '24

08 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23894 Bug ID: 23894 Summary: accountlines.payment_type and accountlines.credit_type should be merged Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com During the implementation of bug 23805 and bug 23049 it became apparent to me that the introduction of payment_type appeared to be a workaround for the lack of distinct credit and debit categories. Now we have a distinct credit_type field in accountlines which is properly governed by foreign key relationships I believe we could merge the payment_type field with this credit_type field and expose a purpose build UI for managing such types. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 20489] New: Prevent DB user login
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20489 Bug ID: 20489 Summary: Prevent DB user login Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Since we have the onboarding tool that create a superlibrarian patron as well as a misc script (misc/devel/create_superlibrarian.pl), we could reject login with the DB user. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 18936] New: Convert issuingrules fields to circulation_rules
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18936 Bug ID: 18936 Summary: Convert issuingrules fields to circulation_rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 18930 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18930 [Bug 18930] Move lost item refund rules to circulation_rules table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 226

[Bug 21487] New: Disable CataloguingLog syspref in UNIMARC_sync_date_created_with_marc_biblio.pl
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21487 Bug ID: 21487 Summary: Disable CataloguingLog syspref in UNIMARC_sync_date_created_with_marc_biblio.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Script UNIMARC_sync_date_created_with_marc_biblio.pl edits MARC record to define 099 $c and $d. This should not be registered as a cataloguing change in action_logs table. So script must disable CataloguingLog syspref (if enabled) during its process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 26268] New: Remove items.paidfor once and for all
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26268 Bug ID: 26268 Summary: Remove items.paidfor once and for all Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 18501, 23463, 19919 In bug 19919 we removed all references to setting, unsettling and referring to the paidfor field but we neglected to actually drop the field from the database (I think I intended to do this, but was asking for feedback on the approach before adding the actual db change.. then completely forgot when it went through SO/QA quickly). In bug 23463 we inadvertently re-introduced some of the setting code during a rebase. In bug 18501 we then moved that inadvertently re-introduced setter into Koha::Item->store. We should kill it off once and for all! Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18501 [Bug 18501] Automatic refunds need protection from failure https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19919 [Bug 19919] Writing off a Lost Item Fee marks as "Paid for by patron" https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23463 [Bug 23463] Move C4::Items CRUD subroutines to Koha::Item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 62

[Bug 24786] New: Allow setting a cash register for a login session
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24786 Bug ID: 24786 Summary: Allow setting a cash register for a login session Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: martin.renvoize(a)ptfs-europe.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 23321 If enabled, the cash register associated with any transaction needs to be selected for each and every transaction. One can use a 'branch default' to set the most likely register for all transactions at a branch, but it would be an improvement to also allow for selecting a different till for the entirety of a login session. This enhancement aims to add that ability, allowing for a session register to be selected at any point during a session and override the branch default for that session. One should still be able to override the register per transaction if required. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23321 [Bug 23321] Add 'cash registers' to the accounts system -- You are receiving this mail because: You are watching all bug changes.

1 188

[Bug 28996] New: SendQueuedMessages exit on a bad email 'To' and following messages are never processed.
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28996 Bug ID: 28996 Summary: SendQueuedMessages exit on a bad email 'To' and following messages are never processed. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 22343 If there's a bad 'To' field email create die but it isn't caught by SendQueuedMessages. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343 [Bug 22343] Add configuration options for SMTP servers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 23033] New: C4::Items::AddItemBatchFromMarc does not queue bib record for indexing
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '24

05 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23033 Bug ID: 23033 Summary: C4::Items::AddItemBatchFromMarc does not queue bib record for indexing Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul(a)flo.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Callers of C4::Items::AddItemBatchFromMarc must call ModZebra (directly or indirectly) afterwards, which strikes me as wrong. AddItemBatchFromMarc used to call C4::Biblio::ModBiblioMarc, which calls C4::Items::ModZebra[*] but the call to ModBiblioMarc was commented out in commit 3584c442 (2010-09-03 12:16:52 +0200, see bug #5579) and the comment was never removed. The only code in Koha 18.11 that calls AddItemBatchFromMarc is in migration_tools/bulkmarcimport.pl, which dutifully calls MobBiblioMarc once after each call to AddItemBatchFromMarc -- even(!) if AddItemBatchFromMarc fails, which seems weird but I don't fully understand the code. We could add a call to ModZebra in AddItemBatchFromMarc but I assume it would be better to reinstate the call to ModBiblioMarc. I'll attach a patch shortly. [*] C4::Items gets ModZebra from C4::Biblio, which implements and exports it, so my will also change this to a call to C4::Biblio::ModZebra. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24710] New: patron-title.inc should have seperate span classes for firstname, othername, surname
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '24

04 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24710 Bug ID: 24710 Summary: patron-title.inc should have seperate span classes for firstname, othername, surname Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries would prefer to be able to customize how the name is displayed in the patron details. If these included <span> classes we could easily move/hide/reorder bits we don;t want. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31