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

[Bug 29655] New: Email sender name setting
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29655 Bug ID: 29655 Summary: Email sender name setting Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: resetka.bedi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be nice if the name of the library, for example, was part of the email notifications in addition to KohaAdminEmailAddress. This procedure is not possible in the current version: https://wiki.koha-community.org/wiki/Adding_Custom_name_to_the_%27From%27_f… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 29090] New: Patron card creator has a bug when generating batches
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29090 Bug ID: 29090 Summary: Patron card creator has a bug when generating batches Change sponsored?: --- Product: Koha Version: 21.05 Hardware: PC OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: eliza.allison64(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 125182 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=125182&action=e… screenshot of patron library cards When creating a new batch of patron library cards, underneath the barcode, there is a line obstructing the card number saying "HASH(0X55d6.....)". I'm not sure how to remove it. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 29423] New: link of opac-detail.pl use biblioitemnumber
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29423 Bug ID: 29423 Summary: link of opac-detail.pl use biblioitemnumber Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: rcoelho(a)net.ipl.pt QA Contact: testopia(a)bugs.koha-community.org Hi. We found that in some situations when we click on a link instead of the correct record appearing, another record appears. After some analysis I found that for this record the biblioitemnumber is different from the biblionumber. When the link is built instead of placing the biblionumber, the biblioitemnumber is placed generating the error. How can I put the biblionumber in the construction of the link to the record detail? -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 28925] New: OPAC checkout history is not accessing the set language
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28925 Bug ID: 28925 Summary: OPAC checkout history is not accessing the set language Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org OpacNav is still in the system preferences (yet to be moved to Tools -> Notices) so in the meantime we've done a bit of hacky work to make our OpacNav translateable. We changed this line in koha-tmpl/opac-tmpl/bootstrap/en/includes/navigation.inc: <div id="opacnav">[% OpacNav | $raw %]</div> to: <div id="opacnav">[% OpacNav | eval %]</div> so that it would render Template Toolkit in OpacNav. Then, in OpacNav, we added some code like: [% IF lang == 'mi-NZ' %] Show navigation in te reo Māori [% ELSE %] Show navigation in English [% END %] This seems to work most everywhere in the OPAC, except for the user's checkout history. When printing [% lang %], it looks like $lang is set to default, rather than any of the languages we have installed. $lang should be set to the installed and selected language. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 29451] New: Merging records and authorities - log details for the delete action so it could be recreated
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29451 Bug ID: 29451 Summary: Merging records and authorities - log details for the delete action so it could be recreated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When logging is enabled for cataloging (CataloguingLog) and authorities (AuthoritiesLog), no details are shown for the deleted record or authority. The logs record a delete (with no details) and a modify entry for the merged item (with details). When merging records and authorities it would be good to have some of these available (depending on how complex they are to do): i) show for the log action that the delete and modify actions were as a result of a merge, not a standard deletion or modification, for example: Delete (merge), Modify (merge) ii) record the details in the log of the deleted item (just before it was deleted) so it could be restored or recreated (for example: if it was accidentally merged) iii) have a compare function (see bugs listed below) iv) have an undo merge function See this Twitter thread for more details: https://twitter.com/elafrula/status/1457650198939897856 Other bugs I could see which have some elements of this: * Bug 10417 - Add table to keep deleted authorities * Bug 26207 - Compare values of system preference log entries * Bug 26736 - Compare values of reports log entries * Bug 14233 - Add logging support to notices and slips management * Bug 28714 - Bib record change tracking action log -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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