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

[Bug 29746] New: Add a handy Koha::Boolean class
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '25

25 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29746 Bug ID: 29746 Summary: Add a handy Koha::Boolean class Change sponsored?: --- Product: Koha Version: unspecified 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The idea is to provide an OO class that can carry a boolean value, and also useful messages for feedback. An example usage: sub safe_to_delete { my ( $self ) = @_; my $result = Koha::Boolean->new; my $can = 1; if ( condition_1 ) { $can = 0; $result->add_message({ message => 'has_debt' }); } ... if ( condition_n ) { $can = 0; $result->add_message({ message => 'has_guarantees' }); } return $result->set_value($can); } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 29712] New: [DOCS] [Omnibus] Content development guide
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '25

25 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29712 Bug ID: 29712 Summary: [DOCS] [Omnibus] Content development guide Change sponsored?: --- Product: Koha Version: master Hardware: All URL: https://wiki.koha-community.org/wiki/Documentation_-_C ontent_Development_Guide OS: All Status: ASSIGNED Severity: enhancement Priority: P3 Component: Documentation Assignee: david(a)davidnind.com Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org Omnibus bug for the creation of a content development guide for the documentation team. It will include: * a style guide: guidelines for writing clear and concise content, including grammar and word lists * an information model: structures and guidelines to help us write different types of content consistently * a content strategy: a plan outlining how we develop content, including the types of information products we create, the tools we use, and the processes we follow -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 29577] New: Link bibs to authorities fails if relator terms are in records to be linked
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29577 Bug ID: 29577 Summary: Link bibs to authorities fails if relator terms are in records to be linked Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If you use a relator ($e) in the authority and biblio records and run link_bibs_to_authorities.pl, it does not link the records although they are a match Observed at 20.11.09 Workflow: 1. Add PERSONAL authority record with 100a Berridge, Elizabeth and 100e actor 2. Add new biblio record with 700a Berridge, Elizabeth and 700e actor NB/ 700 Field should not be under authority control whilst this data is entered to simulate data that is not linked. Temporarily amend this in cataloguing template for 700 field 3. Run link biblio script on the new test bib's biblionumber: sudo koha-shell -c "/usr/share/koha/bin/link_bibs_to_authorities.pl --bib-limit='biblionumber=<yourbibnumber>' --verbose" <site> 4. Observe log which will say Number of bibs checked: 1 Number of headings linked: 0 Number of headings unlinked: 1 5. Remove 100e actor (from authority) and 700e actor (from biblio) and save 6. Rerun linker script (step 3) Number of bibs checked: 1 Number of headings linked: 1 Number of headings unlinked: 0 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[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