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

[Bug 29045] New: Public Lists do not sort alphabetically as expected
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29045 Bug ID: 29045 Summary: Public Lists do not sort alphabetically as expected Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 124943 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=124943&action=e… Failed sorting of public list. When viewing the table with public lists, the individual lists do not automatically descend alphabetically as expected. When clicking on the arrow to sort the list, the list reorders but is also not alphabetical as expected. (see the pre and post sort image). It looks like the lists default to appear in order of creation date, but even then it should sort alphabetically when the arrow is clicked in the List Name column. Clicking the arrow to sort the List Name column a second and third time further orders the list in what appears to be a random order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 28069] New: Can't sort lists on 'Contents'
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28069 Bug ID: 28069 Summary: Can't sort lists on 'Contents' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On staff client, it's not possible to sort lists by 'Contents'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 30365] New: editing existing records that are greater than 100 characters long brings up the textarea method of input
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30365 Bug ID: 30365 Summary: editing existing records that are greater than 100 characters long brings up the textarea method of input Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: courtenay.johnson(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Cataloging individual records using Frameworks. Using version 21.05.03 running on Ubuntu. Looking at the adddbiblio.pl code, (near line 445) I see that editing existing records that are greater than 100 characters long brings up the textarea method of input, and newlines are accepted. However if the existing shorter input, or any new input is forced to a single line text box and \n are ignored. My point is it is ridiculous that accepting of \n from the keyboard is acceptable during some conditions, but not others. As I have submitted in a bug report 30364 I also wish that the behaviour of the HTML input field should not vary if a plugin is present. I propose that a new flag in the framework should determine if a subfield will use the HTML input text or the textarea for input, and thus whether or not \n is accepted, and this should allow \n in input of any length up to the maximum length usually 9999 which currently does not seem to be used. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 28329] New: The items callnumber will reappear when editing the item if originally blanked out
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28329 Bug ID: 28329 Summary: The items callnumber will reappear when editing the item if originally blanked out Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Set system preference, itemcallnumber, to 082ab or something similar to pull the call number from the bib record into the item holding. 2. Create item and remove the call number. 3. See that the callnumber has been removed in the item. 4. Edit this same item and see that the call number is back (pulled again from the marc record following the itemcallnumber sys pref). This is an issue if a library does not want a callnumber in some records but does for others. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 28712] New: Printed slips for fees come up empty if no notice is defined for the user's preferred language
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28712 Bug ID: 28712 Summary: Printed slips for fees come up empty if no notice is defined for the user's preferred language Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When printing slips for account actions and using the TanslatedNotices feature, there is no fallback to "default", when there is not notice template for the user's preferred language. See bug 28487 for a similar instance of this. To test: - Create a manual fee of any kind - Pay it - Click on "print" and confirm the slip comes up with content - Turn on TranslateNotices system preference - Repeat "print" action - the slip should still print - Edit your patron and set a language other than "default" - Repeat print, the page now comes up empty I think this is quite hard to understand track down for users to figure out, so while there is a workaround (setting the notices) we should really fix it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 26300] New: Error in ISBD view in OPAC
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26300 Bug ID: 26300 Summary: Error in ISBD view in OPAC Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hblancoca(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org when I try to connect in OPAC to https://catalogo.urosario.edu.co/cgi-bin/koha/opac-ISBDdetail.pl?biblionumb… View this error Software error: The method Koha::Item->itemtype is not covered by tests! Trace begun at /usr/share/koha/lib/Koha/Object.pm line 780 Koha::Object::AUTOLOAD('Koha::Item=HASH(0x564b373f19d0)') called at /usr/share/koha/lib/Koha/Item.pm line 478 Koha::Item::__ANON__ at /usr/share/koha/lib/Koha/Item.pm line 478 Koha::Item::hidden_in_opac('Koha::Item=HASH(0x564b373f19d0)', 'HASH(0x564b3659bcf0)') called at /usr/share/koha/lib/Koha/Biblio.pm line 258 Koha::Biblio::__ANON__ at /usr/share/koha/lib/Koha/Biblio.pm line 258 Koha::Biblio::hidden_in_opac('Koha::Biblio=HASH(0x564b35160c78)', 'HASH(0x564b37636218)') called at /usr/share/koha/opac/cgi-bin/opac/opac-ISBDdetail.pl line 91 But in staff all works fine -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 30827] New: Autobarcode discards leading zero
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30827 Bug ID: 30827 Summary: Autobarcode discards leading zero Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you set autobarcode to "generated in the form 1,2,3," Koha will find the largest numeric barcode in your system and add 1. However, if your largest numeric barcode has leading zeros, those will not be maintained in your new item. So if the current highest barcode is "09000," the next barcode generated will be "9001." Apparently we fixed this on bug 5681 way back in 2011, but it has since regressed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 27426] New: Plugin barcode must keep leading zeros
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27426 Bug ID: 27426 Summary: Plugin barcode must keep leading zeros Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If autoBarcode is set to incremental, we are generating the next barcode adding 1, but casting to integer. If you have "0001" "0002" the next barcode will be "3". Should not we keep the leading zeros and generate "0003" instead? -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 30900] New: "Error searching for analytic records"
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30900 Bug ID: 30900 Summary: "Error searching for analytic records" Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Created attachment 135680 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=135680&action=e… Screenshot of error message On 21.11.05 using Zebra, this message is displayed between the "New", "Edit" etc buttons, and the title of *some* records: There was an error searching for analytic records, please see the logs for details. The logs say: ==> /var/log/koha/koha/plack-error.log <== CCL parsing error (10014) Unknown qualifier ZOOM for query: Host-item=(Psychology and law =) at /usr/share/koha/lib/C4/Search.pm line 242. Warning from simple_search_compat: 'CCL parsing error (10014) Unknown qualifier ZOOM' at /usr/share/koha/lib/Koha/Biblio.pm line 540. For a while I thought the message only displayed for records with a trailing colon in 245$a, but on looking at more records that does not seem to be the case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 6419] Add customizable areas to intranet home pages
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6419 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0