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

[Bug 29710] New: Add cancellation reason to OPAC holds history
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '25

01 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29710 Bug ID: 29710 Summary: Add cancellation reason to OPAC holds history Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: axelle.clarisse(a)univ-amu.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 26281 adds the cancellation reason to the holds history page in the staff interface. It would be useful to have the same dev on the holds history page on the OPAC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 29918] New: Batch Patron Modification - Creation of "Add Number of Days" to Expiry date field
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29918 Bug ID: 29918 Summary: Batch Patron Modification - Creation of "Add Number of Days" to Expiry date field Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org It would be useful to have the Batch Patron Modification "Expiry Date" field have the option to either set a hard date or "Or add number of days:", as you do with the Batch Extend Due Dates function. Use Case: This came about from adjusting 28,500 accounts this week due to COVID closures. I had to manually adjust the dates in batches of 1000 to ensure that I didn't "over-crowd" one day with too many expiring cards. Had I been able to say extend "200 days" for each account, the dispersal of accounts could have been more randomized. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[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 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 35639] New: Long SMS messages are not sent if they exceed the character limitation of the messaging driver
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35639 Bug ID: 35639 Summary: Long SMS messages are not sent if they exceed the character limitation of the messaging driver 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: emily-rose.francoeur(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org Some messages that were supposed to be sent via SMS are not delivered because SMS has a character limitation. Since this limitation also depends on the driver used with SMS::Send, it would be good to have a system preference to choose the message length. This way, even messages that are too long could still be sent (but they would be cut). Example with a limitation of 120 characters: “According to our records, you have at least one item that is overdue. The following item(s) are overdue: - Book 1 - Book 2 - Book 3“ will become : “According to our records, you have at least one item that is overdue. The following item(s) are overdue: - Book 1 - Book...“ -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 35715] New: Pick items to add to train directly from those in the waiting list
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35715 Bug ID: 35715 Summary: Pick items to add to train directly from those in the waiting list Change sponsored?: --- Product: Koha Version: master 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)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com In the preservation module, you have to add your items to the waiting list before you can add them to a train. When adding items to a train from the Trains > Show train page (at /cgi-bin/koha/preservation/trains/1/items/add), the only option is to scan the item's barcode. I understand that makes sense for library staff who are located close to the physical items. However, it would be very useful if all the items in the waiting list could also be displayed on this page, so staff could select them from the list instead of re-scanning all the ones they need. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 33388] New: Use template wrapper for breadcrumbs: Patrons part 4
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33388 Bug ID: 33388 Summary: Use template wrapper for breadcrumbs: Patrons part 4 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 32507 To continue the process started by Bug 32507, this patch will update more patron module templates so that they use the new template wrapper for breadcrumbs. - members/memberentrygen.tt - members/members-update.tt - members/merge-patrons.tt - members/moremember.tt - members/notices.tt - members/pay.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32507 [Bug 32507] Use template wrapper to build breadcrumb navigation -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 23830] New: Koha::AuthorisedValues should use Koha::Objects::Limit::Library
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23830 Bug ID: 23830 Summary: Koha::AuthorisedValues should use Koha::Objects::Limit::Library Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: agustinmoyano(a)theke.io, fridolin.somers(a)biblibre.com, jonathan.druart(a)bugs.koha-community.org, katrin.fischer(a)bsz-bw.de, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 17755, 23272, 23281 Koha::Patron::Attribute::Types should be used as an example. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17755 [Bug 17755] Introduce Koha::Patron::Attribute::Type(s) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23272 [Bug 23272] Koha::AuthorisedValue should use Koha::Object::Limit::Library https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23281 [Bug 23281] Add Koha::Objects::Limit::Library -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 35579] New: marcrecord2csv searches authorised values inefficiently
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35579 Bug ID: 35579 Summary: marcrecord2csv searches authorised values inefficiently Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you have a CSV export profile with a large number of fields, and you have a list with a large number of records, you end up making the exact same database calls thousands of times. This chews up CPU like crazy and it can also mean your list never downloads as the proxy times out. So we need to cache! Koha::AuthorisedValues already caches when getting descriptions by "koha_field", but it does *not* when getting descriptions by "marc_field". Koha::AuthorisedValues->search_by_marc_field is actually only ever used by C4::Record for CSV exports anyways so that's probably why this hasn't come up before... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 34051] New: Koha::AuthorisedValues->get_description_by_koha_field not caching results for non-existent values
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '25

31 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34051 Bug ID: 34051 Summary: Koha::AuthorisedValues->get_description_by_koha_field not caching results for non-existent values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As I note at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31216#c5 Koha::AuthorisedValues->get_description_by_koha_field isn't caching database results for non-existent values. Many authorised values lists don't have a value for 0, but many records contain values of 0. Koha::AuthorisedValues->get_description_by_koha_field() will do a database call every time it encounters a value that doesn't exist in the AV table, because it isn't caching the empty/null that is calculated based on the incoming value not existing in the AV table. In terms of code, it is a simple change, but Koha::AuthorisedValues->get_description_by_koha_field is used in a lot of places, so obviously we'll want to be careful making any changes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23