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

[Bug 24720] New: Remove special characters from beginning of search fields
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24720 Bug ID: 24720 Summary: Remove special characters from beginning of search fields 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: glasklas(a)gmail.com The ElasticSearch icu_collation_keyword has weird sorting behavior when field values with some special character (", - or [ for example) as they appear on top when sorting a-z. This patch strips initial special characters so behaves more like one would expect (and more like collations usually sort things). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 51

[Bug 23682] New: Add ability to manually import EDI invoices as an alternative to automatic importing on download
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23682 Bug ID: 23682 Summary: Add ability to manually import EDI invoices as an alternative to automatic importing on download Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some library would like to delay the importing of invoices until a time of their choosing. The invoices should be imported into the database as they do now, but the invoice processing should be skipped. Instead, any invoice file with a status of 'new' should have an 'Import' button to process the invoice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 23998] New: Messages REST API
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '26

12 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23998 Bug ID: 23998 Summary: Messages REST API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi Expose messages table via REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 21303] New: XSLT should look in LDR/18 to know whether to add punctuation or not
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '26

10 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21303 Bug ID: 21303 Summary: XSLT should look in LDR/18 to know whether to add punctuation or not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I noticed the XSLT sometimes adds or removes punctuation. If the cataloguers already add the punctuation while cataloguing, this causes double punctuation or no punctuation at all where there should be. For instance, I have a record where there is a period (.) at the end of 100$e. So in MARC, it looks like 100 1# a Goscinny, René, d 1926-1977-, e author. In intranet details, it looks like Goscinny, René, 1926-1977- [author.]. There are two periods (and no comma after the date). In the 260 field, the opposite happens. There is a period at the end of 260$c in MARC, but nothing is appearing in intranet results. 260 ## a Paris : b Gallimard jeunesse, c [2014]. In the intranet details, it looks like Paris : Gallimard jeunesse, [2014] There is no period after the date. MARC21 has a code in LDR/18 to indicate whether or not punctuation has been included in the cataloguing. XSLT should obey this code to determine if it should add punctuation or not. LDR/18 possible codes # - Non-ISBD a - AACR2 c - ISBD punctuation omitted i - ISBD punctuation included n - Non-ISBD punctuation omitted u - Unknown -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 18583] New: Add the ability to merge multiple authorities
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18583 Bug ID: 18583 Summary: Add the ability to merge multiple authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Since bug 8064 it is possible to merge multiple bibliographic records at once, it would be nice to be able to do the same thing with authority records. -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 22439] New: Duplicated code in PrepHostMarcField and prepare_host_field
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22439 Bug ID: 22439 Summary: Duplicated code in PrepHostMarcField and prepare_host_field 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: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- The C4/Biblio.pm subroutines PrepHostMarcField and prepare_host_field both do the same thing, so should be merged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 64

[Bug 24535] New: Add the ability to have longer barcodes than 20 digits
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24535 Bug ID: 24535 Summary: Add the ability to have longer barcodes than 20 digits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: nick(a)bywatersolutions.com Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, in Koha, an item's barcode can only be up to 20 digits, it would be nice to increase this value to possibly a higher number such as 32. Koha recently increased the patron's barcode length to 32 and it was helpful to libraries. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 21453] New: blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21453 Bug ID: 21453 Summary: blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: arouss1980(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If you add or alter an authority record and edit one of the MARC fields in UNIMARC 5XX 'See Also Reference Tracing Block' [1], you can click on the ellipsis (...) next to a subfield [2] to launch the authority finder plugin. This plugin allows you to search for an authority and then pick an entry from the 'Special relationship:' dropdown menu in order to set the relationship between the two authorities. The results list of the authority finder contains 'Choose' buttons which _should_ insert all data from the chosen authority into the appropriate subfields of the MARC tag you are editing [3]. However, in UNIMARC setups this does not work: clicking on 'Choose' only populates subfield $a ('Entry Element') with data, but not subfields $3 and $5 ('Authority Record Number' and 'Tracing Control', respectively), which are just as important for correct authority linking. I've tracked this down to these lines of code which are MARC21-specific and use hardcoded subfield values in blinddetail-biblio-search.pl: 91 for ( $field->subfields ) { 92 next if $_->[0] eq '9'; # $9 will be set with authid value 101 push( @subfield_loop, { marc_subfield => 'w', marc_values => $relationship } ) if ( $relationship ); There is also this code in the template blinddetail-biblio-search.tt: 38 [%- END -%]‡9[% authid | html %]"; 138 if(code.value=='9'){ 139 subfield.value = "[% authid |replace("'", "\'") |replace('"', '\"') |replace('\n', '\\n') |replace('\r', '\\r') %]"; These code fragments don't work 100% because in UNIMARC authorities the authid value is stored in subfield $3 and the relationship code in $5. I propose to modify the Perl script above (which is currently MARC flavour agnostic), have it check the 'marcflavour' system preference, and use that to decide which subfield to push the authority relator code to. A similar approach in the template file will set the authid subfield value depending on whether you are a MARC21 or UNIMARC user. [1] Known as the 'Related Access Point Block' in recent IFLA updates. [2] For the ellipsis to appear next to a subfield, you must view the MARC structure of the relevant authority type and then edit the subfields of the tag you're interested in. Finally, you must select an authority type from the 'Thesaurus:' dropdown menu. [3] Under the hood each 'Choose' button is a call to the JS function doauth(), which in turn calls blinddetail-biblio-search.pl with the parameters required (authid, relationship, etc.). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 42

[Bug 21309] New: Add flag to change password
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21309 Bug ID: 21309 Summary: Add flag to change password Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We should add a flag to patron accounts that, if checked, would require the patron to sign in to their account and change their password. This option could incorporate the following functionality: * Allow patron to sign in with old password then prompt for a new password. * E-mail patron notifying them with the need to change. * When active, it would block checkouts and sip authentication until done. * Anytime a password is changed in the account, whether staff side or opac, the change would clear the flag in the patron account. * Date of change should be time stamped. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 23861] New: Add authorised value categories description option
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23861 Bug ID: 23861 Summary: Add authorised value categories description option Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I really like the way the authorised values page looks now. I think it's much more user friendly with the descriptions and the categories all laid out and not in a drop-down. Right now, the descriptions for each category are "hardcoded" in the template. Would it be feasible to move those in the DB? That way, when we add new categories, we would be able to add our own description. For example, if I add a category for RDA media type, I would be able to add a description saying it's meant to be used with 337$a. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15