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

[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 25 Aug '26

25 Aug '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 5

[Bug 22439] New: Duplicated code in PrepHostMarcField and prepare_host_field
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22439 Bug ID: 22439 Summary: Duplicated code in PrepHostMarcField and prepare_host_field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- The C4/Biblio.pm subroutines PrepHostMarcField and prepare_host_field both do the same thing, so should be merged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 62

[Bug 19814] New: Batch Check-in function
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Bug ID: 19814 Summary: Batch Check-in function Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: smichaelxx(a)tlen.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, in Koha exists function named "Batch Check out" but there is no "Batch Check in". A lot of small libraries don't have self-check station. Maybe a good solution would be adding function "Batch Check in"? Thanks a lot Regards -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 188

[Bug 20747] New: Allow LocalHoldsPriority to fill by hierarchical groups system rather than individual library
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20747 Bug ID: 20747 Summary: Allow LocalHoldsPriority to fill by hierarchical groups system rather than individual library 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: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be great if the LocalHoldsPriority could be used within a district in a consortium. >>Christopher expressed concern, adding on “grouping” – some libraries may not >>want to be effected. Typically this is all or nothing or on or off. Example, >>the circulation of Mobile Hotspots; hotspots are popular outside of CDA but CDA >>patrons get priority, Rathdrum is pushed down. Consider an “Item type” or “Item >>level” opt out which would be similar to how suppression works. If the >>modification increased features and flexibility, there may be more interest from >>the larger group in supporting the enhancement. Group structure for settings, a >>hierarchy based system, and refinement is needed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 87

[Bug 16631] New: Show groups/categories of reports to authorized staff
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16631 Bug ID: 16631 Summary: Show groups/categories of reports to authorized staff Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful to have reports that are specific groups/categories to be authorized under the reports permissions in a patron account. Not everyone wants to see everyone else's reports, some are similar but are not. Some are for superlibrarians to test, and are not ready for use. It would be great if we could specify groups and even subgroups in the permissions that the staff could access, or specify all groups. All groups should be the norm for a superlibrarian. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 283

[Bug 34164] New: OAuth2/OIDC should redirect to page that initiated login
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34164 Bug ID: 34164 Summary: OAuth2/OIDC should redirect to page that initiated login Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org At the moment, a successful OAuth2/OIDC login is sent to opac-user.pl/opac-main.pl or mainpage.pl instead of the page that initiated the login process. With Shibboleth, we manage this using the "target" URL, so that the Shibboleth login is processed by whatever page initiated it, but that doesn't work with OAuth2/OIDC and the "redirect_uri" since we're using an API endpoint. However, all we need to do is save the current path in the user's session, and then recall it after the successful login. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 33259] New: Optionally set SameSite attribute of cookie to Strict
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33259 Bug ID: 33259 Summary: Optionally set SameSite attribute of cookie to Strict Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSi… We should offer a system preference so that libraries who'd like to increase their security can set the SameSite attribute of the session cookie to Strict, rather than the default Lax. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 92

[Bug 29948] New: Display author information for researches
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29948 Bug ID: 29948 Summary: Display author information for researches Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29897 Display author's information from 371, 372, 373 (email, activity, etc.) in the same area than identifiers (from bug 29897). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29897 [Bug 29897] Display author identifiers for researchers -- You are receiving this mail because: You are watching all bug changes.

1 68

[Bug 30557] New: Add ability to create Item lists
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30557 Bug ID: 30557 Summary: Add ability to create Item lists Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is relevant for multi-branch installations. Lists currently appear to be primarily bibliographic lists. This creates a problem when sorting lists by call number. In this scenario there may be multiple items from different libraries using different call number schema attached to a single bibliographic record. The list cannot be sorted accurately by call number. It would be helpful if there was an option for an item based list. In this scenario items are added to a list for a specific branch. The call number sort will then sort correctly because the call number schema will be consistent for the branch. An item list would display the same information as a bibliographic list with the exception of additional branches which may also have the item. A typical use case would a library creating an item list, sort by call number, and then use that list to go to the shelf to pull the items in order. This is currently not possible in a multi-branch installation without a bit of work. It would require downloading the list and then cleaning up the list to be useful for this kind of work. It may be possible to create a report that will do this, but it would be a nice added functionality in the List tool. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 21272] New: Marc import should warn about mis-matched branch and item-type fields in 952 during marc import.
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21272 Bug ID: 21272 Summary: Marc import should warn about mis-matched branch and item-type fields in 952 during marc import. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When importing a record that has homebranch (952$a), holding branch (952$b) or item type (952$y) populated, but not matching values in branches.branchcode or itemtypes.itemtype, koha will indicate that items were not imported (via the count of imported items), but not why. This causes frequent confusion among new users. It would be nice to offer mappings between detected branches / item types and the branches and item types already in the system. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101