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

[Bug 29154] New: Add hold cancellation reason to Holds Awaiting Pickup page
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '25

01 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29154 Bug ID: 29154 Summary: Add hold cancellation reason to Holds Awaiting Pickup page Change sponsored?: --- Product: Koha Version: 21.05 Hardware: Macintosh OS: Mac OS Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: pnavarrete(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Using the authorized value "HOLD_CANCELLATION" allows us to choose a reason a hold was cancelled, which then triggers a patron notice. However, the option to choose a reason does not appear on the Holds Awaiting Pickup page, which is where we cancel holds from often. Can the hold cancellation options be added to this page? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 26282] New: Allow staff to decide if a hold cancellation notice will be sent when cancelling a hold
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '25

01 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26282 Bug ID: 26282 Summary: Allow staff to decide if a hold cancellation notice will be sent when cancelling a hold 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 25534 Bug 25534 adds the option to send hold cancellation notices when a reason was given. It would be nice if you could give a reason but still decide not to send to the patron. Say the patron called and will not be able to pick up numerous holds for some time. You cancel them all with "patron requested cancellation" but don't want to send multiple notices. I could imagine a checkbox next to the reason to activate/deactivate sending the notice. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25534 [Bug 25534] Add ability to send an email specifying a reason and store the reason when canceling a hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 170

[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 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 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