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

[Bug 36299] New: Highlighting of Logged-In Library Facets not working
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '24

17 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36299 Bug ID: 36299 Summary: Highlighting of Logged-In Library Facets not working Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 34940 introduces the highlighting of the logged-in library within the facets. This does not seem to be working in 23.11.01 or in master. Changing the system preference, DisplayLibraryFacets, to home, holding or both does not change the fact that this is not highlighting the library. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 31011] New: Make hold reminders respect patron's language
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '24

17 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31011 Bug ID: 31011 Summary: Make hold reminders respect patron's language Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When running misc/cronjobs/holds/holds_reminder.pl it looks like borrowers.lang is not respected. The only code I can see that relates to language is this: # FIXME What if we don't want to default if the translated template does not exist? my $template_exists = Koha::Notice::Templates->find_effective_template( { module => 'reserves', code => $lettercode, branchcode => $branchcode, lang => 'default', } ); As far as I can see, the "default" template is always used? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 30733] New: Simplify translatable strings
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '24

15 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30733 Bug ID: 30733 Summary: Simplify translatable strings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr A.K.A "We must be nicer with translators 2" (follow-up of bug 29602) It's the same simple idea that worked well without issues: Add in templates to not have anymore translatable strings like %sEnter a new purchase suggestion%s %sPurchase suggestions%s &rsaquo; %s%s%sKoha online%s catalog git is a great help to review this patch. Don't use the bugzilla diff view. Apply the patch and use: git show --color-words=. Now you will see just the added You can search for and go one by one to check that the opening and closing tags match and that there is no typo. Then the same with I already did that though, so you might want to spare pressing the "n" (next) key 1300 times (684 x 2) --- This patch has been made by searching in the translation platform for "%s" and inspecting the 2300 strings containing it to find those that are terrible to translate: those with tons of %s which are a concatenation of independent strings. Mainly the IFs in template produce these abominations. bug 29602 focused on CASE statement. This is an attempt for all the rest. Except for CSV templates and page <title> tags because can't be used there. Some less terrible strings have been skipped due to lack of time. --- I tried to think about right to left languages in cases like Confirm deletion of subfield [%- tagsubfield | html -%] I included the variable tagsubfield in the so there will be a %s in the translatable string which should allow to invert the order when translating to be RTL. And also I included semicolons in the when the context allows for a translated version with the semicolon on the left to make sense. If the context has a related thing just after on the same line (on the right) to the string, then I didn't include the semicolon to leave it "pointing" at the right thing. Even though that's wrong, but we can't swap the phrases. caveat: I don't have any experience in translating RTL in Koha so I'm not sure if these things help. And I just noticed we have an RTL CSS that might actually swap stuff. If that's the case, the fact that I left the semicolon outside the might not be an issue because it should end up swapped right? --- There are a few fixes like Payment[% ELSE %]Transaction[% END %] type: </label> ↓ Payment type[% ELSE %]Transaction type[% END %] type: </label> because having "type" separated removes the context and it locks the word order as same as English. Which makes this string not possible to correctly translate in French, Spanish and Esperanto for example. --- There is a double , it looks like: Author(s) This is expected. There was already one spanning (ha ha) a few lines and I needed another one just for the string on this line. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 147

[Bug 36402] New: A Link on Reports Module Homepage - New SQL from MANA
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '24

14 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36402 Bug ID: 36402 Summary: A Link on Reports Module Homepage - New SQL from MANA Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org it would be great to have a Link on Reports Module Homepage to create a New SQL report from MANA Database. Current Steps navigate to the reports module click on Create from SQL click dropdown for new sql from Mana This will help with a few less clicks. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 30872] New: Table on claims.tt ( missing issues table ) should be column configurable
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '24

14 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30872 Bug ID: 30872 Summary: Table on claims.tt ( missing issues table ) should be column configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 30039 adds another column to an already large table in claims.tt. That table should be column configurable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21322] New: process_message_queue.pl --type should take an argument
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '24

14 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21322 Bug ID: 21322 Summary: process_message_queue.pl --type should take an argument Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz If you run process_message_queue.pl -h you get this, among other things: -t --type: If supplied, only processes this type of message ( email, sms ) But if you try to use --type like this: process_message_queue.pl -v --type=sms" <instance> You get this error: Option type does not take an argument This is because the setup of the type argument is wrong. This: 't|type' => \$type, should be this: 't|type:s' => \$type, -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 29888] New: ->search_limited logic breaks searches
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '24

11 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29888 Bug ID: 29888 Summary: ->search_limited logic breaks searches Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major 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 When writing unit tests for bug 29886, in which I was moving bug 23991 addtion of Koha::Suggestions->search_limited I noticed a problem with how the query is amended to deal with limitations: instead of relying on chained searches, it tries (badly) to tweak the passed parameters. This line was disturbing to me: $params->{branchcode} = { -or => [ $userenv->{branch}, '' ] }; it means any query on branchcode will be overwritten! (another bug could be filed to discuss that '' in there). I propose to revisit the current ->search_limited implementations, and fix them: $ git grep 'sub search_limited' Koha/ArticleRequests.pm:sub search_limited { Koha/Patron/Discharge.pm:sub search_limited { Koha/Patrons.pm:sub search_limited { Koha/Reviews.pm:sub search_limited { -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 30736] New: Upgrade 'libsearch-elasticsearch-perl' package to version 6.00
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '24

11 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30736 Bug ID: 30736 Summary: Upgrade 'libsearch-elasticsearch-perl' package to version 6.00 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com this bug tracks the upgrade of 'libsearch-elasticsearch-perl' package to version 6.00 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 21972] New: Record matching rule for authorities only works for first 20 authority records
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '24

11 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21972 Bug ID: 21972 Summary: Record matching rule for authorities only works for first 20 authority records Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: simon.hohl(a)dainst.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 82955 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=82955&action=ed… MARC File containing geographical authority data The summary is already my first interpretation, the following is happening: I am trying trying to import some custom authority data (see attached mrc file) and have defined a matching rule accordingly: Match threshold: 1000 Record type: Authority record Match point 1: Search index: indentifier-standard Score: 500 Tag: 024 Subfields: a Offset/Length: 0 Match point 2: Search index: indentifier-standard Score: 500 Tag: 024 Subfields: 2 Offset/Length: 0 While using the command line interface (staging + commit) to automatically update authority data, I noticed that the number of successfully matched records was far too low. As a strict test I then did the following: 1. Import the data using the bulkimport script 2. Upload the same data in the staging Interface 3. See which records match and which do not, in order to find a pattern in those who fail. The only pattern I encountered was the following: Only the (initially) first 20 imported records are actually matched. Meaning only authorities with ID 1 to 20 are successfully matched with the staged import, everything else stands as "No Match". I tried this with different sets of place data, still the same result. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 33024] New: Lazy load the components in the routes definition
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '24

11 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33024 Bug ID: 33024 Summary: Lazy load the components in the routes definition Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com In routes/erm.js we should lazy load the components https://vuejs.org/guide/components/async.html -- You are receiving this mail because: You are watching all bug changes.

1 7