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

[Bug 24597] New: Add ability to add note on all payment screens
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '24

27 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24597 Bug ID: 24597 Summary: Add ability to add note on all payment screens Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On pay.pl staff can add a note if 'Pay amount', 'Pay selected', or 'Write off selected' are selected yet no note textarea appears if staff select 'Pay' or 'Write-off' Staff should have the ability to add a note regardless of which type of payment they select. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 22873] New: C4::SIP::ILS::Transation::FeePayment->pay $disallow_overpayment does nothing
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '24

27 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22873 Bug ID: 22873 Summary: C4::SIP::ILS::Transation::FeePayment->pay $disallow_overpayment does nothing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Target Milestone: --- The `disallow_overpayment` parameter that's expected to be passed to the pay method of FeePayment does nothing.. it should either be removed or implimented. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 23940] New: Create SQL with mana in Reports
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '24

26 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23940 Bug ID: 23940 Summary: Create SQL with mana in Reports Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Mana-kb Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com >From the main page of the Reports Module (reports-home.pl), you can create a guided report or create a SQL report. From the guided_reports.pl page, you can create a guided report, sql report or SQL report from Mana. It would be very nice if the option to create a SQL report from Mana would be also an option on the reports-home.pl page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 20780] New: EDI: Add support for 'AcqItemSetSubfieldsWhenRecieved'
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '24

26 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20780 Bug ID: 20780 Summary: EDI: Add support for 'AcqItemSetSubfieldsWhenRecieved' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org EDI, as it stands, does not respect the AcqItemSetSubfieldsWhenRecieved system preference.. it should ;) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

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