November 2021 - Koha-bugs - lists.koha-community.org

[Bug 22348] New: Koha::EDI has no tests
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '24

26 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22348 Bug ID: 22348 Summary: Koha::EDI has no tests 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The utility functions in Koha::EDI are entirely untested and as such prone to regressions... we should write tests for them -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 24807] New: Add "year" type to improve sorting by publication date
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '24

25 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24807 Bug ID: 24807 Summary: Add "year" type to improve sorting by publication date 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 When sorting on date-of-publication (a year, field 008, positions 7-10), the current behavior when the field contains an invalid year (containing word characters like "uuuu" or just whitespace), these results appear first when sorting in descending order. Invalid values like these should really not be indexed at all. If so (having null values instead) they will always appear last when sorting, regardless of sort order. This fix adds a "year" search field type, that will reject any non-year values, resulting in a more user friendly sorting behavior. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 69

[Bug 28504] New: Hold pickup library match (hold_fulfillment_policy) not enforced when filling holds if set to "patron's group" / 'patrongroup'
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28504 Bug ID: 28504 Summary: Hold pickup library match (hold_fulfillment_policy) not enforced when filling holds if set to "patron's group" / 'patrongroup' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The case is simply not covered in the code In C4::Reserves::CheckReserves: 908 my $hold_fulfillment_policy = $branchitemrule->{hold_fulfillment_policy}; 909 next if ( ($hold_fulfillment_policy eq 'holdgroup') && (!$library->validate_hold_sibling({branchcode => $res->{branchcode}})) ); 910 next if ( ($hold_fulfillment_policy eq 'homebranch') && ($res->{branchcode} ne $item->$hold_fulfillment_policy) ); 911 next if ( ($hold_fulfillment_policy eq 'holdingbranch') && ($res->{branchcode} ne $item->$hold_fulfillment_policy) ); 912 next unless $item->can_be_transferred( { to => Koha::Libraries->find( $res->{branchcode} ) } ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 25836] New: MARC fields not able to be reordered in basic editor
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25836 Bug ID: 25836 Summary: MARC fields not able to be reordered in basic editor Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl >From bug 7882, it seems that MARC fields should be able to be reordered, however it does not appear to be working. For instance, if I have a record with 3 650 fields and 2 651 fields, I cannot move the 651 fields above the 650 fields. I can rearrange the 650 fields amongst themselves, but that's it. The move icon/hamburger shows on all fields, which leads one to think that all fields can be reordered, when this is clearly not the case. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 27421] New: Porting tools/stage-marc-import.pl to BackgroundJob
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27421 Bug ID: 27421 Summary: Porting tools/stage-marc-import.pl to BackgroundJob Change sponsored?: --- Product: Koha Version: 20.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: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org Hi! I recently started to convert tools/stage-marc-import.pl to use the new BackgroundJobs, because we're using the Plack version, which does not like the old forking implementation. While I've realized now that we can still use the old CGI script by running it directly via the frontend Apache, I'm not very happy with this workaround. So, here is my current first sort-of-working prototype: https://github.com/Koha-Community/Koha/compare/master...domm:MARCImporter Before I continue my work, I'd really appreciate some feedback if what I'm doing makes sense and matches your general plans. Obviously there is still a lot missing: * Proper feedback after starting the staging process (i.e. a link to the job) * Probably I will also need to check if the job has finished, and present a link to the next step (copy the staged records into the library) (which AFAIK will also need to be converted to BackgroundJobs) I also have a few questions: * Is it neccessary to get the job-size before starting it? If yes, then I assume I'll have to first parse the MARC file to get the job size, throwing the results away (and this might not work, because we want to do the parsing in the background in the first place). Or is there an easy way to get the number of records? * When I try to update job_size later, I get an exception (something like "job_size not tested") * Can I actually use BatchStageMarcRecords in BackgroundJob? * I see I can pass a batch size to BatchStageMarcRecords. But this will not result in more forking? This is "only" used to fire the progress callback? I'm also not sure if the bug tracker or the dev mailing list is the best place to discuss my questions? Anyway, looking forward to some feedback! Greetings, domm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 136

[Bug 28981] New: Add a syspref for marking items as unavailable in Z3950Responder
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '24

18 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28981 Bug ID: 28981 Summary: Add a syspref for marking items as unavailable in Z3950Responder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Proposal: 1 - Add a new system preference "Z39ResponderUnavailable" 2 - Similar to 'OpacHiddenItems' this will accept a list of column/value pairs 3 - Update Koha::Z3950Responder::Session::add_item_status to check the preference and mark item as unavailable 4 - Item status message will be pulled from Z3950_STATUS authorized value list -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 24161] New: Late orders improvements - keeping track of claims
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '24

18 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24161 Bug ID: 24161 Summary: Late orders improvements - keeping track of claims Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org * Allow multiple claim dates to be associated with an individual order line * Show multiple claim dates against an order line in the late orders page * Show multiple claim dates against an order line in the basket page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 102

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