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

[Bug 25667] New: Add field for items.notforloan_on to record when a notforloan status is applied
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '26

15 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25667 Bug ID: 25667 Summary: Add field for items.notforloan_on to record when a notforloan status is applied Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We record lost_on and damaged_on. Can we record notforloan_on, too? It'd be helpful for various reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 28915] New: MARC Modification Templates should allow specification of a position or range within a control field
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28915 Bug ID: 28915 Summary: MARC Modification Templates should allow specification of a position or range within a control field 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When dealing with the MARC Leader, 008, and other fixed length control fields, it would be nice to be able to make the modification templates look at, match on, and alter only a specific position or range. For example, suppose I have several records in which I want to change the 008 position 33 (Literary form) from a 0 to a 1 (nonfiction to fiction). Currently I could tell my modification template to update the 008 of every record I point it at where the character in position 33 is a 0 (using regex to match only that specific character). But then there's no way to change ONLY that character and preserve the rest of the field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 144

[Bug 23988] New: When replace record with z39.50, give option on what gets pre-populated
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23988 Bug ID: 23988 Summary: When replace record with z39.50, give option on what gets pre-populated 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently in Koha, when a user chooses to replace an existing record with another record using z39.50, Koha will prepopulate the z39.50 search with Title, Author and ISBN. This search is very constrictive and it would be nice to have the option of what fields get prepopulated instead of having to manually remove the fields that the user doesn't want. Specifically, an ISBN pre-population would be ideal for a library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 18139] New: 'Too many checked out' can confuse librarians
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18139 Bug ID: 18139 Summary: 'Too many checked out' can confuse librarians Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com The too many checked out message can be very confusing for librarians when the limit specified is more or less than the number of checkouts the patron already has. We should make it clear to the librarian that this is only counting certain types of checkouts by giving them the issuing rule criteria used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 54

[Bug 28639] New: Embed see-from headings (from authorities) into bibliographic records at OAI repository level
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28639 Bug ID: 28639 Summary: Embed see-from headings (from authorities) into bibliographic records at OAI repository level Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: julien.sicot(a)univ-rennes2.fr QA Contact: testopia(a)bugs.koha-community.org Hi, It could be interesting to enrich the bibliographic records exposed in OAI with see-from headings, this would allow users who use koha with a discovery tool to be able to manage, normalize and index some authorities data ? This is something that could be done directly in C4::Biblio::GetMarcBiblio following the same method used for embedding items. We could use an optional parameter like embed_items (embed_seefromheading) and a function similar to C4::Biblio::EmbedItemsInMarcBiblio by reusing what was made for zebra with EmbedSeeFromHeadings (bug #7417). Thanks for feedback, Best Julien Sicot Systems Librarian, Université Rennes 2 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43

[Bug 29281] New: Allow per-user configuration of table settings and default sort orders
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29281 Bug ID: 29281 Summary: Allow per-user configuration of table settings and default sort orders 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Different users will have different needs for what's shown in any given table in the staff interface. Table settings only allow things to be shown/hidden systemwide. It'd be great to have a way for individual users to pick their own defaults. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 27507] New: Search host record using control number identifier / organization code
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27507 Bug ID: 27507 Summary: Search host record using control number identifier / organization code 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 11175 In /cgi-bin/koha/catalogue/detail.pl currently if you are viewing a record with 773w field the page shows "In: XXXX" with a search link to the host record. Currently when the 773w field format is in the LOC format of (OrgCode)ControlNumber we only search using the ControlNumber part. When importing records to Koha from different databases it is necessary to search also using the organization's code that is in the parentheses – otherwise we get in the results also unrelated records from other organizations. We need the 003 / Control-number-identifier search addition from bug 11175 to implement this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 [Bug 11175] Show the parent record's component parts in the detailed views -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 21820] New: Zebraqueue should not be added to
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21820 Bug ID: 21820 Summary: Zebraqueue should not be added to Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com In bug 20244 we identified that the zebraqueue is still being appended to when the searchengine preference is set to ElasticSearch.. unfortunately zebra may still be in use in parallel to Elastic to provide a public SRU/z3950 gateway.. as such we can't bind on just the syspref to know whether we should stop adding to the zebraqueue or not. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[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 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