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

[Bug 31228] New: Fix Coce JavaScript to hide single-pixel cover images in both the staff client detail and results pages
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31228 Bug ID: 31228 Summary: Fix Coce JavaScript to hide single-pixel cover images in both the staff client detail and results pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org As reported by Jonathan in bug 31217 koha-tmpl/intranet-tmpl/js/coce.js hides the coce-coverimg class. - In koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/results.tt coce-coverimg is a class. - In koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt coce-coverimg is an ID, not a class. As ID's are more specific, coce-coverimg should be changed to an ID in koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/results.tt And koha-tmpl/intranet-tmpl/js/coce.js should be changed to: $("#coce-coverimg").remove(); -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 31222] New: DBIC queries for batch mod can be very large
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31222 Bug ID: 31222 Summary: DBIC queries for batch mod can be very large Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We had an issue with mysql logging for a site doing many batch modifications. The object search is currently: Koha::Items->search({ barcode => \@contentlist } Which generate code like: barcode = 1 OR barcode = 2 OR barcode = 3 .... This can get quite large We can reduce the query size by using -in: Koha::Items->search({ barcode => { -in => \@contentlist } } Which generates code like: barcode in ( 1, 2, 3 ) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 31217] New: Fix Coce JavaScript to hide single-pixel cover images in the OPAC lightbox gallery
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31217 Bug ID: 31217 Summary: Fix Coce JavaScript to hide single-pixel cover images in the OPAC lightbox gallery 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The shift to using a lightbox gallery to display cover images in the detail pages of the OPAC has stopped Coce from hiding 1-pixel cover images. This line ( https://github.com/Koha-Community/Koha/blob/0177b88eb33d398da4eb5ffb6344226… ) should hide the coce-coverimg box from the OPAC for 1-pixel images. However, coce-coverimg is an id, not a class, in the OPAC detail page, therefore, this JavaScript does not hide anything in the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 30984] New: Action logs should log the cronjob script name that generated the given log
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30984 Bug ID: 30984 Summary: Action logs should log the cronjob script name that generated the given log Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When something is changed by a cronjob, and that entity is logged via action logs, we can know what changed, and that it was via a cronjob, but we cannot necessarily know which cronjob made that change. The closest we can come is to find the action logs for the cronjob module which ran before the change which is by no means reliable assuming the CronLog is even enabled. We should add a new column to action logs to store the name of the script ran for any action logs where the interface is "cron". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 30797] New: Subfields linked to the dateaccessioned.pl value builder on addbiblio.pl throw a JS error
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30797 Bug ID: 30797 Summary: Subfields linked to the dateaccessioned.pl value builder on addbiblio.pl throw a JS error 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl By default the dateaccessioned.pl cataloguing value builder is linked to the 952$d subfield. When the additem.pl page loads the 952$d is pre-populated with today's date. However, some libraries link the dateaccessioned.pl cataloguing value builder plugin to subfields displayed in the addbiblio.pl (biblio cataloguing page). For example, 902$d. When you load the addbiblio.pl page those subfields are not pre-populated with today's date. Instead in the console you get the following JavaScript error: Uncaught TypeError: $(...).flatpickr is not a function -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 30499] New: Keyboard shortcuts broken on several pages
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30499 Bug ID: 30499 Summary: Keyboard shortcuts broken on several pages Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Keyboard shortcuts fro catalog search, check in and renew should be following: 1) Alt-q for catalog search 2) Alt-r for check in 3) Alt-w for renew However on some of the pages shortcuts get mixed up: 1) Alt-w for catalog search 2) Alt-q for check in 3) Alt-r for renew Problem occurs at least on the following pages: circulation-home.pl circulation.pl renew.pl set-library.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 30468] New: koha-mysql does not honor Koha's timezone setting
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30468 Bug ID: 30468 Summary: koha-mysql does not honor Koha's timezone setting Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If I run a query like "SELECT NOW()" from a koha report, I will get a different answer than if I had run it from koha-mysql. In Koha, we set the timezone for each database connection. However, koha-mysql does not do this, so instead we are left using the default timezone of the database. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 30028] New: Patron message delete confirmation untranslatable
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30028 Bug ID: 30028 Summary: Patron message delete confirmation untranslatable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr When we delete a patron message, there is a confirmation message that is untranslatable. It may be because it's a browser message or something, rather than a Koha modal? To get to this message: 1) Add a message to a patron account from your own branch (or make sure AllowAllMessageDeletion is on) 2) Click "Delete" next to the message --> a confirmation message appears "Are you sure you want to delete this message? This cannot be undone." with options "Cancel" and "OK". This sentence is in koha-tmpl/intranet-tmpl/prog/en/includes/patron_messages.inc but it is not in any .po file. Caroline -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43

[Bug 29782] New: Missing entries for display locations in HTML customizations
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29782 Bug ID: 29782 Summary: Missing entries for display locations in HTML customizations 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: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org In Koha menu "Tools > HTML customizations" it is possible to create new entries for various display locations. Given the Koha instance has two languages, "English (en)" and "Deutsch Deutschland (de-DE)" an entry will show three tabs: * Default * English (en) * Deutsch Deutschland (de-DE) If you fill just text into the "Content" field of the actual language tabs you will be prompted with a popup saying "Please specify a title for Default". In fact I don't know why such a "title" is needed at all (see also bug 29515), but OK I fill one in, but do not fill any content into the "Content" field of the Default tab because I don't want or need no default content. Now it's possible to save. The content of tab "English (en)" and "Deutsch Deutschland (de-DE)" will show up in the OPAC when changing to the respective language. But Koha menu "Tools > HTML customizations" will NOT show any entry for the display location you have created! So you are not able to change its content or delete it. The problem doesn't happen if you enter text in the "Content" field of the Default tab. This means 1. It is not clear why the default tab is mandatory. 2. It shouldn't be possible to save the entry for a display location without entering text in the "Content" field of the Default tab if the consequence is that there won't be no entry for the display location in the end. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 29434] New: In UNIMARC instances, the authority finder uses MARC21 relationship codes
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29434 Bug ID: 29434 Summary: In UNIMARC instances, the authority finder uses MARC21 relationship codes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org Background information ---------------------- As per the IFLA UNIMARC Manual for Authorities format [1], the 5-- Functional Block (a.k.a. Related Access Point Block) "contains related authorized access points from which a reference is to be made to see also the access point of the record". To put it simply, this allows for linking authority records with other authority records in order to form, for example, broader/narrower term hierarchies (see sreenshots 1 and 2). Control Subfield $5 ("Relationship Control" in IFLA speak, whereas the UNIMARC Authorities framework in Koha uses the term "Tracing Control") is key to this idea, because it is used to store a single-character value that denotes the type of relationship between the authorities being linked. The actual problem ------------------ When using the authority finder plugin (authorities/auth_finder.pl), you can pick an entry from the 'Special relationship:' dropdown menu in order to set the relationship between authorities. However, in UNIMARC instances the relationship codes listed are those for MARC21 [2] (see screenshots 3 and 4). The correct codes for UNIMARC are listed in pages 93-94 of the IFLA UNIMARC Manual for Authorities. [1] https://repository.ifla.org/handle/123456789/861 [2] https://www.loc.gov/marc/authority/adtracing.html -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22