March 2022 - Koha-bugs - lists.koha-community.org

[Bug 28128] New: Cataloging Record Uploading Process
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '22

28 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28128 Bug ID: 28128 Summary: Cataloging Record Uploading Process Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cmkelleymls(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org About three months ago, my library moved its Koha ILS to a new machine. The transition was not ideal but it was smooth enough. We still catalog a bit on the old machine and last week we extracted and uploaded a bunch of records to the new machine. The upload process stalled. After days of trying to find out why the uploading process would stall, I noticed that the 952 $7 in a few records was miscoded as a 952 $9 instead. Once I reverted the 952 $9 to 952 $7, all was well. This also happened when a transfer record had a 999 field. If the record number in 999 $c and 999 $d did not exist, the uploading processing would stall. So I deleted the 999 fields or corrected them to what was in the other copy of the ILS; and again all was well. I have been reading online about this phenomenon and I haven't found a reason or solution to the stall. Mind you, other operations continue to run: the editing of existing records and the entry of new records; circulation; calendar changes, etc. It's just the automatic record uploading through the user interface that stalls. Well, here are two possible solutions: check for 952 $9 fields and 999 fields in the records that are to be uploaded. They may be the source of stall. Their presence may not be the only source, mind you, but their presence is a possibility. P. S. It would be nice if instead of stalling, the uploader would write the MARC record to some sort of upload log with a reason; and then try uploading the next record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 30150] New: Dutch option in language limits is garbled
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '22

27 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30150 Bug ID: 30150 Summary: Dutch option in language limits is garbled Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org Created attachment 130998 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=130998&action=e… screenshot of bug To recreate: - add Dutch "dut" to the AdvancedSearchLanguages option - go to the advanced search page /cgi-bin/koha/opac-search.pl - click open the Language select menu - note that the text for Dutch is "nedərlɑns (Dutch)" It should render as "nedərlɑns (Dutch)" but instead the numerical character references for the fourth and seventh characters are rendered literally, as if they were escaped. I haven't looked into this further so I don't know _why_ this is happening but Koha's OPAC uses charset=utf-8 so I think we should be able to simply use the actual characters without any references. Perhaps it's a problem with the encoding of strings in the database? But when I run a report to pull all the rows from the `language_descriptions` table, the word "nedərlɑns" renders correctly. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 20126] New: Saving a biblio does no longer update MARC field lengths
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '22

27 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20126 Bug ID: 20126 Summary: Saving a biblio does no longer update MARC field lengths Change sponsored?: --- Product: Koha Version: master 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See bug 10455. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 28723] New: Holds table not displayed when it contains a biblio without title
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '22

26 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28723 Bug ID: 28723 Summary: Holds table not displayed when it contains a biblio without title Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Staff Client Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Steps to reproduce: 1. Create a biblio without title, then create an item for this biblio. 2. Place a hold on it. 3. Go to the patron detail page and click on the Holds tab 4. Confirm that holds are not displayed (the table is there but empty) In the browser console you can see an error message: > Uncaught TypeError: oObj.title is null -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 29860] New: Useless warnings in regressions.t
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '22

25 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29860 Bug ID: 29860 Summary: Useless warnings in regressions.t Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org To reproduce: 1. Run: $ kshell k$ prove t/db_dependent/selenium/regressions.t => FAIL: You see several item-level_itypes set but no itemtype set for item (985) at /kohadevbox/koha/Koha/Schema/Result/Item.pm line 905. and Wide character in print at /usr/share/perl/5.32/Test2/Formatter/TAP.pm line 156. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 28068] New: Cash register should not record writeoff as cash received
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '22

25 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28068 Bug ID: 28068 Summary: Cash register should not record writeoff as cash received Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org While reviewing register details I found that write offs are recorded as cash received. Unless I misunderstand write-offs, no cash is received but is meant to act as a type of forgiveness. This is confusing because it adds to the total cash received in the cash register. The register summary excludes the write off in the total bankable, but without knowing why there is a difference between the total received and bankable it can lead to confusion. The current summary (example): Last cashup: 03/30/2021 01:28 PM Float: 25.00 Total income (cash): 68.95 (68.40) Total outgoing (cash): -5.10 (-5.10) Total bankable: 63.30 Proposed change (example): Last cashup: 03/30/2021 01:28 PM Float: 25.00 Total income (cash): 68.95 (68.40) Total outgoing (cash): -5.10 (-5.10) Total write-offs: -0.55 Total bankable: 63.30 Or even better, do not include write-offs as cash received since no money enters the drawer during that transaction. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 30336] New: Default sort order of late orders
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '22

25 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30336 Bug ID: 30336 Summary: Default sort order of late orders Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement 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 It seems like the sort order in the late orders column changed at some point. Right now it sorts by ordernumber, but it would be nice if this could be changed to order date or even "days late" to make sure that the oldest ones sort to the top. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29901] New: Editing purchase suggestions create a new suggestion
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '22

25 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29901 Bug ID: 29901 Summary: Editing purchase suggestions create a new suggestion Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, When a purchase suggestion is created from the OPAC and then edited, the first suggestion is not edited and a new suggestion is created. To recreate : 1. Create a purchase suggestion from the OPAC 2. In the staff interface, edit the suggestion. For exemple, edit the copyright date field and save the change 3. Refresh the OPAC purchase suggestions page 4. Refresh the staff interface purchase suggestions page Results : The first suggestion with the first copyright date is still there and a new suggestion is created with the new copyright date and the same other informations (title, author, etc.) Note : I also tested with the author field and the result is the same, it's not specific to the copyright date field. I also tested on a 21.05 demo site and I have the same problem. Thank you ! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30197] New: Transaction library in cash register statistics does not reflect the information in accountlines
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '22

25 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30197 Bug ID: 30197 Summary: Transaction library in cash register statistics does not reflect the information in accountlines Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Created attachment 131172 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=131172&action=e… Cash register statistics Hi, In cash register statistics, for column transaction library, user's branch is displayed and not branch of transaction, as can be read in the table accountlines. See images attached. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 26357] New: Create preference for staff notification of patron self-renewals
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '22

25 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26357 Bug ID: 26357 Summary: Create preference for staff notification of patron self-renewals Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Have a preference to whether or not patron modification requests include patron modifications that are simply renewal updates that acknowledge that no information has changed in the account. This relies on bug 26355. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7