March 2022 - 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 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 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 26929] New: Koha will only display the first 20 macros Advanced Editor
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '25

30 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26929 Bug ID: 26929 Summary: Koha will only display the first 20 macros Advanced Editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: nick(a)bywatersolutions.com Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In 20.05, if a library has more than 20 macros, then they will not appear on the screen and will not be accessible to the cataloger. The current workaround, upping the value in this system preference, RESTdefaultPageSize - increased to 40, this will display the rest of the macros (over 20) for the library. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 20396] New: Omnibus: Koha Cleanup
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20396 Bug ID: 20396 Summary: Omnibus: Koha Cleanup Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some parts of the interface are not really working and have been in this status for a long time, either because a feature is boken and hard to fix, or because it was never really implemented in the first place. Other parts are not really used and could be removed, HEA is helpful to determine these situations to some extent, but not everything can be seen there. This omnibus will be used to link tickets related to cleaning up parts of Koha that can be removed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 46

[Bug 20411] New: Remove StaffDetailItemSelection system preference and make the feature always on
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20411 Bug ID: 20411 Summary: Remove StaffDetailItemSelection system preference and make the feature always on Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is always used according to HEA, and a very useful feature, i am not sure it makes sense to let the administrators choose to have it or not. Permissions are here also to make sure librarians won't batch delete items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 16122] New: Item record needs to keep Local Use count
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16122 Bug ID: 16122 Summary: Item record needs to keep Local Use count 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Like the "issues" field in the items table, there should be a field for "local_use" to keep the count of local uses. While this information is kept in the statistics table, it is a task to acquire, and if a library wants to keep bloat down on their tables, the statistics are pruned on a regular schedule, which means loss of valuable data. This counter would keep that valuable information in one field in each item record, rather than having a separate field for each instance in the statistics table. Unless it is vital to someone to know the exact moment a local use occurred, I am suggesting that this piece of information not be recorded in the statistics table any longer. This would significantly reduce the growth of the statistics table in general. Christopher -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 163

[Bug 27769] New: Advanced editor shouldn't break copying selected text with Ctrl+C
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27769 Bug ID: 27769 Summary: Advanced editor shouldn't break copying selected text with Ctrl+C Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, nick(a)bywatersolutions.com Depends on: 17179 Bug 17179 added a shortcut for Ctrl+C to copy the line where the cursor is into the advanced editor's clipboard div. That only works if you don't have text selected. If you have text selected, the shortcut silently does nothing, but Ctrl+C, which I've used for decades to copy selected text, doesn't copy the text. Dozens of times a day, I copy the OCLC control number from a record, or the contents of an 024, do an advanced search for that number (where I can no longer actually see what record I'm replacing), and replace the record. Despite having now spent months trying to train myself that Ctrl+C has been broken (difficult training since I catalog both on a Mac, where Cmd+C has not been broken, and on Windows where it has), every couple of weeks I catch myself having just replaced a record with some record I had previously successfully right-click copied data from. How often do I *not* catch myself, and replace a record with a record for a completely different bib? Dunno, I'd really rather not think about that. The keyhandler looks like it'a a CodeMirror command, and the very scanty documentation says that a CodeMirror key handling command can return CodeMirror.Pass to let other handlers or the default behavior handle the key. Currently the handler does "return true" when it sees selected text and decides not to handle Ctrl+C. If instead returning cm.Pass would make the system clipboard work when text is selected, and the advanced editor clipboard work when no text is selected, that would be the best outcome. Second best would be deciding that silently causing the system clipboard to fail was a bad idea, and switching the default shortcut to something else. Yes, there is a system-wide option to change keys. For me, that means getting 14 people to agree on a different key, then starting the process of persuading an admin to make the change. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17179 [Bug 17179] Advanced editor: Add keyboard shortcuts to repeat (duplicate) a field, and cut text -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 23295] New: Automatically debar patrons if SMS or email notice fail
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23295 Bug ID: 23295 Summary: Automatically debar patrons if SMS or email notice fail 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org When the sending of an SMS (or email) notice fails at the Koha level (i.e. before it is passed to the SMS API) then librarians should have the ability to enable automatic restriction (debarment) of patrons prompting them to update their smsalertnumber (or email address) in their library accounts. Adding this ability will tie in nicely with the functionality implemented in bug 13552 and bug 23291. As the enhancement for this bug report would let us restrict when notices failed at the Koha level, whereas 13552 and 23291 would let librarians restrict when notices failed at the SMS API level in batch restriction jobs retrieving patrons by SMS numbers in the SMS gateway report libraries get telling them which notices failed at the SMS API level. So all three enhancements together will mean there will be end-to-end functionality to restrict patrons when SMS notices fail, thereby prompting them to update their smsalertnumber. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 71