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

[Bug 29855] New: Add a repeated subfield with a MARC modification template
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '25

20 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29855 Bug ID: 29855 Summary: Add a repeated subfield with a MARC modification template Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It seems it is not possible to add a repeated subfield with MARC Modification template with the current options. Ex : it should be possible to create a 099$tBOOK field, then create an other $t (ex: $tCD) in the same 099 field (not in a new 099), to obtain 099$BOOK$tCD -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '25

20 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Martin Renvoize (ashimema) <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Hackfest -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35286] New: Replace GetPrintMessages with Koha::Notice::Messages->search
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '25

20 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35286 Bug ID: 35286 Summary: Replace GetPrintMessages with Koha::Notice::Messages->search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 C4::Letters::GetPrintMessages is a very basic wrapper around a simple SQL lookup. We could easily remove it and use Koha::Notice::Messages->search directly instead resulting in Koha::Notice::Message objects in the return. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 32429] New: With "Write off all" UseEmailReceipts sends emails for each, with "Write off selected" a digest
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '25

20 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32429 Bug ID: 32429 Summary: With "Write off all" UseEmailReceipts sends emails for each, with "Write off selected" a digest Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com If you are using UseEmailReceipts, an email is sent to the user as a receipt when fines are written off or paid. There is a difference in how the emails sent that should be fixed: * When you pay/write off a single fine, an email is sent for that line. * When you pay/write off multiple using "selected", one email is sent with all information about the selected lines. (nice and expected) * When you pay/write off all a single email is sent for each line. (unexpected, not nice) If multiple lines are paid or written off, this should always generate a single email about the transaction. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 39069] New: The 'Your lists' tabs should show both the user's private and public lists
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '25

20 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39069 Bug ID: 39069 Summary: The 'Your lists' tabs should show both the user's private and public lists Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists 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 In both the OPAC (opac-shelves.pl) and the staff client (virtualshelves/shelves.pl), the "Your lists" tab only shows your private lists. This can be confirmed by creating two lists and setting one to public and one to private. "Your lists" implies it would include all of the lists you own, not just the private ones. At the very least, it would be helpful if there were three tabs "Your private lists", "Your public lists", and "All public lists". In the staff client you can filter down to your own public lists in the "Public lists" tab via the owner column but in the OPAC there's not an easy way to do that. At scale, with hundreds of lists, if a patron marks their list 'public' then wants to change the settings on the list, they have to dig through the whole mess of public lists one a page at a time to find it. I suspect our public lists are partially in such a messy state because patrons and staff have created public lists in the past then completely forgotten about them since they don't show up in their 'Your lists'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 39375] New: About page accessible to low privileged staff users
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '25

19 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39375 Bug ID: 39375 Summary: About page accessible to low privileged staff users Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, anyone with staff interface access can visit the About page at about.pl. There's privileged information available via that interface -- This is something we seem to acknowledge in koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt: <p class="problem ret_datacorrupt">The item has not been checked in due to a configuration issue in your system. You must ask an administ rator to take a look at the <a href="/cgi-bin/koha/about.pl#sysinfo_panel">about page</a> and correct all errors shown on the "System information" tab</p> That said, koha-tmpl/intranet-tmpl/prog/en/modules/ill/ill-requests.tt says <div class="dialog message">ILL module configuration problem. Take a look at the <a href="/cgi-bin/koha/about.pl#sysinfo_panel">about page</a></div> So we should probably update ill-requests.tt to match returns.tt -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 39370] New: staff authentication (success or fail) should always be logged
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '25

19 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39370 Bug ID: 39370 Summary: staff authentication (success or fail) should always be logged Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: evelyn(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Regardless of the Authentication Logs being enabled in Koha, when a user of the category type "staff" attempts to authenticate, it should always be logged. Ideally the length of the session should also be stored, but that may add complexity (I'm happy to open a new bug for length of session if that's the preference, please just let me know). This would help for any future security questions for libraries that don't enable those authentication logs by default, and also assist in making audits more straightforward. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 13870] Add warnings about subscriptions and orders when deleting items
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '25

19 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13870 --- Comment #15 from Fridolin Somers <fridolin.somers(a)biblibre.com> --- Oupsy, tag a is not closed : + <td class="linked_order"> + [% IF linked_order.ordernumber %] + <a href="/cgi-bin/koha/acqui/basket.pl?basketno=[% linked_order.basket | uri %]" title="See basket details">[% linked_order.ordernumber | html %]<a> + [% ELSE %] + None + [% END %] + </td> + <td class="linked_subscription"> + [% IF linked_subscription %] + <a href="/cgi-bin/koha/serials/subscription-detail.pl?subscriptionid=[% linked_subscription | uri %]" title="Subscription id [% linked_subscription | html %]">Subscription details<a> + [% ELSE %] + None + [% END %] + </td> Should be </a> Also use <span>None</span> to ease translation -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10060] Allow adding a branch parameter to the web-based self check to indicate library its used at
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '25

19 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10060 --- Comment #44 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to David Cook from comment #43) > (In reply to Christopher Brannon from comment #41) > > Oh yeah. I remember that. This sounds like a nightmare to implement. I > > think there are less complicated ways to build this into Koha itself and > > make it easier to implement. > > It depends on how your Koha is managed. In theory, it shouldn't be a big > drama. In some ways, it could actually offer a lot more control and > security. > > But I agree about having a simpler/more maintainable way of doing it. > > Unfortunately, since this work is unsponsored, it falls lower than the > sponsored priorities, but this is definitely on my radar. Well, I have to go the more complicated route on this for the time being, but I do think this is basic setup for most self checks - being able to configure to a specific branch and automatically login. I'd be pressed to find a self check out there that requires these hoops. Anything that requires more than 1 person to configure and setup, especially something this basic, is inefficient in my book. At least it is here for someone to consider. Thanks for having it on your radar. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35798] New: Record overlay rules are needed for Authorities
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '25

19 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35798 Bug ID: 35798 Summary: Record overlay rules are needed for Authorities 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: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The record overlay rules seem to only work with bibliographic records. It would be nice to expand this tool to include Authorities. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2