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

[Bug 34551] New: Don't allow Z39.50 import if MARC can't be converted to MARCXML
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34551 Bug ID: 34551 Summary: Don't allow Z39.50 import if MARC can't be converted to MARCXML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl As I note on bug 34014 and bug 34549, if you've got the wrong encoding on your Z39.50 server, you can wind up importing MARC data that contains invalid data (like control characters). During copy cataloguing, there should be a warning that there's a problem with the data (possibly because of Z39.50 server config). That way we have librarians raising the flag that there's a problem before the data is in Koha rather than us doing cleanup after it's been imported. (Of course, bulk loaded MARC will still be a problem, but baby steps...) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 35104] New: We should warn when attempting to save badly encoded MARC records
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 Bug ID: 35104 Summary: We should warn when attempting to save badly encoded MARC records 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 34549 Bug 34549 adds some defensive coding to prevent incorrectly encoded MARC data getting into the database.. but is does so by silently stripping bad characters from the record. It would be nice to highlight that this is taking place, or preferably before it takes place so the end user understands what's happening. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34549 [Bug 34549] The cataloguing editor allows you to input invalid data -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 338

[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 07 Jul '26

07 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 07 Jul '26

07 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