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

[Bug 22972] New: Proposal for enriching the bibliographic records with standard identifiers from authority data
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22972 Bug ID: 22972 Summary: Proposal for enriching the bibliographic records with standard identifiers from authority data Change sponsored?: --- Product: Koha Version: unspecified 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: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Thinking in terms of linked data, it would be of profit to have as much of standard identifiers in the bibliographic data produced by the library as possible. Libraries use authority data coming from official sources (like LoC, SUDOC, etc.) or enrich their locally created authority records with standard identifiers (e.g. viafId, ISNI, Wikipedia). This information is linked to the bibliographic record by the Koha-specific subfield $9 which is illegal in terms of MARC 21 and does not mean anything outside of the local Koha ecosystem. A record moved out of a local Koha catalogue (downloaded, exported) loses the linked-data connection to other objects (like authors, subjects etc.), which are then identified only by strings. To make this connection between bibliographic access point and objects identified by universal identifiers more permanent outside of the local environment, the standard MARC 21 $0 subfield could be used. (UNIMARC has to be examined - $3 subfield?) The required changes would include at least: C4::AuthoritiesMarc::merge function, the authority plugin, some new system preferences, optionally display templates and also a script to update the existing biblio records. New possible system preferences needed: - switch the feature on/off - source of the standard IDs (possibly different for different biblio fields?) (standard in MARC 21 authority: 024, but may be also 010/035) (a list) - how many ids should be copied (= how may $0 added): only the first found or all of them - if an extra link/icon should be generated in display (OPAC / librarian) Please, share your comments about this idea. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 72

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

05 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 7

[Bug 16291] New: koha-remove --purge should also delete /etc/koha/sites/instance
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16291 Bug ID: 16291 Summary: koha-remove --purge should also delete /etc/koha/sites/instance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org It would be useful if 'koha-remove --purge' also deleted a /etc/koha/sites/instance dir -- You are receiving this mail because: You are watching all bug changes.

1 15

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

05 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 50

[Bug 24237] New: The 406 response on the biblios end point should be more discoverable
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24237 Bug ID: 24237 Summary: The 406 response on the biblios end point should be more discoverable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Other endpoints default to an application/json response by default regardless of the Accept headers in the request. For consistency, we should do the same on the biblios endpoint.. I'm thinking a 406 still, but with a JSON encoded error message in the body explaining the available Accept headers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 21357] New: Filter elisions from index and search terms in Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21357 Bug ID: 21357 Summary: Filter elisions from index and search terms in Elasticsearch 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: ere.maijala(a)helsinki.fi To make searching easier at least in French, it would be nice to have the default configuration handle elisions properly (e.g. l'avion). Coming up with a proposed patch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 105

[Bug 25900] New: Double quotes breaks search with Zebra and QueryWeightFields
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25900 Bug ID: 25900 Summary: Double quotes breaks search with Zebra and QueryWeightFields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com Search with Zebra and system preference QueryWeightFields on builds a query with surrounding double quotes : q=tree => q="tree". Therefore existing double quotes are replaced by a space : q="tree" => q=" tree ". Looks like the leading space breaks the search, 0 results. Experimented on Ubuntu Xenial and Bionic with Indexdata repository so Zebra version is 2.1.4. It might be specific to this version. You can reproduce with direct CCL query (regardless QueryWeightFields) : https://demo.biblibre.com/cgi-bin/koha/opac-search.pl?idx=&q=ccl%3Dti%2Cphr… https://demo.biblibre.com/cgi-bin/koha/opac-search.pl?idx=&q=ccl%3Dti%2Cphr… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 25572] New: Permissions for Mana Reports are currently linked to Permissions in Serials
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25572 Bug ID: 25572 Summary: Permissions for Mana Reports are currently linked to Permissions in Serials Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Mana-kb Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com Mana works with both Reports and Serials. Currently a staff member needs to have a serial permissions to be able to use the Mana function in the reporting module. If the staff member does not have the permission, "Create A New Subscription", the staff member can not use Mana in the reports module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 26472] New: Elasticsearch - ES - Authority record results not ordered correctly due to punctuation marks
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26472 Bug ID: 26472 Summary: Elasticsearch - ES - Authority record results not ordered correctly due to punctuation marks Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather_hernandez(a)nps.gov When searching authorities, the results are grouped by punctuation, e.g.: Word (Word) Word Word Word-Word Word, Word For example: Saint (Fictitious... Saint Charles School Saint Hilaire Institute Saint Patrick Club Saint-Nazaire (France) Saint-Pierre (Martinique) Saint, Eva Marie Saint, Joseph But it should sort like this: Saint Charles School Saint, Eva Marie Saint (Fictitious... Saint Hilaire Institute Saint Patrick Club Saint-Nazaire (France) Saint-Pierre (Martinique) There is documentation of this filing order in _Library of Congress Filing Rules_ which can be freely accessed here: https://babel.hathitrust.org/cgi/pt?id=mdp.39015022080140&view=1up&seq=3 Especially in section 1, General Filing Order: ---Begin quote: Fields in a filing entry are arranged word by word, and words are arranged character by character. This procedure is continued until one of the following occurs: a. A prescribed filing position is reached. b. The field comes to an end (in which case placement is determined by another field of the entry or by applying one of the rules given hereafter). c. A mark of punctuation indicating a subarrangement is encountered. 1.1. Order of Letters Letters are arranged according to the order of the English alphabet (A-Z). Upper and lower case letters have equal filing value. 1.1.1. Modified Letters Modified letters are treated like their plain equivalents in the English alphabet. Thus all diacritical marks and modifications of recognizable English letters are treated as if they did not exist; e.g., ä, á, å, ł , ñ, ø are filed as a, 1, n, o. The treatment of special letters that cannot be readily equated with English letters is described in Rule 17. Example Hand blows Hand book for Prospect Park Hand in glove Håndbok for sangere Handbook for adventure Hände am Pflug Hands on the past Haṇḍu [Indic surname] 1.2. Placement of Numerals Numbers expressed in digits or other notation (e.g., roman numerals) precede letters and, with few exceptions, they are arranged according to their numerical value. According to this rule, all filing entries beginning with numerals appear before entries beginning with the letter A. Numbers expressed as words are filed alphabetically. Detailed instructions for filing numerals are given in Rule 16. Example 1, 2, 3, and more 1, 2, buckle my shoe 3 died variously 10 ways to become rich 13 jolly saints 112 Elm Street 838 ways to amuse a child 1000 spare time money making ideas 1984 10,000 trade names 1,000,000 delinquents A is for anatomy A4D desert speed run Aa, Abraham Henry II Henry 3 Henry VIII and his six wives Henry Street Settlement, New York Henry the Fourth, part two Longitude 30 west Longitude and time Nineteen eighty-four Oberlin College one, two, three for fun Rubinstein, Moshe F. Ten thousand miles on a bicycle Three 14th century English mystics Three by Tey Thucydides 1.3. Signs and Symbols Nonalphabetic signs and symbols within a field are generally ignored in filing and the remaining letters or numerals are used as the basis of arrangement (see also Rule 18). 1.3.1. Punctuation Punctuation as such has no place in the collating sequence of characters considered in filing arrangement. A mark of punctuation is taken into account, however, in two situations: 1) when it signals the end of an element or field and indicates the need for subarrangement as described in the following rules; and 2) when it serves as the sole separator between two discrete words (e.g., Mott-Smith; 1951/1952; 1:3) and so must be treated as equivalent to a space. The second situation dictates that a hyphen will always be treated as a space (see also Rules 12 and 16). ---End quote -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 65

[Bug 24172] New: Locale is ignored when saving season/month/day name in the database
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24172 Bug ID: 24172 Summary: Locale is ignored when saving season/month/day name in the database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials 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: colin.campbell(a)ptfs-europe.com Hi All, it seems the locale is completely ignored when creating numbering with season/month/day names. What I'm getting on master is that the season name is saved in English in the database, ignoring the locale completely, and depending on the page, the season name will be translated or not for display purposes in the staff interface language. (Steps 1-4 of the test plan are related to bug #20511, but I feel they are related since both have to do with locale being ignored.) Here's what I did : 0- Make sure you have at least one language other than English installed 1- With staff interface in English, create a subscription with a seasonal numbering pattern and frequency, with locale in your other language 2- Check the prediction pattern, note that the season names are in English not the locale language 3- Change the staff interface to other language, redo the prediction pattern test with locale in other language, note that the season names are in other language 4- Save the subscription 5- Receive an issue, note that the season name in the "Numbered" column on serials-edit.pl is in English 6- Save your issue 7- Switch interface in other language 8- Note that the season name on serials-collection is in other language 9- If you check the database, you will see the season name is in English, even though the subscription.locale is something else Navigating through different pages, here's what I noticed: - serials-collection.pl: display is translated - serials-edit.pl: name pulled directly from db - subscription-detail.pl: name pulled directly from db - detail.pl: name pulled directly from db - opac-detail.pl: name pulled directly from db I think the locale should be used when saving the season name in the db ensuring all displays are the same and in accordance with the option specified when creating the subscription. P.S. I'm not sure it has anything to do with it, but I noticed when choosing "French" as locale, the value saved in the db (subscription.locale) is "fre" and not "fr-FR" or "fr-CA". Would that have to do with Koha not being able to find the right translations? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 129