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

[Bug 35441] New: Typo 'UniqueItemsFields' system preference
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35441 Bug ID: 35441 Summary: Typo 'UniqueItemsFields' system preference 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Typo in message : NOTE: Fields listed in the 'UniqueItemsFields' system preference will not be copied The preference is Item without 's' : 'UniqueItemFields' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 36129] New: Check in "Hide all columns" doesn't persist on item patch modification/deletion
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36129 Bug ID: 36129 Summary: Check in "Hide all columns" doesn't persist on item patch modification/deletion Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com On item patch modification/deletion tool, if one checks "Hide all columns" checkbox and then reloads the page, checkbox is no longer selected. Columns are hidden as they should. To reproduce: 1. Find items to modify/delete and modify/delete them with corresponding tool. 2. Check checkbox "Hide all columns". 3. Refresh the page. => Note that columns are still hidden, but checkbox is now unselected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 26176] New: AutoLocation is badly named
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26176 Bug ID: 26176 Summary: AutoLocation is badly named 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org As far as I can tell AutoLocation isn't about koha picking a library branch automatically from your login IP address as much as it's a security feature to prevent you from logging into another branch from outside an IP range. As such, I feel the preference is either misnamed, or the description is incorrect.. either way it needs some clarification adding. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 61

[Bug 35961] New: Modal include missing for catalog concerns
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35961 Bug ID: 35961 Summary: Modal include missing for catalog concerns Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 31028 Jonathan Druart 2024-01-29 10:23:15 GMT The modal only opens on opac-detail, however "Report a concern" is displayed on other pages (opac-isbd, opac-marc, etc.) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31028 [Bug 31028] Add 'Report a concern' feature for patrons to report concerns about catalog records -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 16567] New: RSS feeds show issues in W3C validator and can't be read by some aggregators (Chimpfeedr, feedbucket)
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16567 Bug ID: 16567 Summary: RSS feeds show issues in W3C validator and can't be read by some aggregators (Chimpfeedr, feedbucket) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We are seeing issues with some RSS aggregators refusing to load koha rss links, there are errors when checked in the W3C validator: https://validator.w3.org/feed/check.cgi -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 32695] New: Search string for 775 'Other editions' is incorrectly formed
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32695 Bug ID: 32695 Summary: Search string for 775 'Other editions' is incorrectly formed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We format the search as a title phrase 77$a + 77$t like so: http://localhost:8081/cgi-bin/koha/catalogue/search.pl?q=ti,phr:AAAAAAAAAAA… Looking at the documentation, field A is 'Main entry heading' and usually the author: https://www.oclc.org/bibformats/en/7xx/775.html https://www.oclc.org/bibformats/en/7xx/76x-78x.html#subfielda So we likely need to form a title and author search instead -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 30318] New: Cannot override default patron messaging preferences when creating a patron in staff client
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30318 Bug ID: 30318 Summary: Cannot override default patron messaging preferences when creating a patron in staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The issue appears to be in C4/Form/MessagingPreferences.pm 73 sub handle_form_action { ... 104 if (! $prefs_set && $insert){ 105 # this is new borrower, and we have no preferences set, use the defaults 106 $target_params->{categorycode} = $categorycode; 107 C4::Members::Messaging::SetMessagingPreferencesFromDefaults( $target_params ); 108 } ... To recreate: 1 - Enable EnhancedMessagingPreferences system preference 2 - Set some defaults for a category 3 - Create a new patron in this category 4 - Uncheck all messages before saving 5 - Note patron is created with the defaults set -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 33099] New: Add missing MARC21 Match authority mappings so "Search all headings" search works
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33099 Bug ID: 33099 Summary: Add missing MARC21 Match authority mappings so "Search all headings" search works Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org CC: nick(a)bywatersolutions.com The authorities search option to "Search all headings" is actually the most useful choice, but with ElasticSearch it only really works for personal names and meeting names, because while https://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=admin/searchengi… maps 4xx and 5xx see and see-also headings for all types of authorities for the Match index, it only maps 100 and 111, missing 110, 130, 148, 150, 151 and 155 for main headings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 35927] New: Selecting MARC framework again doesn't work when adding to basket from an external source
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35927 Bug ID: 35927 Summary: Selecting MARC framework again doesn't work when adding to basket from an external source Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Like Bug 19372, selecting MARC framework currently doesn't work when adding to basket from an external source. Strangly I can reproduce on koha-testing-docker, but we have this issue with a Ubuntu Focal install. Looks like it comes from a bad syntaxe than needs to be replaced in any case. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 32565] New: Holds placed when all libraries are closed do not get added to holds queue if HoldsQueueSkipClosed and RealTimeHoldsQueue are enabled
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32565 Bug ID: 32565 Summary: Holds placed when all libraries are closed do not get added to holds queue if HoldsQueueSkipClosed and RealTimeHoldsQueue are enabled Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If HoldsQueueSkipClosed is enabled and a hold is placed on a day when all libraries are closed (e.g. a holiday), that hold doesn't get added to any holds queue, because there are no valid queues to add it to at the time. This did not matter with the build-holds-queue cronjob, because the job would just add it to the queue later; however, if RealTimeHoldsQueue is also enabled, that hold will not get added to the holds queue when the libraries reopen unless something triggers a holds queue update on that biblio record, potentially leading to holds stuck in limbo. The exception is a hold that has copies available at the pickup location - those types of holds will still get added to the holds queue even if all libraries are closed. To recreate: 1. Enable RealTimeHoldsQueue and set HoldsQueueSkipClosed to satisfy holds from libraries only when they are open 2. Add a holiday to the calendar for all libraries for today 3. Place a biblio-level hold on a biblio record and set the pickup location to a library that has available copies 4. Verify that that hold got added to the holds queue 5. Place a bilbio-level hold on a biblio record where there are no other holds and copies are available at another location, but not the pickup location 6. Verify that that hold was not added to any holds queue 7. Remove the holiday (or wait for the next day) and verify that the hold from step 5 is still not on the holds queue This could be solved by adding a check to the real-time holds queue to check whether all libraries are closed, and ignore HoldsQueueSkipClosed when that is the case. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 62