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

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 --- Comment #151 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- (In reply to Mathieu Saby from comment #147) > Sorry, for me it's not working as it should : > > In standard rule I defined > - a circulation matrix : Patron : All, Item type : All, checkouts : 5, > on-site checkouts : 5 > - a global checkout limits : Patron : All, Item type : All, checkouts : 8, > on-site checkouts : 8 > > > Then I check out items from 1 given library (Centerville) to a patron. Koha > let me check out 8 items before showing an error message. It should be 5 > items... > > You need to add steps in your test plan to make sure Koha is not applying > the "global" limit that way. Hello Mathieu, The feature currently works as you describe, given that it is integrated into the function which will "get effective rule", if it is defined in global checkouts limits and in the circulation rules matrix it will be the one which will be returned to supplant the operation on all branches. If comparisons of quotas have to be made I fear that this will somewhat complicate its use and implementation. But I welcome opinions on this subject. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 --- Comment #150 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- (In reply to Fridolin Somers from comment #148) > Hi, > > There might be an issue in get_effective_rule_value() : > > my $memory_cache = Koha::Cache::Memory::Lite->get_instance; > my $cache_key = sprintf "CircRules:%s:%s:%s:%s", $rule_name // q{}, > $categorycode // q{}, $branchcode // q{}, $itemtype // q{} > ,$has_priority // q{}; > > It generates error > [WARN] Redundant argument in sprintf > > Maybe sprintf is missing a "%s" Hi Fred, Thanks for this feedback, I fixed this and squash commits by the way. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #186028|0 |1 is obsolete| | Attachment #186029|0 |1 is obsolete| | Attachment #186030|0 |1 is obsolete| | --- Comment #149 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Created attachment 188548 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=188548&action=e… Bug 8137: Add 'global checkout limits' table The aim here is to avoid the accumulation of checkouts possibilities through the rules of the various branches, in order to have a global quota. Test plan: 1) Apply this patch 2) Run updatedatabase script and rebuild schema, restart_all.. 3) On circulation rules page you will find a new table "Global checkout limits". 4) If you enter values, they will overwrite the existing values, creating limits for all branches combined. 5) Test it by set a "current checkouts allowed" to 2 on "standard rules section" and set a "global" maxissueqty to 1. Normally 1 is the new limit for now. 6) You can also add a "current checkouts allowed" on other branches and see that you can't accumulate checkouts (you can also delete "global" values and see that if you have 3 on a branch and 2 on other, you can perform 5 checkouts in total. 7) Note that on specific branch circulation rules page the table cannot be modified, but just shown as a reminder. If main matrix is empty on specific branch the table is hidden by default (cause if none values it's referred to standard rules). Sponsored-by: BibLibre Signed-off-by: Lisette Scheer <lisette(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26463] New: AllowHoldPolicyOverride overrides too many holds policies
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26463 Bug ID: 26463 Summary: AllowHoldPolicyOverride overrides too many holds policies Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To test: Enable 'AllowHoldPolicyOverride' system preference Via the the REST API: t/db_dependent/api/v1/holds.t fails Try to place an item level hold: PUT localhost:8080/api/v1/holds Body: { "biblio_id":"1", "item_id":"1", "patron_id":"5", "pickup_library_id":"CPL" } Repeat ad nauseam, patron now has multiple holds on a single item Leave those holds in place. On the staff side: Hit the URL below: http://localhost:8081/cgi-bin/koha/reserve/placerequest.pl?biblionumbers=1/… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 17884] New: troubles with syspref AllowHoldPolicyOverride on return
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17884 Bug ID: 17884 Summary: troubles with syspref AllowHoldPolicyOverride on return Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: christophe.croullebois(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com 1° with syspref AllowHoldPolicyOverride ON 2° in "Holds policy by item type" (in smart-rules.pl) with "no holds allowed" selected for an itype. 3° create an hold on an item of this itype 4° return this item 5° you have no message about the hold and the hold is not in status waiting Due to the lack of the check about the syspref during the check in. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 15567] Update API to allow multiple holds for the same record
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15567 Arthur Suzuki <arthur.suzuki(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.suzuki(a)biblibre.com --- Comment #8 from Arthur Suzuki <arthur.suzuki(a)biblibre.com> --- to be honest I don't really see the point of having a client software pushing a "batch" of holds to Koha. That could as well be handled by the client (portal) software in a for-loop to make a single request for each hold request. IMO that kind of handling should be done on the client software rather than Koha. Also there are already portal software in the wild (like Aspen or VuFind) which are using the holds api, and that patch would break compatibility with them. Best, Arthur -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40837] New: Give more information about UNIMARC configuration
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40837 Bug ID: 40837 Summary: Give more information about UNIMARC configuration Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de I think the manual should include additional information, probably in the installation section. It would be useful for readers to point out that cataloging framework and indexes are based on the UNIMARC defined by IFLA and do not take into account the modifications commonly implemented in different countries using the format (France, Italy, Portugal...), and that adaptations may need to be made by libraries or support companies. Unlike Marc21, there are multiple variants of UNIMARC, and no one uses IFLA UNIMARC as is, so the default config of Koha is not suitable out of the box. For example in France and Italy the use of field 359 is not the same. There is an even greater need for adaptation in countries that do not use UNIMARC directly, but rather national formats based on UNIMARC with variations (Russia, Slovenia, Korea, etc.). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 18024] New: Adding a "genres and kinds" search in Authorities module
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18024 Bug ID: 18024 Summary: Adding a "genres and kinds" search in Authorities module Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Another little enhancement for the Authorities module 1) Go to Authorities module 2) Clic on "New from Z39.50" 3) Observe in the search window that we don't have a place to search by genres (novel, science-fiction, roman, poetry, etc.) It will be very convenient if we can have an additionnal search option by literary "genres and kinds" to help target the good records when searching. Then it will find all records with the same authority (zone 155) from the RVML. Thanks again, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 39992] New: Update UNIMARC frameworks to UNIMARC Bibliographic Format Manual 1.1.0
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '25

29 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39992 Bug ID: 39992 Summary: Update UNIMARC frameworks to UNIMARC Bibliographic Format Manual 1.1.0 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl UNIMARC Bibliographic Format Manual 1.1.0 has been endorsed bu IFLA https://repository.ifla.org/items/cd4be6b4-46a6-43e7-86bf-d14a5cfed916 We should update bibliographic framework in Koha. I will take care of it. After that, Zebra and Elasticsearch will probably need a fix in other bugs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2