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

[Bug 23236] New: Remove 'its items may still be processed' in action if no match is found
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23236 Bug ID: 23236 Summary: Remove 'its items may still be processed' in action if no match is found Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I think this is only a string bug, but I'd like a developer to make sure nothing happens behind the scenes. When importing records and looking for duplicate records using record matching rules, there is an option if NO match is found to "ignore incoming record (its items may still be processed)". This doesn't make any sense. Where would the items go if there is no match? To reproduce : 1) Go to tools > Stage MARC for import 2) Browse and choose a file and click on Upload file 3) Go to the Look for existing records in catalog? section 4) Open the drop down for Action if no match is found 5) Note that one option says Ignore incoming record (its items may still be processed) This option should only say Ignore incoming record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 21708] New: Editing a record moves field 999 to first in the marcxml
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21708 Bug ID: 21708 Summary: Editing a record moves field 999 to first in the marcxml Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl 1) Import or create a new record. 2) Examine the marcxml of that record in the database - the fields are in the correct numerical order. 3) Edit the record - no need to change any data, just save it. 4) Examine the marcxml in the database - the 999 field is now right after leader and before 001. This is due to TransformHtmlToMarc in C4/Biblio.pm, specifically the $param eq 'biblionumber' case, which pushes the param in the array first, and then the sub uses $record->append_field() Perhaps the array should be sorted by field tag before appending the fields? AFAIK, this doesn't really show up anywhere in Koha, but if you ever edit the records via a script using MARC::Record, new fields cannot be easily inserted into correct position. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 17143] New: Popup Notification for decreaseloanhighholds preference
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17143 Bug ID: 17143 Summary: Popup Notification for decreaseloanhighholds preference Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you have an item that meets the holds requirement by the decreaseloanhighholds preference, but doesn’t get a decrease in the actual checkout period; you still get a popup notification that the high demand feature is being used and the loan period will be decreased. The notification shouldn't populate if the decreased loan period matches or is higher than the original loan period. The current behavior in the system looks at the the number of holds and doesn't take the loan periods with an equal value into consideration when enforcing the preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 17693] New: Add option to export deleted bibs in export_records.pl
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17693 Bug ID: 17693 Summary: Add option to export deleted bibs in export_records.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Currently the export_records.pl script has an option to export a list of deleted items, but not deleted biblios. There are cases where such an export would seem useful (at Aristotle University of Thessaloniki we have been using it for a long time), the data is already kept in the deletedbiblio table, so the enhancement is easy to implement as it only requires a couple lines of code in the export script. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 23488] New: Line wrapping doesn't always respect word order in Patron card creator
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23488 Bug ID: 23488 Summary: Line wrapping doesn't always respect word order in Patron card creator Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: maryse.simard(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org In patron card creator, layouts can define up to three lines of text to print to the card. When the text of a line is too long, wrapping will happen. If the wrapped text contains a word that is repeated at least once in the string, the words in the text can be rearranged, the repeated words being grouped together. To reproduce, I use the following text that I put in a card layout : "one two three one two three one two three one two three one two three one two three one two three one two three" I then export some patron cards using this layout. In the resulting file, the words are all out of order : all of the ones appear first, followed by all the twos and only then the threes. The problem is that wrapping happens by finding the last word that can be cut from the string and putting it in a new line. But, when the word is then removed from the original text, only the first occurrence is removed if it appears more than once. The new last word to be removed from the end of the line is the same word again and again until there is none left. We should make sure to remove the word at the end of the line, exactly where we found it to start with. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 24294] New: Creating an order with ACQ framework using 00x fields doesn't work
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24294 Bug ID: 24294 Summary: Creating an order with ACQ framework using 00x fields doesn't work Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com When trying to add an order using the ACQ framework with a 008@ tag, Koha explodes: Control fields (generally, just tags below 010) do not have subfields, use data() at /home/vagrant/kohaclone/C4/Acquisition.pm line 3272. at /usr/share/perl/5.24/Carp.pm line 167 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 24566] New: UpdateItemLocationOnCheckin triggers SIP2 alert flag, even with checked_in_ok enabled
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '20

15 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24566 Bug ID: 24566 Summary: UpdateItemLocationOnCheckin triggers SIP2 alert flag, even with checked_in_ok enabled 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com If UpdateItemLocationOnCheckin, it triggers an alert flag but cannot be acted on in the same way as LocalUse and thus should be removed in the same fashion. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 24705] New: Holds placed via SIP will be given first priority
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '20

15 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24705 Bug ID: 24705 Summary: Holds placed via SIP will be given first priority Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com The SIP server does not calculate and pass a priority to AddReserve, which causes the hold to be given priority 1. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 22744] New: 'Do not notify' is really a 'Clear' option
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '20

15 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22744 Bug ID: 22744 Summary: 'Do not notify' is really a 'Clear' option Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- 'Do not notify' in messages sort of hints that messages will be prevented, however, when checked it simply clear the other boxes. Hold notices wil generate print even when nothing is selected, so we shouldn't imply that there is an 'Opt out'/'Do not notify' (see bug 5501 for that) The goal of this bug is to simply rename this option -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 24131] New: Improved formatting for output of updatedatabase
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '20

15 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24131 Bug ID: 24131 Summary: Improved formatting for output of updatedatabase Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some updates include more than just the 'Updated to' text.. like Warnings and Notes to run scripts. It would be nice to format these nicely in the webinstaller. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 60