January 2026 - Koha-bugs - lists.koha-community.org

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 21 Jan '26

21 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #181065|0 |1 is obsolete| | --- Comment #180 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- Created attachment 191723 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191723&action=e… Bug 7376: Unit test Signed-off-by: Julian Maurice <julian.maurice(a)biblibre.com> Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski(a)biblibre.com> Signed-off-by: Mathieu Saby <mathsabypro(a)gmail.com> Rebased-by: Victor Grousset/tuxayo <victor(a)tuxayo.net> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 21 Jan '26

21 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #181064|0 |1 is obsolete| | --- Comment #179 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- Created attachment 191722 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191722&action=e… Bug 7376: Transfer limits should be checked at check-in Test case: * UseBranchTransferLimits must be set * define your branch transfer limit. Refuse transfers from libraryA to libraryB * checkout a book owned by libraryB, from libraryB, with a librarian located at libraryB * move the librarian to libraryA ("Set Library" link top/right) * check-in the book => it's possible whatever your setup After the patch, the behaviour respect the branch transfer limit parameter: you can check-in if you accept transfers, you can't if you refuse them. (Note: IndependantBranches must be OFF, otherwise it's not possible to do the checkin whatever the branch transfer limits) TEST PLAN: Note: older signoffs did not validate this test plan Considering you use a ktd-like database. Log in at centerville Allow transfers between centerville, Midway and Franklin, don't allow transfers between Fairfield, Liberty and all other libraries. In addition, allow the transfer between Liberty and Midway Transfer as much books as you can from Centerville to Midway. Log in as Midway, check out as many books from Centerville as you can to Henry Acevedo. If you don't have enough books during the test plan, feel free to check out books again. During the whole test, without further precision, items checkout out in such conditions should be checked in. You will also need 6 checked out floating books at midway Note: '-> ok' means the checkin is allowed '-> not ok' means the checkin is not allowed Apply patch I - Test AllowReturnToBranch During this part of the test plan, you want to have all following configuration : 'CircControlReturnsBranch' -> 'The library the item is checked in at' In CIRC rules: 'Default holds policy and return policy' -> 'Item returns home' (make sure you have no other holds policy on any library) 'AllowReturnToBranch' -> as follows 1 - Set to "Either at the library the item is from or at the library the item was checked out from" X a - Check in to Centerville -> ok X b - Check in to Midway -> ok X c - Check in to Franklin -> not ok X d - Check in to Fairfield -> not ok 2 - Set to "Only at the library the item was checked out from" X a - Check in to Centerville -> not ok X b - Check in to Midway -> ok X c - Check in to Franklin -> not ok X d - Check in to Fairfield -> not ok 3 - Set to "Only at the library the item is from" X a - Check in to Centerville -> ok X b - Check in to Midway -> not ok X c - Check in to Franklin -> not ok X d - Check in to Fairfield -> not ok 4 - Set to "Any library" X a - Check in to Centerville -> ok X b - Check in to Midway -> ok X c - Check in to Franklin -> ok X d - Check in to Fairfield -> not ok II - Transfer and check out 6 floating items at midway. 1 - X a - Check in to Centerville -> ok X b - Check in to Midway -> ok X c - Check in to Franklin -> ok X d - Check in to Fairfield -> ok 2 - Set 'AllowReturnToBranch' to 'home library' X a - Check in to Centerville -> ok X b - Check in to Midway -> not ok III - Pathological & asymetrical cases. During this part of the test plan, you want to have all following configuration : 'CircControlReturnsBranch' -> 'The library the item is checked in at' 'Default holds policy and return policy' -> 'Item returns home' (make sure you have no other holds policy on any library) 'AllowReturnToBranch' -> 'Any library' FOR THIS PART OF THE TESTS ONLY (until IV): Don't allow tranfers from midway to centerville, but allow from centerville to midway X 1 - Check in a book at midway -> not ok Set 'Default holds policy and return policy' -> 'Item returns to issuing library' X 2 - Check in a book at centerville -> ok FOR THIS PART OF THE TESTS ONLY (until IV): Don't allow tranfers from centerville to midway X 3 - Check in a book at centerville -> not ok X 4 - Set 'AllowReturnToBranch' to "Only at the library the item was checked out from" X a - check in to Centerville -> not ok X b - check in to Midway -> not ok IV - Test 'CircControlReturnsBranch' (remove the precedent transfer restriction) During this part of the test plan, you want to have all following configuration : 'Default holds policy and return policy' -> 'Item returns home' (unchanged) 'Default checkout, hold and return policy for Midway' -> 'Item returns to issuing library' 'Default checkout, hold and return policy for Franklin' -> 'Item floats' 'Default checkout, hold and return policy for Fairfield' -> 'Item returns to issuing library' 'Default checkout, hold and return policy for Liberty' -> 'Item returns home' 'AllowReturnToBranch' -> "Any library" (unchanged) 'CircControlReturnsBranch' -> as follows 1 - 'The library the item is checked in at' X a - Check in to Centerville -> ok X b - Check in to Midway -> ok X c - Check in to Franklin -> ok X d - Check in to Fairfield -> not ok X e - Check in to Liberty -> not ok 2 - 'The library the current item is held by X a - Check in to Centerville -> ok X b - Check in to Midway -> ok X c - Check in to Franklin -> ok X d - Check in to Fairfield -> not ok X e - Check in to Liberty -> ok 3 - 'the library the item is owned by' X a - Check in to Centerville -> ok X b - Check in to Midway -> ok X c - Check in to Franklin -> ok X d - Check in to Fairfield -> not ok X e - Check in to Liberty -> not ok Sponsored-by: National Library of Finland Signed-off-by: Arthur Suzuki <arthur.suzuki(a)biblibre.com> Signed-off-by: Julian Maurice <julian.maurice(a)biblibre.com> Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski(a)biblibre.com> Signed-off-by: Mathieu Saby <mathsabypro(a)gmail.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35138] New: Elastic search - add new facets
by bugzilla-daemon＠bugs.koha-community.org 21 Jan '26

21 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35138 Bug ID: 35138 Summary: Elastic search - add new facets Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: michaela.sieber(a)kit.edu We would like to create a new facet for a 9xx-MARC field As Nick mentioned in Bug 18235, Comment 7: -labels shouldn't be hardcoded - staff should be able to set them -we should add more options to what can be faceted- could be out of control but technically any field should be able to be used -ES has better handling for faceting (can provide subsets of existing/current results and allow to step in/out of facets) Problems / Challenges: 1. Translatability: if staff changes or add new labels, they will not be translated 2. same files for elastic and Zebra -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 74

[Bug 18235] New: Elastic search - Configurable facets
by bugzilla-daemon＠bugs.koha-community.org 21 Jan '26

21 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18235 Bug ID: 18235 Summary: Elastic search - Configurable facets Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Searching Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 14899, 17169, 18174 >From the Elastic mappings configuration page, the librarians should be able to manage facets (display/hide and order). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14899 [Bug 14899] Mapping configuration page for Elastic search https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17169 [Bug 17169] Add facets for ccode to elasticsearch https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18174 [Bug 18174] Add the Koha::Object->update method -- You are receiving this mail because: You are watching all bug changes.

1 137

[Bug 28245] New: Language dropdown in advanced search should be sorted
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28245 Bug ID: 28245 Summary: Language dropdown in advanced search should be sorted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The Language dropdown in the advanced search should be sorted. It should be sorted according to the locale of the user. For instance, sorting by iso 629-2 codes favours English. Take for example "German". The code is "ger" and in English it's "German" but in French it's "Allemand", and in German it's "Deutsch". The alphabetical sort should be done to align with the expectations of the language of the user/interface. I'm not sure what to do about non-alphabetic languages like Chinese that don't do alphabetic sorting... Also, this is neat https://perldoc.perl.org/Unicode::Collate::Locale. A core module which adds support for locales. That said, sort for French is weird. The first is normal sort() and the second is Unicode::Collate::Locale sort. $VAR1 = [ 'a', 'e', 'ç', 'é', 'ï' ]; $VAR1 = [ 'a', 'ç', 'ï', 'é', 'e' ]; -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 28957] Many plugins require the full plugins permission set to run
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28957 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette(a)bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41349] New: Spelling: Id is an abbreviation
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41349 Bug ID: 41349 Summary: Spelling: Id is an abbreviation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Id koha-tmpl/intranet-tmpl/prog/js/vue/components/Admin/RecordSources/RecordSourcesResource.vue:48 Should be: ID -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 41641] New: Link emails sent from cart or lists to existing patron accounts
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41641 Bug ID: 41641 Summary: Link emails sent from cart or lists to existing patron accounts Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org When sending a list or a cart to a patron via email, it is great that we are not limited to existing patrons, but it would also be nice if the email we are sending to would check if the email is going to a matching patron account so the email could be added to their list of notices in their account. It would also be great if instead of entering an email address, we could search for a patron account and select from any email addresses listed in their account, and then linking to their notices as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 41657] New: Patron messaging preferences - list notices in alphabetical order
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41657 Bug ID: 41657 Summary: Patron messaging preferences - list notices in alphabetical order Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The order of the notices shown for 'Patron messaging preferences' seems somewhat random. I recommend putting them in alphabetical order. To reproduce: 1. In the staff interface, go to Administration > System preferences 2. Set UseRecalls to Use 3. Set ILLModule to Enable 4. Go to Patrons 5. Add a new patron: + New patron > Patron 6. Scroll down to the "Patron messaging preferences" section (at the bottom) 7. Note the order of the notices: - Hold filled - Hold reminder - Return recalled item - Recall awaiting pickup - Interlibrary loan ready - Interlibrary loan unavailable - Interlibrary loan updated - Item checkout - Auto renewal - Advance notice - Item due - Item check-in 8. If you go to Administration > Patrons and circulation > Patron categories, and edit any patron category, the order is the same. 9. If you go to the OPAC, log in as a patron, and go to the 'Messaging' section, note that they are in alphabetical order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 29194] New: Patron messaging preferences should be ordered
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29194 Bug ID: 29194 Summary: Patron messaging preferences should be ordered Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 28153 comment 3 suggests the preferences should be ordered Alphabetical could differ in different languages, and I think that would be confusing I would suggest a 'logical' ordering - Holds options together, ILL options together, and item option in process order: Checkout, Predue, Due, Checkin Currently the table is ordered by 'message_attribute_id' and these is not a simple way to sort as desired -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34