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

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

16 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 52

[Bug 30800] New: Ability to view, modify, and delete profiles for staging MARC records for import
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30800 Bug ID: 30800 Summary: Ability to view, modify, and delete profiles for staging MARC records for import Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be useful to have a place to view/edit all profiles that a library has created for use while staging MARC records for import in one place - maybe similar to 'Manage MARC modification templates'. It could include each profile's settings and the ability to delete individual/multiple at a time, and if possible, the ability to add new, edit existing, and/or duplicate to create new. But at a minimum, being able to see what exists and delete from there rather than the 'Stage MARC records for import' screen would be helpful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

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

16 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 13

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

16 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 27

[Bug 17385] New: Add custom export notices
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17385 Bug ID: 17385 Summary: Add custom export notices Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: bouzid.fergani(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl this patch, add custom export notices using xslt. -- You are receiving this mail because: You are watching all bug changes.

1 448

[Bug 30719] New: ILL should provide the ability to create batch requests
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30719 Bug ID: 30719 Summary: ILL should provide the ability to create batch requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Some interlibrary loan providers, for example Reprints Desk, allow for ILL requests to be submitted in batches. In the Reprints Desk case, a batch is created with the supplier, then requests are then submitted including the batch ID. Obviously, this workflow may differ according to supplier and these differences should be abstracted away into the supplier backend. For core Koha, we should provide the ability for it to recognise if a given backend can process batch requests. If so, we should provide an interface for creating and manipulating batches within Koha, then submitting a batch to the supplier. It should also be possible to view all batches and the contents of a given batch. The funding institution has defined the following workflow for creating and populating batches: - A encapsulating "batch" is created with a name and a requesting borrower - Requests are added to a batch via two methods: - In bulk: - A form which allows the user to paste in a collection of identifiers, such as DOI / PMID etc. - For each of these identifiers: - The request metadata should be populated via API queries to metadata suppliers, for example, PubMed API or LibKey/Browzine. This behaviour is governed by the presence of appropriate plugins. - (Optional) Once the metadata is populated for an item, we check for item availability via any installed ILL availability plugins - Individually: - A regular ILL request form, requests are added to the batch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 195

[Bug 30759] New: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30759 Bug ID: 30759 Summary: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 14242 On bug 14242 Victor suggested to add a hint to the OPACSuggestionAutoFill system preference that explains about possible implications to data privacy and lists which data is sent via the Google Books API: (In reply to Victor Grousset/tuxayo from comment #118) > And meanwhile, should a small warning in the syspref description be added? > So the library can update their documents about their personal data > processing. > > Something like «Personal data processing: Google will receive the following > data: IP address, OS name, web browser version, preferred languages, and the > ISBNs of the books suggested.» Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14242 [Bug 14242] Use ISBN-field to fill out purchase suggestions using Google Books API -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 29720] New: Allow per-user customization of table settings
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29720 Bug ID: 29720 Summary: Allow per-user customization of table settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 Table settings are currently global. Per-user customization would be great! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 26197] New: Using Rancor while cataloging doesn't appear to check for existing records
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26197 Bug ID: 26197 Summary: Using Rancor while cataloging doesn't appear to check for existing records 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 Upon testing this, while cataloging a new record using the basic editor Koha will find a duplicate record existing in Koha but didn't find the same duplicate using the Advanced Editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 30255] New: Allow skipping "list" step for record batch modification/deletion
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30255 Bug ID: 30255 Summary: Allow skipping "list" step for record batch modification/deletion 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: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We encountered an issue using the Batch record modification/deletion-tools for a very large number of records. The "list" step where records can be optionally excluded is not relevant in our use-case and takes forever to load. This patch adds an option for skipping this step and directly enqueue the job for all specified records. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 49