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

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '25

20 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 Alex Buckley <alexbuckley(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexbuckley(a)catalyst.net.nz --- Comment #58 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- not backporting to 24.05.x unless requested - dependency not in 24.05 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35421] New: Is "A guarantor cannot be a guarantee." still correct?
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '25

20 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35421 Bug ID: 35421 Summary: Is "A guarantor cannot be a guarantee." still correct? 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 With the ability to have adults guarantee for adults, I believe the above might no longer be true. Found while translating in koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt:190 -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '25

20 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 Irene <i.tortorella(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i.tortorella(a)arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '25

20 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 --- Comment #15 from Helen Jones <h.jones(a)ghil.ac.uk> --- Thank you, Heather! That describes the different approaches to bound-withs very well. This was the workflow for bound-withs that I used to use (Dynix/Voyager/Millennium/Sierra): 1. Create a completely standard bibliographic record for the first title [title A] in the bound-with volume. Add 501 Bound with: Title B / by author 2 -- Title C / by author 3. Add 590 Item No. x in classmark. $5 library code Add an item record with the classmark and barcode 2. Create bibliographic records for titles B and C. Do not add an item. 3. Using the bib record numbers of the bib records for titles B and C, link the item from title A to the bib records for titles B and C. And that's it. No parent record, no hierarchy. The item appears with each bib record just as it usually would for a non-bound-with bib-item record pair. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '25

19 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 Lauren Denny <lauren_denny(a)sil.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lauren_denny(a)sil.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '25

19 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 Heather <flyingendpaper(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |flyingendpaper(a)gmail.com --- Comment #14 from Heather <flyingendpaper(a)gmail.com> --- This feature would be completely different from analytics--analytics have hierarchical relationships, those of "parent-child." A bound-with feature in most systems simply links an item to multiple bib records and *doesn't require* a "parent record" for the entire entity--analytics require a parent record for the child records. "Bound with" bib records would be like members of a team; all the bibs created for the one physical entity are equal, and the cataloging standards pre-RDA use a "Bound with" note explaining the relationship. It's easier cataloging, too, because catalog records may exist for the items which one library has all bound together, so they can be copy cataloged and the "bound with" note inserted. Creating a parent record and then using analytical relationships creates a lot more work, usually, than simply copy cataloging existing cataloging for the titles in the physical item, and then being able to link an item record to all the bibs, because a "bound with" is usually a unique physical items only held by one library. I know this sort of "bound with" workflow is difficult to describe to those who've only worked with Koha, and may not seem easier to people who understand linking entry fields & relationships, but for libraries that find themselves with a physical volume containing lots of bound together small titles, just copy cataloging some or all of them & then linking one item to all of the bibs is almost always a faster & easier cataloging operation than locally creating parent-child relationship records. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '25

19 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39172 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39172 [Bug 39172] Merging records no longer compares side by side -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36810] New: Resend button for notices being hidden by CSS and never unhidden
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '25

19 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36810 Bug ID: 36810 Summary: Resend button for notices being hidden by CSS and never unhidden Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, julian.maurice(a)biblibre.com, katrin.fischer(a)bsz-bw.de, kyle(a)bywatersolutions.com, lari.taskula(a)hypernova.fi, mtj(a)kohaaloha.com, nick(a)bywatersolutions.com, testopia(a)bugs.koha-community.org, veron(a)veron.ch Depends on: 11274, 12426, 18439 +++ This bug was initially created as a clone of Bug #18439 +++ To recreate: Enable EnhancedMessagingPreferences Ensure you have some sent or failed notices View notices tab and don't see a 'resend' button Inspect the status column, note a hidden for containing the 'resend' button Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11274 [Bug 11274] Sent Notices Tab Not Working Correctly https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12426 [Bug 12426] Allow resending of emails from the notices tab in the patron account https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18439 [Bug 18439] Resend button for notices being hidden by CSS and never unhidden -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '25

19 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 Helen Jones <h.jones(a)ghil.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |h.jones(a)ghil.ac.uk --- Comment #13 from Helen Jones <h.jones(a)ghil.ac.uk> --- I have been struggling with bound-withs in Koha. The systems that I have worked with previously had a function whereby you could attach multiple bib records to one item record. The item displayed with each bib record, so if the item was borrowed, the fact that it was on loan was immediately obvious no matter which bib record you were looking at. If there is only one item, the unique barcode is not a problem. Could this functionality be developed in Koha? From my point of view, it would solve all the issues that I have with the current workflow: 1. The item is not displayed in the OPAC with the bib records for the subordinate items, which is baffling to anyone actually trying to find the publication (this is in Bugzilla but does not seem to have been solved: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29606) 2. We are part of Library Hub Discover (UK) and there, the subordinate records do not appear at all 3. Creating a host record for unrelated items is often quite difficult if the items are not thematically linked You can of course squeeze everything into one record with lavish usage of 505 and 700 + $t but if you have a lot of items in the bound-with, records like this can quickly become very messy. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39168] New: Add an option to use a report to writeoff_debt
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '25

19 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39168 Bug ID: 39168 Summary: Add an option to use a report to writeoff_debt Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be really helpful for libraries to have the ability to add a report ID to batch waive fines using writeoff_debt. The specific use case would be for libraries who wants to check the report prior to running the script. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0