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

[Bug 35066] New: In the Holds Queue, add ability to decline to fill a hold and automatically push to the next branch
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35066 Bug ID: 35066 Summary: In the Holds Queue, add ability to decline to fill a hold and automatically push to the next branch Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: catrina(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com For libraries using the holds queue, they should have the ability to deny filling the hold so it would push the item onto the next branch's holds queue without having to wait for the cron to run. Right now, the only way to move an item off a library's queue is to mark it as missing/lost or damaged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 21391] New: Add per user interface settings
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21391 Bug ID: 21391 Summary: Add per user interface settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are some setting in system preference, which are related to user interface and could be useful to have an ability to set it for each user separately and use global preference as fallback only. For example: StaffLangSelectorMode AudioAlerts intranetbookbag IntranetCatalogSearchPulldown viewISBD viewLabeledMARC viewMARC hide_marc IntranetBiblioDefaultView advancedMARCeditor CircSidebar ExportCircHistory previousIssuesDefaultSortOrder todaysIssuesDefaultSortOrder EnableSearchHistory numSearchResults defaultSortField defaultSortOrder displayFacetCount expandedSearchOption NumSavedReports And in the future the cash register from Bug 11373 There could be admin page where the system administrator could enable/disable the settings for users and then in users menu could be new item - interface settings where users could change their preferences. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 31383] New: Additional contents: We need a parent and child table
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31383 Bug ID: 31383 Summary: Additional contents: We need a parent and child table 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org In the design of additional contents the idea of a parent-child relation is implicitly present. You have a default page and translations. But we do this in one table coming from the old news items. Several reports show (imo) that we would be better off creating a parent table listing the main news items, CMS pages or HTML content. And a child table containing all language related stuff. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 173

[Bug 34952] New: Ability to limit visibility of CMS pages by logged in patron category
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34952 Bug ID: 34952 Summary: Ability to limit visibility of CMS pages by logged in patron category 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org It would be awesome if we could choose which patron categories could view/access CMS pages -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 37624] New: Link system preference to entry in the manual
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37624 Bug ID: 37624 Summary: Link system preference to entry in the manual Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Each system preference in the manually can directly be linked to. So wouldn't it be nice if we could link to the entry directly from each system preference in the administration module? Maybe with a small icon or similar, separate from the help link on top of the page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 35452] New: Provide more info when using Link authorities automatically
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35452 Bug ID: 35452 Summary: Provide more info when using Link authorities automatically 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: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl There are records with many entries that can be linked to authorities, be it secondary authors (7xx) or subjects (6xx) As it is, when you use "Automatic authority link" the results list only indicate the field number, so you see something like this. * 650 - More than one local match found. Possibly a duplicate authority! * 650 - More than one local match found. Possibly a duplicate authority! * 650 - More than one local match found. Possibly a duplicate authority! * 700 - No matching authority found. * 700 - No matching authority found. * 700 - No matching authority found. To figure out which are the entries the results refer to you have to manually check the fields in the record. I think this could improved by adding info about the entries. Something like this. * 650 - Rock music. - More than one local match found. Possibly a duplicate authority! * 650 - Alternative rock music. - More than one local match found. Possibly a duplicate authority! * 650 - Country music. - More than one local match found. Possibly a duplicate authority! * 700 - Ikeda, Elaiza - No matching authority found. * 700 - Okada, Nana - No matching authority found. * 700 - Tsuchiya, Anna - No matching authority found. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 36988] New: PUT for patrons requires full borrowers permission, but should only require 'edit_borrowers'
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36988 Bug ID: 36988 Summary: PUT for patrons requires full borrowers permission, but should only require 'edit_borrowers' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com CC: tomascohen(a)gmail.com On the staff side, a user with only edit_borrowers can make changes to a patron account - for PUT access we require borrowers=>1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 33991] New: Inventory tool should be run in the background for performance reasons
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33991 Bug ID: 33991 Summary: Inventory tool should be run in the background for performance reasons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The inventory tool takes a long time to run even for small batches of barcodes. This can lead to timeouts and other undesirable user behaviour. It would make sense to perform this computationally heavy workload via the background jobs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 29016] New: viewlog.pl - Problem with many entries
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29016 Bug ID: 29016 Summary: viewlog.pl - Problem with many entries Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: vitorfernandes87(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The script viewlog.pl it's very slow because it retrieves all action logs at the same time. It should use KohaTables with pagination/number max of returning entries like other Koha tables (API + AJAX wrapper). Test plan: - We need a database with a large number of entries in the action_logs table (200k for example) - Open view logs tool (viewlog.pl) - Select all modules and search - Timeout or a long waiting time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 93

[Bug 23172] New: Issuingrules not checked when returning item and allocating to bib-level holds
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23172 Bug ID: 23172 Summary: Issuingrules not checked when returning item and allocating to bib-level holds 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Currently, when an item is returned the values in the issuingrules are not checked when determining whether to allocate that item to a bib-level hold, based on the item's itemtype and the requesting patrons patron category. This means hold rules defined in the issuingrules table are not being respected when allocating an item to a bib-level hold. For example, A biblio 'Fish' has items with two different item types 'BK' and 'CR'. In the circulation rules the patron category 'B' (Board) with the item type 'BK' has a reservesallowed value of 0 and a holds_per_record value of 0. Patron A (who has a patron category of 'B') can place a bib-level hold on 'Fish' biblio as there is an item with itemtype of 'CR' which they are permitted to reserve. If the 'BK' item is returned first then that will be allocated to fill patron A's bib-level hold, even though in the issuingrules 'B' patrons cannot place a hold on 'BK' items. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 60