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

[Bug 17593] New: Extend circulation rules to include shelving location
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17593 Bug ID: 17593 Summary: Extend circulation rules to include shelving location Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We are in the process of moving over to Koha, and are still trying to manage all the details around this. Circulation rules are a big thing we have to tackle here. At the moment, we have multiple libraries, and within each library we have both open and closed stacks as well as multiple other segmentations, all specified as shelving locations (authorized value LOC). These locations are not always governed by the same set of rules, so it would be very helpful if the system could support LOC as a circulation rule condition alongside library, patron category and item type. >From doing a fairly brief look at the code, it seems GetIssuingRule and GetLoanLength in C4/Circulation.pm are the main points where the ruleset is retreived. There will of course be all the places calling these two functions, as well as database management parts to consider. If we were to develop some sort of extension to these rules, what would be an appropriate approach? It should certainly be an option to turn on to be used, but should we consider LOC as a starting point, or should LOC just be one many possible choices in the configuration? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 20813] New: Revamp user permissions system
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20813 Bug ID: 20813 Summary: Revamp user permissions system 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 Koha's current user permissions system is a bit convoluted and limited due to it's legacy where the permissions system was a simple set of flags. A second layer of sub-permissions were later added complication and obfuscation to the system. We should revamp the permissions system to be a more modern system and open the path to having unlimited nesting of sub-permissions instead of shoe-horning sub-permissions into the limited system we have. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[Bug 28897] New: Allow library limits in cities and towns administration
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28897 Bug ID: 28897 Summary: Allow library limits in cities and towns administration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In a multi branch setting there may be cities/towns that only apply to certain branches. It would be nice if we could add library limits to each city/town, much like we already do in authorized value administration. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 28974] New: Add pagination to holds queue viewer
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28974 Bug ID: 28974 Summary: Add pagination to holds queue viewer Change sponsored?: --- Product: Koha Version: master 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 We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 19642] New: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19642 Bug ID: 19642 Summary: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Bug 19225 proposes a warning for users that the config is wrong. I propose instead, we should just ignore that field if automembernum is enabled (since it autocalculates and becomes mandatory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 29733] New: MARC21: Link 7xx linking fields to marc21_linking_section.pl value builder in sample frameworks
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29733 Bug ID: 29733 Summary: MARC21: Link 7xx linking fields to marc21_linking_section.pl value builder in sample frameworks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org We do link the authority controlled fields to the authority linker by default, so it would make sense to link the fields used for linking between bibliographic records to the available helper plugin as well. At the moment the plugin is not well know, although it provides a great functionality, this could help advertise and improve it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 30303] New: Add ability to select which values to retain when merging patrons
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30303 Bug ID: 30303 Summary: Add ability to select which values to retain when merging patrons 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When merging two patron records, one simply picks one record to retain values from. It would be helpful to have an interface more like what we see when merging biblio records, where one can select values from either pre-merge record to be retained post-merge. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 63

[Bug 24608] New: Allow modification of checkout due date
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24608 Bug ID: 24608 Summary: Allow modification of checkout due date 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: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently it is not possible to modify a checkout's due date. This bug proposes to allow such an action. It is only proposed to allow modification of a due date *forward* at this stage as moving a due date backwards may involve additional complication that will require further thought. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 71

[Bug 21482] New: Create a "landing page" for ILL
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21482 Bug ID: 21482 Summary: Create a "landing page" for ILL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Currently, when you go to the ILL module, the first iew is of all ILL requests. This can be a lot of data, and take several seconds to load, and I doubt a lot of people will want the full list. So maybe we could have some sort of intermediate page with links to selections of request, based on their status, type etc. At it's simplest this could just be a page that displays the contents of a syspref, and that syspref could then be filled with HTML and links to filtered views of ILL requests. If the syspref is empty, the intermediate page could redirect to the full view, as it is today. A more advanced version would have a GUI to configure the links, order them, give them names etc. Thougts? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 27365] New: Koha doesn't check marcxml field size is < 10000 and fails in various places
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27365 Bug ID: 27365 Summary: Koha doesn't check marcxml field size is < 10000 and fails in various places Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hi ISO standard >The core of the framework is a MARCXML schema that allows lossless round-trip >conversion of an ISO 2709 MARC 21 record and an XML-encoded MARC 21 record. Thus a field size is 9999 bytes max. But /usr/share/perl5/MARC/File/USMARC.pm doesn't care: my $direntry = sprintf( "%03s%04d%05d", $field->tag, $len, $dataend ); and if len >= 10000 it silently creates a bogus directory with a length of 13 rather then 12. These non-conformed marxml will fail in various places. Export, search results list with elasticsearch which store ISO 2709 record in index and use them as data source in results list. eg: Easy to trigger in french UNIMARC with 359 (sorry in french) https://www.transition-bibliographique.fr/wp-content/uploads/2019/02/B359-2… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56