November 2022 - Koha-bugs - lists.koha-community.org

[Bug 28439] New: Add ability to suspend club enrollments
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '25

22 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28439 Bug ID: 28439 Summary: Add ability to suspend club enrollments 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: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be helpful if club enrollments could be suspended or paused for a specific patron. Right now, if a patron goes on vacation and we want to prevent them from getting club holds we have to remove them from all their clubs, keep track of which ones they were removed from, then add them back to their clubs at a later date. If we could suspend their enrollments without fully removing them from the club that would mean less tracking and work to re-establish their enrollments after they have returned. Bonus points if this can behave like a hold suspension, where you could suspend multiple enrollments with one click via the patron's account and also set a date to automatically release the suspensions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 29582] New: Browse search results block not visible in OPAC when using Google Chrome
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '25

19 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29582 Bug ID: 29582 Summary: Browse search results block not visible in OPAC when using Google Chrome Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 128054 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128054&action=e… Browse results block in OPAC not visible in Google Chrome When using Google Chrome and clicking through from the search results page, the browse search results block on the details page for a record is not visible. It does display correctly in Firefox. Screenshot attached. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 19534] New: Adding collection code attribute to cover image div
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '25

19 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19534 Bug ID: 19534 Summary: Adding collection code attribute to cover image div Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: michael(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To further facilitate add images associated with items, add collection code attribute ID to cover image div. Requested by archive that wanted to have images associated with specific collections appear next to items in search results. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 31581] New: Remove Zebra files for NORMARC
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31581 Bug ID: 31581 Summary: Remove Zebra files for NORMARC 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 18984 Bug 18984 removed support for NORMARC, but some files remained: /etc/zebradb/marc_defs/normarc/biblios Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18984 [Bug 18984] Remove support for NORMARC -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 30856] New: Remove CanReserveBeCanceledFromOpac
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30856 Bug ID: 30856 Summary: Remove CanReserveBeCanceledFromOpac Change sponsored?: --- Product: Koha Version: unspecified 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 We already have a method that does the same check, Koha::Hold->is_cancelable_from_opac -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 27063] New: Allow changing which record an order is linked to
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27063 Bug ID: 27063 Summary: Allow changing which record an order is linked to Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment if the basket is still open you can update the bbliographic details of an order or overwrite the existing record via Z39.50, but if you notice that you have used the wrong record, there is no way to fix this. It would be great if it was possible to change the record an order is linked to while the basket is still open. This should explicitly allow to use a record that is already in the catalog. -- There is also a use case here for libraries using standing orders for tracking electronic resources such as series. They usually place the order on the series record. When the volumes arrive they'd like to change it so the acq information is tied to the volume. But without using items (which is not the case here for electronic resources), this is not possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 22881] New: Trying to clear search history via the navbar X doesn't clear any searches
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22881 Bug ID: 22881 Summary: Trying to clear search history via the navbar X doesn't clear any searches Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: margaret(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To Reproduce: 1) Run a few keyword searches on your Opac. You can be logged in or not, the behavior is the same. 2) Go to 'My Search History' the /cgi-bin/koha/opac-search-history.pl page. 3) Delete your past searches by selecting one or multiple searches and clicking the "Remove Selected Searches" button. You'll get an alert pop-up about what you are about to delete. The searches you selected should delete successfully. 4) Look at the little "x" (next to "Search History" in the Navbar). If you click on this "x" it will give you the exact same alert pop-up, however is you say yes, delete my searches, nothing will be deleted. Either the little "x" should not give you the option to delete searches nor the alert message or it should clear all your saved searches; as if you hit select all and Remove. Otherwise patrons who want to delete their history will be incorrectly lead to believe it was cleared if they don't check /cgi-bin/koha/opac-search-history.pl . -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 25996] New: Changes to debarments should be logged
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25996 Bug ID: 25996 Summary: Changes to debarments should be logged Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1 - verify borrower log is enabled 2 - click Edit on a patron 3 - on the edit page click "add a manual restriction" and enter a debarred comment, save the patron 4 - click Edit again, remove your restriction 5 - go to patron modification logs, see the log of your changes 6 - go back to the borrower checkout page, click to the Restrictions tab 7 - add a restriction 8 - delete the restiction 9 - go to patron modification logs, see there is not a log of your changes -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 26170] New: Create "system" patrons that cannot be (easily) deleted via the web ui
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170 Bug ID: 26170 Summary: Create "system" patrons that cannot be (easily) deleted via the web ui Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At the moment, the only way to create OAuth2 or Basic Auth credentials is to generate a user. This user can be deleted by a librarian by accident, which will break your API integration with Koha. I propose that we make some system users that cannot be deleted from the Web UI. (Or users that can be deleted by a superlibrarian, but need to be "unlocked" first or maybe have their category changed, and a warning splashed that this will likely break integrations with other systems.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 78

[Bug 31104] New: Pagination generates HTTP "Link:" header which is over 8291 bytes apache's limit
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '25

15 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31104 Bug ID: 31104 Summary: Pagination generates HTTP "Link:" header which is over 8291 bytes apache's limit Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: REST API Assignee: tomascohen(a)gmail.com Reporter: nugged(a)gmail.com CC: tomascohen(a)gmail.com to repeat: 1. Go to /cgi-bin/koha/members/member.pl 2. put this test into the "Search for patron" "Search:" field: "some long test to search in patron fields" 3. Observe "nothing found" but in the server log, it will say (28)No space left on device: [client 127.0.0.1:60330] AH10124: header size is over the limit allowed by ResponseFieldSize (8192 bytes). Bad response header: 'Link: <https://... this of course happens when you searching for something long but seems we came to so long URL which fails to fit into the "forward" (Link: ... header) field, if to debug, it creates a "search" API request URL that is already 5219 bytes long, then this URL is re-encoded and put two times inside the "Link:" header, so it quickly jumps over the 8192 bytes header limit. Note: as we found together that solution in Koha/REST/Plugin/Pagination.pm to split @links in separate "Link:" headers. SIDENOTE: considering that we already have URL 5129 long in this example, we might anyway even without header doubling bump into the 8192 limits (!). We might need re-think later how in general this formed up. Not related to the current shorter fix though. -- You are receiving this mail because: You are watching all bug changes.

1 23