August 2023 - Koha-bugs - lists.koha-community.org

[Bug 29718] New: DateTime - our 'iso' is not ISO 8601
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '25

04 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29718 Bug ID: 29718 Summary: DateTime - our 'iso' is not ISO 8601 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: In Discussion Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com In some scripts we are doing unnecessary conversion from string to DT and vice-versa, sometimes several times. For instance, see bug 29711. We have epoch => DT => string => sending to template in 'iso' YYYY-MM-DD HH:MM => DT => string. This is because the stringified version of DT (the real ISO 8601 YYYY-MM-DDTHH:MM:SS) is not supported by our dt_from_string method. There are (at least) two options: * Use DateTime::Format::Strptime In dt_from_string: my $formatter = DateTime::Format::Strptime->new(pattern => '%Y-%m-%d %H:%M:%S'); return DateTime->now( time_zone => $tz, formatter => $formatter, ) unless $date_string; Then later $dt_params{formatter} = $formatter; But that's an overhead for all dt_from_string calls. * add "T?" to $time_re, easy and efficient. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 60

[Bug 18986] New: High Hold Items with Decreased Loan Period Can' t Be Checked-Out with Self-Check
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '25

03 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18986 Bug ID: 18986 Summary: High Hold Items with Decreased Loan Period Can't Be Checked-Out with Self-Check Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: cslone(a)camdencountylibrary.org QA Contact: testopia(a)bugs.koha-community.org Scenario: A patron has an item with a high number of holds ready for pickup. They come to their library get the item and use the SCO to try to borrow it. When they scan the item they are given the message: Item cannot be checked out. Sorry, this item cannot be checked out at this station. Please see a member of the library staff. Additionally, if they don’t notice the message and scan another item, they are returned their account summary/the check-out screen with neither item checked out to the patron. At best this creates a scenario where there's an inconvenient extra step that the patron has to take in order to get their item. At worst, it can lead to the patron inadvertently taking two items with them that have not been checked-out. For the item that is on hold this can lead to further confusion when the it is returned (Koha will indicate that the item must go back on the hold shelf for the patron that just returned it) or when holds are cleared from the shelf (the item will be listed there but won’t be found). To replicate: 1.) In system preferences, go to Circulation preferences->Holds Policy. 2.) There are five preferences grouped together for decreaseLoanHighHolds, make sure to set the first drop down to Enable and enter the reduced loan period and the number of holds that will trigger the reduction (you can configure the other options as desired). 3.) Place a hold on an item with a patron you can use at self-check and place enough additional holds on the item with other accounts in order to trigger the decreased loan period according to your preferences. 4.) Check-in an item from the record with the holds and confirm the hold for the patron. 5.) Log into self-check with this patron and attempt to check-out the item. 6.) You will be taken to the error message. 7.) Scan the barcode again, you'll be returned to the SCO screen. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 32879] New: Item search: Display additional 245 subfields in CSV export
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '25

03 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32879 Bug ID: 32879 Summary: Item search: Display additional 245 subfields in CSV export Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Bug 14911 fixes this for the result list of the item search. It would be grat if the CSV export file could also include the additional information. It's not as simple as using the biblio-title include there too, as that adds spans that you don't want in the CSV file. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 20905] New: Warn from Search.t
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '25

03 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20905 Bug ID: 20905 Summary: Warn from Search.t Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Test passes but look at this warn from getRecords: ok 67 - presence of a transit does not block hold request action (bug 10741) ERROR DECODING RECORD - Tag "50%" is not a valid tag. at /usr/share/perl5/MARC /File/USMARC.pm line 223. : 00295nam a22001217a 45000030004000000050017000040080041000211000018000622450 0570008050%001100137942001200148999001300160OSt20111207151138.0111207t xxu||||| |||| 00| 0 eng d aGanser, Helen aA record containing a punctuation character as a tag aa note 2ddccBK c214d214 at /usr/share/koha/devclone/C4/ Search.pm line 683. ok 68 - search for ti:punctuation returned expected number of records A few lines later in the test, a warning_like also looks for this error. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 25362] New: Code to create CGISESSID shoudl be in function
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '25

03 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25362 Bug ID: 25362 Summary: Code to create CGISESSID shoudl be in function 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I found 12 difference instances where we create the CGISESSID cookie, and each one has its own invocation that needs to be updated when you want to change that cookie. It would be better if we wrapped the cookie creation in a function. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 24097] New: Don't show claims tab in patron account, when there are no claims
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '25

02 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24097 Bug ID: 24097 Summary: Don't show claims tab in patron account, when there are no claims Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Not every library will want to use this feature - I think it would be nicer if we didn't show the tab when there are no claims, so this is a bit more 'invisible'. It also matches how we handle other tabs. -- You are receiving this mail because: You are watching all bug changes.

1 9

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

02 Jul '25

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 64

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

02 Jul '25

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 104

[Bug 34365] New: Hold cancellation request workflow cannot be triggered on API
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '25

02 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34365 Bug ID: 34365 Summary: Hold cancellation request workflow cannot be triggered on API Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Rigth now the `DELETE /holds/:holds` route does a straight-cancellation of the hold. It should be possible to trigger the hold cancellation request workflow so thrid-party systems can use it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 32441] New: Localuse is recorded in statistics but not recreated in pseudonymized_transactions
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32441 Bug ID: 32441 Summary: Localuse is recorded in statistics but not recreated in pseudonymized_transactions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The pseudonymization feature creates a parallel to the statistics table without identifiable patron data. This allows one to then use cleanup_database to delete old entries in statistics to remove that patron data. However, the statistics table also contains records of local use. That data only exists in statistics. It is not duplicated in pseudonymized_transactions, and so is lost if statistics are deleted using cleanup_database. Bug 32440 suggests teaching cleanup_database to not delete localuse entries. This bug suggests putting localuse entries into pseudonymized_transactions, even though no patron is involved. That's a bit illogical, but has the benefit of keeping all of this data together. Meanwhile, Bug 16122 suggesting keeping a local use count in the item record. That would alleviate this issue somewhat, but specific transactional data would be preferable to a running count. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5