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

[Bug 25098] New: automatic item modification needs report function
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25098 Bug ID: 25098 Summary: automatic item modification needs report function Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The automatic item modification cronjob does not have an option for reporting the items that were modified. Can the cronjob log in action_logs, or as a report that's emailed, or into a logfile that can be downloaded? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 21670] New: t/db_dependent/Plugins.t is failing randomly on Jenkins (U18)
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21670 Bug ID: 21670 Summary: t/db_dependent/Plugins.t is failing randomly on Jenkins (U18) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org On run #72, Koha_Master_U18 failed: koha_1 | Could not unlink /tmp/xRRc7ht/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm.pm: No such file or directory at /kohadevbox/koha/Koha/Plugins/Handler.pm line 105. koha_1 | koha_1 | # Failed test 'Koha::Plugins::Handler::delete works correctly.' koha_1 | # at t/db_dependent/Plugins.t line 127. koha_1 | # Looks like you failed 1 test of 39. koha_1 | [15:24:05] t/db_dependent/Plugins.t ................................................ koha_1 | Dubious, test returned 1 (wstat 256, 0x100) koha_1 | Failed 1/39 subtests We requested another run and it passes (#73), same node (Docker_3) -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 27363] New: Restore temporary selection of Z39.50 targets throughout multiple searches
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27363 Bug ID: 27363 Summary: Restore temporary selection of Z39.50 targets throughout multiple searches Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Prior to 20.05.06, when using Z39.50 in the Advanced Cataloging Editor, servers that were selected each time a new Z39.50 search was done would be retained throughout multiple searches. This is no longer the case. It would be helpful if that behavior was restored. We have preselected servers which persist for all searches. As we catalog we add some additional servers that would be retained for a short period of time until we decided we no longer needed them. For instance, we may be cataloging Spanish and we could check a server that could be used for several bibs but it wasn't a server that we wanted to be a preselected server. Now that a newly checked server is not retained in the short term we have to check it again for every search which is much less efficient. We could go into Admin and make it a preselected search for the short duration we plan to use it and then go back into Admin to uncheck it when done but that is also not efficient. It would be so much more efficient to be able to check a new server, have it retained, and then uncheck it when done. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 25387] New: Avoid merge different type of authorities
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25387 Bug ID: 25387 Summary: Avoid merge different type of authorities Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When a librarian tries to merge two differents authorities for exampletopic_authority with geogrpahic_authority (Turkey) it deletes one of the authority and all the tags associated for example merging Turkey(topic) with Turkey(geographic) the result is all 650$aTurkey dissapear We should add a lock to avoid merge two different authorities... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 47

[Bug 29539] New: UNIMARCslimUtils.xsl
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29539 Bug ID: 29539 Summary: UNIMARCslimUtils.xsl Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: rafael.antonio(a)sapo.pt QA Contact: testopia(a)bugs.koha-community.org When it hapens UNIMARC record to have $9 after $a on biblio_metadata record like <datafield tag="606" ind1=" " ind2=" "> <subfield code="a">Portugal</subfield> <subfield code="9">12005</subfield> </datafield> OPAC details display the authority number and not the term. If we change record for <datafield tag="606" ind1=" " ind2=" "> <subfield code="9">12005</subfield> <subfield code="a">Portugal</subfield> </datafield> it display the term. Is it a bug? The only piece of XSLT code I see for such reason is at UNIMARCslimUtils.xsl file <xsl:choose> <xsl:when test="marc:subfield[@code=9]"> Any comment? -- You are receiving this mail because: You are watching all bug changes.

1 57

[Bug 30230] New: Search for patrons in checkout should not require edit_borrowers permission
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30230 Bug ID: 30230 Summary: Search for patrons in checkout should not require edit_borrowers permission Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Bug 15812 made searching for patrons for checkout use the regular patron search. This resulted in a significant change in behavior for users who have _circulate_ permissions but not _edit_borrowers_. Previously, a user with these permissions could enter a partial name, be taken to a list of search results, and select the patron they desire. Following bug 15812, a user with these permissions will hit a "You do not have permissions" block when attempting to search for a partial patron name. One can allow the search by adding _edit_borrowers_ permission, but that also grants the ability to create and edit patrons. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 119

[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 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 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 26467] New: Allow multiple display locations to be added in news tool
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26467 Bug ID: 26467 Summary: Allow multiple display locations to be added in news tool 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When configuring a news items for display you can leave the display location blank, which adds your news item in all possible display locations OR you can select a single display location. It would be neat if you could select multiple display locations for a news item. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5