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

[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 10 Jun '24

10 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

[Bug 36401] New: Re-think use of "N/A" in ILL module
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36401 Bug ID: 36401 Summary: Re-think use of "N/A" in ILL module 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I just stumbled on that string again and I'd like us to check if we couldn't do better: * We don't use it in any other module in Koha but ILL, but there a lot * It often poses a problem in translations as people are not aware what it means -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 36551] New: Ability to alert library staff when new ILL requests are placed
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36551 Bug ID: 36551 Summary: Ability to alert library staff when new ILL requests are placed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucy.vaux-harvey(a)ptfs-europe.com CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com For libraries that do not have dedicated interlibrary loan staff it is useful for staff to be alerted when a new request needs actioning. Staff can currently be alerted to cancelled and modified requests via the notices ILL_REQUEST_CANCEL and ILL_REQUEST_MODIFIED but not for new requests. There is a similar feature is available for holds by enabling the system preference emailLibrarianWhenHoldisPlaced. An alternative would be to highlight new ILL requests on the homepage dashboard in a similar way to purchase suggestions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 23187] New: Koha::Objects supports find_or_create without passing through the Koha::Object store method
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23187 Bug ID: 23187 Summary: Koha::Objects supports find_or_create without passing through the Koha::Object store method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P1 - high Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, jonathan.druart(a)bugs.koha-community.org, koha-bugs(a)lists.koha-community.org, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 21761 Blocks: 23185 Target Milestone: --- +++ This bug was initially created as a clone of Bug #21761 +++ If we're adding triggers at the code level all over the place by overloading the store method we need to never ever let dbic handle it.. by allowing directly passing data to dbic's find_or_create method in Koha::Objects we are exposing ourselves to places in the codebase skipping the store triggers. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21761 [Bug 21761] Koha::Object supports passing through 'update' which means we can side step 'set' + 'store' https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23185 [Bug 23185] Koha::Objects supports passing through 'update' which means we can side step 'set' + 'store' -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. You are watching all bug changes.

1 8

[Bug 32747] New: OPAC detail page explodes for items without itemtype
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32747 Bug ID: 32747 Summary: OPAC detail page explodes for items without itemtype Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 When there is an item without itemtype the OPAC detail page explodes: Error trace Can't call method "itemtype" on an undefined value at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 713 I know we agreed not to fix this everywhere, but I think there is definitely a need to fix it in this very spot, because it's on a main page in the OPAC. One thing that can cause this: We just very recently made itemtype mandatory on the acq item form. On order items often had no itemtypes in the past and it was not a problem. Libraries would assign the itemtype on delivery/receive, avoiding any issues in circulation. There might be quite a lot of those 'in the wild'. -- You are receiving this mail because: You are watching all bug changes.

1 17