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

[Bug 40431] New: Subject should be mandatory when using the free form to send an email to a patron
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40431 Bug ID: 40431 Summary: Subject should be mandatory when using the free form to send an email to a patron Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org With Bug 29393 the ability to send emails from patron details page was introduced. This is a great feature, but the subject should be a mandatory field. to reproduce: - go to a patron's details page - click on "Add message" in tools bar - choose "Email" in "Add a message for" - fill the body / message manually but leave the subject emty - Save - Check the message in the patrons notices cgi-bin/koha/members/notices.pl?borrowernumber=xxxxx -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 35688] New: RFID Envisionware Software Requires Static Page Title
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35688 Bug ID: 35688 Summary: RFID Envisionware Software Requires Static Page Title Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: eliana(a)flo.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When attempting to perform batch check-ins in Koha's circulation module, Envisionware's Staff Link software is automatically paused when it detects a change in page title. After submitting a check-in the page title changes to reflect the title of the item you're checking in. For example: Expected window: Check in › Circulation › Koha Actual window: Check in The killer department : › Circulation › Koha If the page title were to stay "Check in > Circulation > Koha" the Staff Link software would successfully check in multiple items (according to Envisionware). We've been able to successfully perform batch check outs because the page title stays static. Possibly related to bug #31512, but that bug didn't mention page titles, so I'm bringing it to the community's attention here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 40501] New: Create a warning when a notforloan status is given to a checked out item.
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40501 Bug ID: 40501 Summary: Create a warning when a notforloan status is given to a checked out item. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: alyssa.drake(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com There should be some kind of warning for staff when they assign a not for loan status to an item that is checked out. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 37891] New: Editing a notice's name having SMSSendDriver disabled causes notice to be listed twice
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37891 Bug ID: 37891 Summary: Editing a notice's name having SMSSendDriver disabled causes notice to be listed twice Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: david.roberts(a)ptfs-europe.com, david(a)davidnind.com, jonathan.druart(a)gmail.com, martin.renvoize(a)ptfs-europe.com, oleonard(a)myacpl.org, paul.derscheid(a)lmscloud.de 1) Visit notices and slips: <staff_url>/cgi-bin/koha/tools/letter.pl 2) Search for a notice code e.g. 'ILL_REQUEST_UPDATE'. 3) Notice only one result is returned. Click 'Edit'. 4) Edit the 'Name'. Click 'Save'. 5) Repeat 2. Notice two results are now returned. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 11591] runtime parameter for library groups
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11591 Phillip Berg <phillip.berg(a)mainlib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phillip.berg(a)mainlib.org --- Comment #3 from Phillip Berg <phillip.berg(a)mainlib.org> --- Yes, for sure having library groups as a parameter is extremely important for just about any multi-branch system. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 19532] New: Recalls for Koha
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19532 Bug ID: 19532 Summary: Recalls for Koha Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P3 Component: Staff Client Assignee: aleisha(a)catalyst.net.nz Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, liz(a)catalyst.net.nz Deadline: 2017-12-01 Preface: I know this will be quite an interesting feature for lots of people. Catalyst is doing a working proof of concept for this feature. The requirements we have given to Aleisha are firm, and we will not be scope creeping them. Additional features are welcome once this initial development is either accepted or supplanted by something else. That said, we welcome comment and suggestions on the patches we will attach here, and view this as a starting point instead of a complete solution. Expected scope of the feature to include: - Ability for borrowers to place a recall on a book from the OPAC results and detail, if it is checked out (question, do we offer to issue a recall if only one copy of say 3 is checked out?) - Ability for borrowers to see their requested recalls, and the when the book is expected to be returned back - An interface similar to holds for recalls, that alerts librarians that a book needs to go on the recall shelf (Recall for User, confirm or cancel) - An interface similar to holds waiting to show recalls that are currently on the shelf, and recalls that are requested but overdue, and ones that have expired and need to be reshelved. - A view in the intranet user interface for librarians to see a borrower's recalls (similar to holds) - Notices for borrower who has the recalled book on issue, to notify that the book's due date has changed and for the recaller, to let them know when the recalled item is ready for pick up. - Something in the circ rules that defines whether an item type/borrower category is allowed to place recalls on an item. - Sysprefs for "days from now that item is now due" and "how long do I let this recall languish on the recall shelf before reshelving" Current implementation notes: * DB: recalls table • DB: old_recalls table • notices: to user who has an item checked out that a recall request has been placed on, saying request has been made and due date has been updated (may use or build upon existing code from 17509) • notices: to user who made the recall request when it has been checked in, saying the item is awaiting pickup and must be picked up within X days (may use or build upon existing code from 17509) • OPAC: in checked out tab on user summary page, show your item has a recall placed on it, highlighting the new due date • OPAC: recall button under availability on record detail page and results page • OPAC: recalls tab on user summary page Per item type/borrower category combination: • circ rules: recall due date interval - what is the new due date of the item being recalled? How many days from the date of recall do we set the new due date? • circ rules: recall overdue fine - Do we have a special fine on an item that was recalled but not returned on time? (this may be a phase two feature) • circ rules: recall shelf time (how long can it be awaiting pickup before it needs to be reshelved) • circ rules OR syspref: do recalls automatically expire? (this may be a phase two feature) • circ reports: overdue recalls • circ reports: recalls awaiting pickup / recalls waiting over X days • circ reports: recalls queue • intranet: recalls tab on member detail page, showing recalls that the borrower has requested. • intranet: highlight on checkout and detail page items with a recall due date. • intranet: alert when checking in an item with a recall -- You are receiving this mail because: You are watching all bug changes.

1 1192

[Bug 11591] runtime parameter for library groups
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11591 Myka Kennedy Stephens <mkstephens(a)fosgail.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED CC| |mkstephens(a)fosgail.org Resolution|INVALID |--- --- Comment #2 from Myka Kennedy Stephens <mkstephens(a)fosgail.org> --- I'd like to reopen and clarify since I was about to submit a new bug for this. The reports module has several runtime parameters that can be used to easily pull a list of values for selecting when running a report. See https://koha-community.org/manual/latest/en/html/reports.html#runtime-param…. Library groups are not currently a runtime parameter. Because library groups are stored in the library_groups table instead of as an authorized value, there's currently no way to pull in a list of library groups to select from when running a report. The library staff member running the report needs to know their library's group code and type that into a text entry for any reports that need to pull data from all libraries that are within a library group. If library groups were added as a runtime parameter, similar to branches or item types, this could be called on in the report and would show up as a drop-down list. This would be a huge benefit to library consortiums and systems that have multiple groups of branches where reports would need to be run by group instead of by individual branch. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40172] New: Remove jQuery from js/fetch/http-client.js
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40172 Bug ID: 40172 Summary: Remove jQuery from js/fetch/http-client.js Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We do not really need jQuery, it can be replace with vanilla JavaScript. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 40330] New: Accessibility of the OPAC Labels
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40330 Bug ID: 40330 Summary: Accessibility of the OPAC Labels Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: nina.martinez(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org Provide labels to identify all form controls, including text fields, checkboxes, radio buttons, and drop-down menus. In most cases, this is done by using the <label> element. Labels need to describe the purpose of the form control. This section of the tutorial describes how to provide labels that are properly associated with form controls. A label and a form control should be associated with each other either implicitly or explicitly. Web browsers provide the label as a larger clickable area, for example, to select or activate the control. It also ensures that assistive technology can refer to the correct label when presenting a form control. We can improve the labelling of the OPAC to provide the label as a clickable area. https://www.w3.org/WAI/tutorials/forms/labels/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 40564] New: Preservation Home shouldn't be empty
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40564 Bug ID: 40564 Summary: Preservation Home shouldn't be empty Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Preservation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com It's disconcerting to arrive in the Preservation module and see a blank page - especially now all (most?) of the other module pages have something on them! Ideas: - get rid of the Home. Land directly on the Trains page. - display some kind of statistics dashboard: number of items in the waiting lists, list of open trains with mention of processing used and how many items are in them, link to closed trains. - have some kind of search: a train search and/or a processing search. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1