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

[Bug 27432] New: Add report run to action logs
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27432 Bug ID: 27432 Summary: Add report run to action logs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Reports run should be logged in action logs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 19384] New: [OMNIBUS] Add Selenium tests
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19384 Bug ID: 19384 Summary: [OMNIBUS] Add Selenium tests Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 29602] New: We must be nicer with translators
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29602 Bug ID: 29602 Summary: We must be nicer with translators Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The PO files are really ugly sometimes, the number of %s and the inclusion of TT tags make the translation a nightmare for translators. We can improve that. -- You are receiving this mail because: You are watching all bug changes.

1 115

[Bug 29238] New: Cataloging cron jobs are not logged
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29238 Bug ID: 29238 Summary: Cataloging cron jobs are not logged Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz After a few cron jobs related to authority records (misc/migration_tools/remove_unused_authorities.pl, misc/link_bibs_to_authorities.pl) were set up to run on our instance, I went to check the Log Viewer tool but couldn't tell that they were configured. I was told that only newer cron jobs actually appear in the logs, and on inspecting those two I saw that they lacked the call to `cronlogaction()` which our circulation-related cronjobs have. It'd be helpful to know if/when these jobs ran. I realize this is a bit debatable because those two scripts don't reside in misc/cronjobs and right now the only scripts that call `cronlogaction()` are in that directory. Is it appropriate to add that logging to these scripts? We do run them on a schedule, it's important to our authority records workflow. This is the complete list of ones I'd like to add logging to: - misc/link_bibs_to_authorities.pl - misc/cronjobs/merge_authorities.pl - misc/migration_tools/remove_unused_authorities.pl A side note: there are several scripts in misc/cronjobs, like merge_authorities.pl, that are not logged and probably should be, but that is a larger bug and I'd like to focus on these first since they're relevant to us. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 33609] New: Script delete_records_via_leader.pl should work with authority records
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33609 Bug ID: 33609 Summary: Script delete_records_via_leader.pl should work with authority records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently this only works with biblios, we should provide the same service for authorities -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 34037] New: Item Bundles do not correctly checkin the bundle if the 952$3 has text
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34037 Bug ID: 34037 Summary: Item Bundles do not correctly checkin the bundle if the 952$3 has text Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using the bundled feature, if the item that is getting checked out has a 952$3, the check-in will not be successful. This main item can not have this field, although this field is helpful for staff to know it is a bundle and has items included. Step 1. Create a bundle of items Step 2. The 'main' item in which will be checked out to the patron - make sure it has a 952$3 with text. Step 3 Check out the 'main' item that has the items attached to it. See the materials specified text appear at checkout. Step 4 Checkin in the 'main' item and the subsequent items. Step 5 See that all items are verified Step 6 Koha will bring the staff member back to the screen to do the check-in. Step 7 Go to the 'main' item and see the bundle is still checked out to the patron. Removing the materials specified from the main item, and the check-in will then be successful and be removed from the patron's account. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 33675] New: OAuth should support state parameter
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33675 Bug ID: 33675 Summary: OAuth should support state parameter Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Some Authentication solutions require a 'state' parameter to be passed during authentication to verify the sources on either end, it is supported by Mojolicious: https://metacpan.org/pod/Mojolicious::Plugin::OAuth2 We should add this to Koha -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 36762] New: Item not transferred correctly when there is a pending hold
by bugzilla-daemon＠bugs.koha-community.org 31 May '26

31 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36762 Bug ID: 36762 Summary: Item not transferred correctly when there is a pending hold Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha is doing some dumb stuff when one attempts to transfer an item that could fill a pending hold. To recreate: 1 - be logged in at Branch A 2 - have a bib with 1 holdable item at Branch A 3 - place a hold for pickup at Branch B 4 - confirm hold shows on Holds to Pull and Holds Queue 5 - go to Circulation > Transfers and attempt to send your item to Branch C 6 - Koha gives you three options. Pick the first one: "Transfer to Branch B." This is the hold pickup branch, not the branch you selected for your transfer 7 - Koha tells you it has transferred the item to Branch C (the branch you did select for your transfer) 8 - go to detail.pl for your title, confirm the holdings table says "there is an item level hold" on your item 9 - click to the Holds tab for your title, confirm the hold claims to be in transit 10 - query the branchtransfers table, confirm no transfer was created 11 - query reserves and confirm your hold has found=T, itemnumber=[your item], and item_level_hold=0 12 - Back on the title, attempt to revert transit status, confirm the Revert button doesn't do anything At step 6, Koha should offer to transfer to the indicated transfer-target, rather than the hold pickup branch. Then it should actually generate the transfer and should not insert the itemnumber into the reserves table or update reserves.found. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 31698] New: Add ability to move a hold to a new biblio/item
by bugzilla-daemon＠bugs.koha-community.org 29 May '26

29 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31698 Bug ID: 31698 Summary: Add ability to move a hold to a new biblio/item 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Sometimes a library gets a new edition, or a new copy of an item and would like to be able to directly provide this to a patron with an existing hold. We propose add a new action on the holds table on request.pl 'Move hold' For an item level hold it would provide a modal with a barcode entry box so librarians can scan a new copy in hand, and move the hold to that specific item For a biblio level hold it would provide a modal with a search box - entering keywords would search the catalog, and add a 'Move hold' button to the results - similar to 'Add to basket form existing record' search in acquisitions -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 198

[Bug 36720] New: Going back when placing multiple holds retains prior selections
by bugzilla-daemon＠bugs.koha-community.org 29 May '26

29 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36720 Bug ID: 36720 Summary: Going back when placing multiple holds retains prior selections Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests 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 In the staff client, when placing multiple holds with the checkboxes on the search results page, if you go back and make new selections after clicking 'place hold', the prior selections are still kept. To replicate: - Search for something with more than 2 results - On the search results page, check two different checkboxes - Click 'Place hold' at the top of the results - Go back with the browser's back button - Uncheck the previous selections, check checkboxes for two new titles - Click 'Place hold' at the top of the results - Search for a patron - Notice 4 titles are listed, despite only having 2 checked Also, going back, then clicking 'place hold' again without changing the checkboxes will cause the titles to be listed in the table of potential holds multiple times. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1