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

[Bug 25405] New: Make separation of Shibboleth and Local login clearer in modal
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '22

29 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25405 Bug ID: 25405 Summary: Make separation of Shibboleth and Local login clearer in modal Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently in the OPAC if you have Shibboleth enabled the loginModal is a bit confusing when differentiating between local and shib logins. It would be nice if this was a bit clearer. I'm proposing the idea of using jQuery UI tabs to split them into separate tabs. -- You are receiving this mail because: You are watching all bug changes.

1 45

[Bug 23676] New: Elasticsearch - 0 is not a valid boolean for suppress
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '22

28 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23676 Bug ID: 23676 Summary: Elasticsearch - 0 is not a valid boolean for suppress Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com To recreate: 1 - Enable ES 2 - Enable OpacSuppression 3 - Suppress a bib in staff client Edit 942n to be 1 4 - Search the opac for anything 5 - Tail the plack logs and note a deprecation warning In a production system these add up fast and can fill the disk -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 17805] New: Add new authority type EVENT_TERM
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '22

28 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17805 Bug ID: 17805 Summary: Add new authority type EVENT_TERM Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: verolencinas(a)yahoo.com.ar QA Contact: testopia(a)bugs.koha-community.org The Update No. 23 from November 2016 adds new fields, subfields and a new authority type: "Named Event". Koha should add a new authority type, for example EVENT_TERM, and add the new fields (see http://www.loc.gov/marc/authority/adapndxf.html) to Authorities. -- You are receiving this mail because: You are watching all bug changes.

1 3

[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 30523] New: Quiet console warning about missing shortcut-buttons map file
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '22

26 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30523 Bug ID: 30523 Summary: Quiet console warning about missing shortcut-buttons map file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The Flatpickr addon shortcut-buttons-flatpickr includes a line referring to a non-existent map file: //# sourceMappingURL=shortcut-buttons-flatpickr.min.js.map I propose removing this line, and updating the addon to the latest version while I'm at it. -- You are receiving this mail because: You are watching all bug changes.

1 12

[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