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

[Bug 18407] New: REST API: Include renewability information on checkouts
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18407 Bug ID: 18407 Summary: REST API: Include renewability information on checkouts Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org It would be useful to have renewability information directly in the /checkouts endpoint to avoid making additional requests. However, this could be optional. Create /api/v1/checkouts/expanded endpoint to include additional data on checkouts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 29643] New: [DOC] Review and update koha-manual git repository README and CONTRIBUTING files
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29643 Bug ID: 29643 Summary: [DOC] Review and update koha-manual git repository README and CONTRIBUTING files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Documentation Assignee: david(a)davidnind.com Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org Review and update the koha-manual git repository README and CONTRIBUTING files to include: * A link to Documentation Team wiki pages * A link to CONTRIBUTING.md * Make the information about setup, producing output and useful commands more concise The main goal is to make it more useful and clearer for those that would like to contribute a change to the manual. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 33374] New: Holds captured at different branch when pickup branch has a copy on shelf can create long wait times for patrons
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33374 Bug ID: 33374 Summary: Holds captured at different branch when pickup branch has a copy on shelf can create long wait times for patrons 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: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. Have a multibranch system where holds can transfer between 2 or more libraries 2. Have a bib with 2 or more items at different branches. 3. At Branch A checkout Branch A's copy of the item to a patron 4. At Branch B place a record level hold for a Branch B patron (where branch b has a copy of the item available on the shelf) 5. Return Branch A's book at Branch A. It fills the hold for Branch B patron In some cases this makes the patron wait much longer for a hold. It would be great if there was a way to set holds not to fill from other libraries if there was a copy available at the pickup location. Some consortiums have branches that only get deliveries once or twice a week. If they happen to check in an item that could be filled at the pickup branch before the pickup branch scans the hold there, it could take much longer for the patron to get the item. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 30682] New: Indicate in addbiblio.pl when an edit will not be saved due to Overlay Rules
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30682 Bug ID: 30682 Summary: Indicate in addbiblio.pl when an edit will not be saved due to Overlay Rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 14957 The new MARC overlay rules can prevent edits to certain MARC fields. We don't give any indication when that's happening. To recreate: - set a rule on marc-overlay-rules.pl for module=source, filter=Staff client MARC editor, tag=020, preset=protect - find a record with an 020 - edit the record, delete the 020, save. confirm the interface allows all of this - confirm the 020 is still there, but no indication of why Something here should inform the user of what's going on. Highlighting of the tag within the edit interface? A popup on saving? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 [Bug 14957] Write protecting MARC fields based on source of import -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 26573] New: Limit patron attribute types to more than one patron category
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26573 Bug ID: 26573 Summary: Limit patron attribute types to more than one patron category Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, Koha doesn't allow to limit a patron attribute type to more than one patron category. Let's say I have a patron attribute type STUDENTID, and I want to limit this attribute to the categories "undergrad students" and "grad students". I have to create two different patron attribute types. To replicate: 1) Go to Administration > Patron attribute types 2) Create a new patron attribute 3) Note that the "Category" field is a dropdown and you can't choose more than one patron category to assign this attribute type to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 94

[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 34304] New: Use "days in advance" for hold reminder notice
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34304 Bug ID: 34304 Summary: Use "days in advance" for hold reminder notice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment the "days in advance" for the HOLD_REMINDER notice can only be configured via command line options. It would be much nicer if we could use the setting in the messaging preferences (same as for the pre-due notice). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[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