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

[Bug 8838] Digest option for HOLD notice
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8838 --- Comment #34 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 155488 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=155488&action=e… Bug 8838: Make db update idempotent -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8838] Digest option for HOLD notice
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8838 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #154969|0 |1 is obsolete| | Attachment #155415|0 |1 is obsolete| | --- Comment #33 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 155487 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=155487&action=e… Bug 8838: Add digest option for HOLD notice Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Restart all the things! 4) Enable the new digest option for "Hold filled" messages 5) Trap multiple holds for a patron 6) Note a single notices is generated for all the trapped holds! Signed-off-by: George Williams <george(a)nekls.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34170] New: Ability to add record/order line specific credits
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34170 Bug ID: 34170 Summary: Ability to add record/order line specific credits Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org With invoice adjustments it's possible to enter negative values to indicate a credit (see bug 19166). The problem is, that while these are linked to a specific invoice, there is no way to link an invoice adjustment to a specific order line or record. The credits might be granted after the initial invoice, because an order has been cancelled mid-term or because of a special discount that was applied. In order to be able to calculate the correct cost in that case, we need to be able to link it to a record or order line. One way this could be achieved would be to allow negative prices on ordering. At the moment when you enter a negative list price, it's stored correctly into the database, but won't be used correctly for calculations and the minus signs is lost in display. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 32275] New: Fill blank record in basic editor using ISBN with Google Books API
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32275 Bug ID: 32275 Summary: Fill blank record in basic editor using ISBN with Google Books API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 14242 added the ability to fill the OPAC purchase suggestion form with data from the Google Books API by entering an ISBN. My catalogers would be ecstatic if that functionality could be used to populate the relevant fields on a blank bib record in the basic editor as a starting point for creating records from scratch. This would save a substantial amount of time entering data. Logical mappings would be: volumeInfo.title > 245$a volumeInfo.subtitle > 245$b volumeInfo.authors > 100$a volumeInfo.publisher > 264$a volumeInfo.publishedDate > 264$c volumeInfo.pageCount > 300$a volumeInfo.dimensions.height > 300$c volumeInfo.description > 500$a -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 34751] New: xss reflected in koha 23.05
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34751 Bug ID: 34751 Summary: xss reflected in koha 23.05 Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: angelmetz05(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org To see the PoC video you just have to go to this link The video is private, only the link can be accessed https://youtu.be/b5107YkpgaM To install the latest version of koha use these resources, which may be good for you in case of -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 18161] New: Option to completely disable advance notice on loans with auto renewal
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18161 Bug ID: 18161 Summary: Option to completely disable advance notice on loans with auto renewal Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org Some background. In our current library system, we use long loans (loans with a guaranteed minimum due date, but a much much longer hard due date), with a recall function. This is only in use for parts of the content. Koha does not support this, so we're looking at using auto renewal as a method to give a reasonable resemblance of long loans. We also want advance notices to be sent when the due date is about to arrive, but having an advance notice and then an automatic renewal shortly after will produce a multitude of notices that will be considered as faulty by the end user. The suggested solution to this is an option to simply disable advance notices for loans where auto renewal is active. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 18441] New: add primary, foreign keys to statistics table
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18441 Bug ID: 18441 Summary: add primary, foreign keys to statistics table 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: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I think that the primary key would be useful for Bug 9717 'localuse recorded for holds/transfers' -- we could record 'localuse' when the item is checked in, and then update the statistics record to 'holdcaptured' or 'transferred' if the check-in captures a hold or completes a branch transfer. The statistics table is *very* slow to join borrowers or items against, because borrowernumber and itemnumber are not indexed. It also caused a 12 hour run of updatedatabase on site that had a large statistics table, when running the upgrade that fixed bug 14598 (itemtype is not set on statistics by C4::Circulation::AddReturn). This occurred on the 16.06.00.039 update. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 18265] New: Followup to Buuug 17196. deletedbiblio_metadata is not used. biblioitemnumber was forgot.
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18265 Bug ID: 18265 Summary: Followup to Buuug 17196. deletedbiblio_metadata is not used. biblioitemnumber was forgot. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Exhibit 1: The MARCXML is lost when the biblio is deleted because the values in biblio_metadata-table from biblioitems-table are never moved to deletedbiblio_metadata-table. Previously the marcxml was preserved in the oldbiblioitems-table This is a challenge for gathering statistics For example item has been ordered, received, and removed from collection during the statistics period Information in marcxml is needed to accurately categorize the item Exhibit 2: [15:22:38] <kivilahtio> also. In Koha there once was a great idea that one biblio-entry can have multiple biblioitems [15:22:45] <kivilahtio> and the marcxml was tied to the biblioitems-table [15:23:11] <kivilahtio> this is a nice idea, but nobdy really cared for it and now biblionumber and biblioitemnumber are used interchangeably [15:23:22] <kivilahtio> except when they get out of sync during a data migration [15:23:41] <kivilahtio> then things start to work really interestingly [15:23:47] <kivilahtio> but the point is [15:23:57] <kivilahtio> biblio_metadata has a biblionumber-column [15:24:15] <kivilahtio> shouldn't it have a biblioitemnumber-column, just for old time's sake? In the biblioitems-table we had marcxml. primary keyed with biblioitemnumber. Now the marcxml is moved to biblio_metadata and the foreign key reference was simplified to biblionumber. This makes the existing FRBR-bug worse. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 16327] New: Running build_oai_sets.pl with embed items option should consider every item in a biblio
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16327 Bug ID: 16327 Summary: Running build_oai_sets.pl with embed items option should consider every item in a biblio Change sponsored?: --- Product: Koha Version: 3.22 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: pjamorim91(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org After configuring a mapping for an oai set which uses item fields, the build_oai_sets.pl must be run with the -i flag, to embed item data in a biblio. The bug is that it's only considering the first item (by itemnumber) of the biblio, not all the items in it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 18524] New: Disable barcode field and submit button when a transfer is found
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18524 Bug ID: 18524 Summary: Disable barcode field and submit button when a transfer is found Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Similar to the actions taken on Bug 11360, when scanning in returns, it can be easy to miss a transfer message due to the fact that the barcode and submit are still active and the barcode field is focused on. When a librarian is quickly scanning in returns, it is easy to scan another item and pass over the form to accept the transfer, which is equivalent to clicking the "ignore" button. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1