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

[Bug 37456] New: Allow to type in library hours
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37456 Bug ID: 37456 Summary: Allow to type in library hours Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When setting library hours in Administration > Libraries, you have to select the hours in the selector popup. It would be useful to be able to type them in. If I type 9, it's ok. If I want to type 9:55, it doesn't let me. It also doesn't let me type 17. I think it's because it's actually a date selector and doesn't go over 12 for the "hours" and doesn't go over 31 for the "minutes" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 36594] New: Library hours display issues
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36594 Bug ID: 36594 Summary: Library hours display issues Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There are some glitches on the libraries table: * If not defined, the string literal 'null' is displayed * If you set 9:00 as the opening hour, 09:00::00 is displayed The feature authors need to: * Find a good approach to undefined values here (do we need to display days when the library is not open?) * Use the formatting tools to display time correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 20638] New: Log actions on API keys
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20638 Bug ID: 20638 Summary: Log actions on API keys 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Actions on API keys shoudl be logged and auditable (i.e. who creates the API keys, who revokes, etc). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 97

[Bug 21272] New: Marc import should warn about mis-matched branch and item-type fields in 952 during marc import.
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21272 Bug ID: 21272 Summary: Marc import should warn about mis-matched branch and item-type fields in 952 during marc import. 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: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When importing a record that has homebranch (952$a), holding branch (952$b) or item type (952$y) populated, but not matching values in branches.branchcode or itemtypes.itemtype, koha will indicate that items were not imported (via the count of imported items), but not why. This causes frequent confusion among new users. It would be nice to offer mappings between detected branches / item types and the branches and item types already in the system. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 110

[Bug 28860] New: Add system setting to mark Patron fields important
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28860 Bug ID: 28860 Summary: Add system setting to mark Patron fields important Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice to add a system setting similar to the BorrowerMandatoryField for the patron form to mark fields important. This would give a visual clue for fields that should be filled in but are not necessarily required. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 36549] New: es_indexer_daemon.pl leaks memory
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36549 Bug ID: 36549 Summary: es_indexer_daemon.pl leaks memory Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 background_jobs_worker.pl runs its tasks in child processes which return their memory to the OS when they complete. es_indexer_daemon.pl runs everything in itself which means if it needs to allocate a large amount of memory for an indexing job, it will hold on to that memory allocation for its entire process life. -- I've got an es_indexer_daemon.pl which is using over 1GB of memory. Once it's done with its indexing activity, I'm going to restart it to get it back down to a more reasonable amount of allocated memory. I reckon we should be forking off child processes to do the worker. We don't need many. We just need 1 that is short lived so that it can return the memory back to the OS. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 38040] New: IndependentBranches doesn't prevent editing other libraries' holds
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38040 Bug ID: 38040 Summary: IndependentBranches doesn't prevent editing other libraries' holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When IndependentBranches is set, any staff member from any library can see and edit the holds from patrons from other libraries. 1. Set IndependentBranches, IndependentBranchesPatronModifications, and IndependentBranchesTransfers to 'Yes' 2. Set canreservefromotherbranches to "Don't allow (with independent branches)" 3. Give limited permissions to a staff patron - circulate - catalogue - delete_borrowers - edit_borrowers - list_borrowers - send_messages_to_borrowers - reserveforothers - updatecharges 4. As the superlibrarian, place several holds on a record with items from various branches 5. Log in as the restricted staff 6. View the holds for the record --> Some will say "A patron from library XX" instead of the name -- OK 7. Click the trash bin icon to cancel a hold from another library --> Hold is cancelled -- NOT OK I feel like it should only be superlibrarians who can edit all holds, even those from other libraries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 79

[Bug 29980] New: Validate ISBN when cataloguing bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29980 Bug ID: 29980 Summary: Validate ISBN when cataloguing bibliographic records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl https://metacpan.org/pod/Business::ISBN Business::ISBN has a valid_isbn_checksum method that implements an ISBN check digit algorithm for both 10-digit and 13-digit ISBNs. Koha could adopt this to validate ISBNs when cataloguing biblios. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[Bug 18148] New: Chronological order for public lists in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18148 Bug ID: 18148 Summary: Chronological order for public lists in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Some librarians ask us to have public lists in chronological order rather than in alphabetical order because some schools will have to kept them there for a long time. This results in a big list with many pages on which is more difficult to find the good list. 1) Go in an OPAC interface 2) Go to "Lists" normally in top left corner 3) A small list appears from the top of the screen, observe that this list is by modification date (not alphabetical order) 4) Clic then on public lists 5) Observe that all lists created are in alphabetical order and their order cannot be changed We are wondering if it's possible to have some sorting options for the results list like in the staff client interface. There, you can change for chronological (modification or creation date) but also by owner order. Thanks for helping us, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes.

1 60

[Bug 32483] New: Show requested changes to personal details in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32483 Bug ID: 32483 Summary: Show requested changes to personal details in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment when a user makes a request for changing the address or similar, there is a note on submitting the form, that the request will be forwarded to the library for processing. After that, when the page is reloaded, the old information still shows and there is no hint on a pending change request. It would be nice if we could show that there was still a change request pendingon the page, so that people don't resend them unnecessarily. And it would be great if we could show which changes were requested. -- You are receiving this mail because: You are watching all bug changes.

1 17