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

[Bug 22343] New: Add SMTP settings
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '22

24 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343 Bug ID: 22343 Summary: Add SMTP settings Change sponsored?: --- Product: Koha Version: 18.11 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: fv(a)spots.school QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I would like to add fields to Koha>Administration for SMTP settings to make it easy to use external mail servers without having to edit files on the server. I am thinking that we could edit koha/C4/Letters.pm adding $mail{smtp} = 'my.mail.server'; I am not sure how the settings are passed to Letters.pm however. What does everyone else think? Is this the right way to do it? Thank you! FV -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 351

[Bug 28659] New: Allow Fast Cataloging to skip duplicate check
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '22

24 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28659 Bug ID: 28659 Summary: Allow Fast Cataloging to skip duplicate check 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 To recreate: - Have a bib in your system with the title "E Street Shuffle" - Confirm you do not have barcode "XXX" in your system - Have Fast Cataloging enabled - Try to check out barcode "XXX" to a patron, get notice that barcode does not exist, follow link to Fast Cataloging - In your Fast Add record, enter title "E Street Shuffle" - click Save, get a popup asking if your new record is a duplicate of the existing record - click "Yes, View Existing Items" - Koha takes you to the existing bib, where you can add a new item (assuming you have permission) - that item will not maintain the XXX barcode and will not follow any of the other settings in one's Fast Add framework I don't expect all libraries to agree on how this should work. It'd be great to have a system preference with which to set whether or not to do that dupe check at all on fast add. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[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

[Bug 28864] New: The patron search results in the Patron card creator doesn't seem to use PatronsPerPage syspref
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '22

23 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28864 Bug ID: 28864 Summary: The patron search results in the Patron card creator doesn't seem to use PatronsPerPage syspref 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: michael.hafen(a)washk12.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The patron search results in the patron card creator card batch doesn't include the value of the PatronsPerPage system preference in the per page drop down, which means it isn't using the system preference. Also, on the Patrons page, the patron search includes the PatronsPerPage value, but doesn't use it as the default. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 41