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

[Bug 30755] New: too_soon should not be counted as an error in autorenewals
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30755 Bug ID: 30755 Summary: too_soon should not be counted as an error in autorenewals Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 30222 When working through the notice for autorenewals digest I found that the too_soon error gets counted, and displayed, in the errors section of the notice. I don't believe it should be, as it's just a function of the system rather than a hard un-recoverable error that the user needs to know about. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30222 [Bug 30222] Auto_renew_digest still sends every day when renewals are not allowed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 14911] Item search: Display additional 245 subfields in search results
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14911 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david(a)davidnind.com --- Comment #11 from David Nind <david(a)davidnind.com> --- Testing notes (using KTD): 1. Edit the framework used for the items so 245$n and 245$p are visible in the editor. 2. To run misc/batchRebuildBiblioTables.pl -c successfully, I needed to edit record 72 to remove the duplicate 010 field (see bug 30896). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14911] Item search: Display additional 245 subfields in search results
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14911 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #144511|0 |1 is obsolete| | --- Comment #10 from David Nind <david(a)davidnind.com> --- Created attachment 144529 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=144529&action=e… Bug 14911: Add 245 fields to itemsearch title column via biblio-title.inc To test: 1. Have some records that have these 245 fields: -Title 245$a -Subtitle 245$b -Medium 245$h -Part number 245$n -Part name 245$p Note: IN KTD I have to run batchRebuildBiblioTables.pl -c 2. Apply patch and do an item search that will turn up items with the 245 fields lists above 3. Notice that those subfields are now included in the title column. Signed-off-by: David Nind <david(a)davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14911] Item search: Display additional 245 subfields in search results
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14911 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32273] New: Unable to set author subfields in Elastic search configuration
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32273 Bug ID: 32273 Summary: Unable to set author subfields in Elastic search configuration Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com In a situation in which you have 2 authors that are both named Barnaby Conrad but one has the authorized name of dates 1922-2013 and the other has III, 1952-. If you click on one of their names for a search from a record where they are the author, results for both show up as the search just does au:"Conrad, Barnaby,". Configuring subfields in the Elastic search do not resolve the problem. Current work around is to enable 'UseAuthoritiesForTracing.' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 13911] Add support for Internet Archive BookReader
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13911 Serhij Dubyk <dubyk(a)ukr.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dubyk(a)ukr.net -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32074] New: Edit vendor has a floating toolbar, but still an additional save button at the bottom
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32074 Bug ID: 32074 Summary: Edit vendor has a floating toolbar, but still an additional save button at the bottom 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org That's a small inconsistency with other forms having the floating toolbar. On the edit vendor form, there is also another save button at the bottom. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 10662] Build OAI-PMH Harvesting Client
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 --- Comment #317 from David Cook <dcook(a)prosentient.com.au> --- Occasionally I think about how I could do an OAI-PMH harvester plugin, but the tough part is that the harvester would need extra database tables, and I think having a plugin changing the database schema is not a great idea (or even possible depending on your database permissions). I suppose a person could take the OAI-PMH repository URL and the OAI-PMH record identifier, then hash them together, and then store that on a file system as a file. The content of that file could then contain additional data (like the Koha biblionumber). Of course, writing a lot of files to the same directory can be problematic, but Fedora Commons has already done some math on that and has recommended pair-tree patterns for creating an optimized sub-folder structure. -- I think that would just leave the need for a "koha-plugin" command that can invoke a particular plugin from the command line. A sysadmin could then schedule that whenever. Alternatively, one could use the "cronjob_nightly" Koha plugin hook. -- It wouldn't be all things to all people, but it would be a minimum viable OAI-PMH harvester... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10662] Build OAI-PMH Harvesting Client
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 --- Comment #316 from David Cook <dcook(a)prosentient.com.au> --- Sonia, do you have any updates on KohaLA is going with OAI-PMH harvesting? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10662] Build OAI-PMH Harvesting Client
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '22

09 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 --- Comment #315 from David Cook <dcook(a)prosentient.com.au> --- I just played a bit with the MarcEdit OAI-PMH tool. It can download OAI-PMH data, transform it, and save it to a local file. If you use the Windows Task Scheduler, you can also schedule this task. The problem I see is that you end up with MARC files that Koha won't be able to necessarily differentiate. DSpace's OAI-PMH harvester and my OAI-PMH harvesters all track the local system identifier against the OAI-PMH identifier, so it keeps a linkage between the upstream and downstream systems, so that updates and deletions are always perfectly matched up. Technically, you could probably write a crosswalk for MarcEdit that saves the OAI-PMH identifier and OAI-PMH repository URL into a custom field, so you could use it with Koha's record matching rules, but you'd have to make sure that custom field is indexed... -- You are receiving this mail because: You are watching all bug changes.

1 0