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

[Bug 20508] New: Validation for *MandatoryField and *UnwantedField sysprefs
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20508 Bug ID: 20508 Summary: Validation for *MandatoryField and *UnwantedField sysprefs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When any the system preferences BorrowerMandatoryField BorrowerUnwantedField PatronSelfModificationBorrowerUnwantedField PatronSelfRegistrationBorrowerMandatoryField PatronSelfRegistrationBorrowerUnwantedField are being populated, we should check that a) The entered fields are columns in the borrowers table b) Mandatory / Unwanted fields that refer to the same form (BorrowerMandatoryField/BorrowerUnwantedField and PatronSelfRegistrationBorrowerMandatoryField/PatronSelfRegistrationBorrowerUnwantedField) do not contain the same fields. c) If autoMemberNum is set, don't allow cardnumber in *MandatoryField See also: * Bug 17433 * Bug 19642 * Bug 19225 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22848] New: Ability to merge suggestions
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22848 Bug ID: 22848 Summary: Ability to merge suggestions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- It can easily happen that multiple suggestions for the same record are made. It would be nice if there was an option to merge them and keep both patrons who made the suggestion linked to it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 20271] New: Merge deleted/old tables with their "alive" cousins
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271 Bug ID: 20271 Summary: Merge deleted/old tables with their "alive" cousins Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P1 - high Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: boutrosboutrosboutros(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In Koha's DB, instead of having a "soft" deletion of entries by flagging the deleted one as so, the rows in the db is actually deleted, but only after a new row in a different table is inserted. Koha's DB is relational, so there is a cascade of links between each object: a biblio is referred by many items, and each item is referred by issues, holds, messages. E.g.: when a row in the item table is moved from "items" to "deleted_items", then all the references from holds, transfers and so on will be broken. The suggested more orthodox approach to this would be to add a "deleted_at" column, which is normally null unless the row is deleted, then it set to the timestamp of when it was deletion. This means that the row is still there and will still be referred by other tables, but it just won't be shown in the relevant lists. This would improve the maintenance of Koha in many ways (e.g.: the auto_increment id on those tables caused lots of issues when you add an item and delete it immediately after. the next new item will have the same itemnumber as the previously deleted one, clashing with it in many ways). This bug is about merging the all these tables: deletedborrowers => borrowers deletedbiblio => biblio deletedbiblioitems => biblioitems deletedbiblio_metadata => biblio_metadata deleteditems => items old_issues => issues old_reserves => reserves -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 383

[Bug 20269] New: Allow selecting default collate rule
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20269 Bug ID: 20269 Summary: Allow selecting default collate rule Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org For some languages, the default collate rule set in kohastructure.sql, utf8_unicode_ci, doesn't work correctly. For example, Finnish alphabet expects the alphabet to sort abc...xyzåäö, but the unicode_ci rule doesn't handle the åäö right. Instead, we need to use the swedish_ci rule. It would be nice to be able to define the default collate rule during install. Problem can be seen for example when you go catalogue a new record and have frameworks starting with 'ä' or 'ö', those will sort incorrectly. On the database, you can test this with: insert into biblio_framework (frameworkcode, frameworktext) values ('TEST', 'Äänikirja'); -- Note where the 'Äänikirja' is located select * from biblio_framework order by frameworktext collate utf8_unicode_ci; -- And then the correct order, with 'Äänikirja' last: select * from biblio_framework order by frameworktext collate utf8_swedish_ci; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 22330] New: Transfer limits should be respected for placing holds in staff interface and APIs
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '25

27 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22330 Bug ID: 22330 Summary: Transfer limits should be respected for placing holds in staff interface and APIs Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Branch transfer limits are respected for placing holds in the OPAC but nowhere else. This should be remedied. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 42

[Bug 21551] New: Automatically update guarantee when updating guarantor
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '25

25 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21551 Bug ID: 21551 Summary: Automatically update guarantee when updating guarantor Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 It would be great if an update to a guarantor's contact information also updated all guarantees. It appears there used to be code for this, but it didn't work and was removed. See bug 15653. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15653 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 23046] New: Add tax handling to accounts
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '25

25 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23046 Bug ID: 23046 Summary: Add tax handling to accounts Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- We should have the ability to assign tax rates to the various charges a patron can incur. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 23669] New: Verify if checkouts or reserves requests from ILS-DI periods overlap with existing reserves
by bugzilla-daemon＠bugs.koha-community.org 24 Nov '25

24 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23669 Bug ID: 23669 Summary: Verify if checkouts or reserves requests from ILS-DI periods overlap with existing reserves Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: julian.maurice(a)biblibre.com Depends on: 15261, 23531 Same as BZ15261 but for WebServices Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15261 [Bug 15261] Verify if checkouts or reserves requests periods overlap with existing reserves https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23531 [Bug 23531] ILS-DI doesn't implement needed_before_date and pickup_expiry_date parameters. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 16791] New: Explanation of callnumber.pl plugin
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '25

22 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16791 Bug ID: 16791 Summary: Explanation of callnumber.pl plugin Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: nengard(a)gmail.com Reporter: eb(a)efdss.org QA Contact: testopia(a)bugs.koha-community.org Perhaps a brief explanation of what callnumber.pl is meant to do would be a useful addition to the manual. I am not certain what its function is, though I discovered that it doesn’t do what I was hoping it would. See bug 13615 for a long winded query. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 21250] New: Auto-self-checkout not fully compatible with two-branch library setup
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '25

22 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21250 Bug ID: 21250 Summary: Auto-self-checkout not fully compatible with two-branch library setup Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: oliver.behnke(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org We use a two-branch library setup, both with auto-self-checkout enabled, so patrons log in with their cardnumber via the pre-defined staff user account (see below). The problem is that since the internal self-checkout user also has to be assigned to exactly one branch, that branch will be used as "current location" when a patron checks out a book. So, it's the self-service account's branch that's used instead of the patron's/borrower's branch. >From looking at the code it seems that C4::Circulation->AddIssue() is using "C4::Context->userenv->{branch}" where "$borrower->{'branch'}" should probably be used instead, since the current user's branch isn't relevant (even wrong) in the auto-self-checkout context. FYI, we use the following config (if relevant at all): - Koha 18.05.01-2 - AutoSelfCheckAllowed: Allow (AutoSelfCheckID/AutoSelfCheckPass) - CircControl: the library the item is from - HomeOrHoldingBranch: the library the item is from Thank you. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26