March 2023 - Koha-bugs - lists.koha-community.org

[Bug 33073] New: sip_cli_emulator doesn't work and documentation is in error
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33073 Bug ID: 33073 Summary: sip_cli_emulator doesn't work and documentation is in error Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: bob-ewart(a)bobsown.com QA Contact: testopia(a)bugs.koha-community.org The documentation on SIP2 server setup gives an example of running the sip_cli_emulator: ./misc/sip_cli_emulator.pl -a 127.0.0.1 -p 6001 -su term1 -sp term1 \ -l CPL --patron 23529001000463 -m checkout --item 39999000001259 it responds with No such file or directory running: /usr/share/koha/bin/sip_cli_emulator.pl -a 127.0.0.1 -p 6001 -l SLA -su <loginID> -sp <login password> --patron <myID> --password <my password> -m patron_information it responds with Can't locate C4/SIP/Sip/Constants.pm running: perl -I /usr/share/koha/lib /usr/share/koha/bin//sip_cli_emulator.pl -a localhost ... it responds with: Attempting socket connection to localhost:6001...connected! Use of uninitialized value $hold_mode in string eq at /usr/share/koha/bin//sip_cli_emulator.pl line 122. SEND: 9300CNSLAAdmin_sip2|COst0newall1972|CPSLA| READ: 940 Login Failed! That user/password is in SIPconfiguration.xml. It's category is Staff and has permissions: Check out and check in items Staff access Place and modify holds for patrons Manage patrons fines and fees Manage the electronic resources module I can log in with that ID and password -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 33232] New: report on item types
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33232 Bug ID: 33232 Summary: report on item types Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: library(a)princeofpeaceabbey.org QA Contact: testopia(a)bugs.koha-community.org The report on item types seems to be stuck. The numbers do not change even though I have added more items. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31215] New: Add ability to select multiple items to remove from course_items
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31215 Bug ID: 31215 Summary: Add ability to select multiple items to remove from course_items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently the only way to remove items from course reserves is to remove all reserves or select items individually to remove. For libraries that use course reserves with large courses, the ability to select multiple items at a time to remove would be helpful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 24414] New: Can't add/delete funds with only budget_add_del permission
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24414 Bug ID: 24414 Summary: Can't add/delete funds with only budget_add_del permission Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This is very minor, but I was trying out all the permissions to better document them in the manual and I found something weird. There are several permissions granting access to funds. - budget_add_del described as 'Add and delete funds (but can't modify funds)' - budget_manage described as 'Manage funds' - budget_manage_all described as 'Manage all funds' - budget_modify described as 'Modify funds (can't create lines but can modify existing ones)' If I only have budget_add_del, I can't create or delete funds. I have to have budget_manage to access the funds administration page. Which is ok, I can simply add a note in the manual that budget_add_del requires budget_manage. If I have budget_add_del and budget_manage, I have access to the funds administration page, but not the 'New fund' button nor the 'Actions' button to delete an existing fund. So in reality, I can't add nor delete funds... If I have budget_manage and budget_modify (but not budget_add_del), I can't add new funds I can't edit existing ones, but I can delete them. To test : 1) Create a patron and give them the catalogue permission and the budget_add_del permission 2) Log in with this patron (I use a private window to be able to go back and change their permissions later without logging out again) 3) Go to the Acquisitions page 4) Notice you can see the budget, but you can't click on the fund code and you don't have the 'Funds' link in the left menu 5) Go back to edit the user's permissions and grant them budget_manage; save 6) Go back to the Acquisition page with the limited patron (refresh if needed) 7) Notice that you can now click on the fund code and you have a 'Funds' link on the left side of the screen 8) Click on the fund code 9) Click on 'New' and choose 'Add fund for xx'; add the new fund 10) Notice there is no 'Actions' button from which you can delete this fund 11) Go back to edit the user's permissions and remove the budget_add_del permission and add the budget_modify; save 12) Go back to the Acquisition page with the limited patron (refresh if needed) 13) Click on the 'Actions' button and choose 'Edit'; the page refreshes, but nothing happens 14) Click on the 'Actions' button and choose 'Delete' and confirm; the fund is deleted I have trouble imagining a situation where we would want staff to be able to add and delete funds but not modify them, so that's why I said I think this is minor. I think in most cases, the staff member will have at least all three (budget_add_del, budget_manage and budget_modify). But I still wanted to record the weirdness somewhere. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 32919] New: Patron category transitions should be managed in the interface, not on the command line
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32919 Bug ID: 32919 Summary: Patron category transitions should be managed in the interface, not on the command line Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a library wants to configure transitions between patron categories using the update_patrons_category.pl cron, all of the parameters for this must be entered on the command line. We should put the power to configure this in the hands of the library, and allow configuring these transitions in the Patron Category editor within the interface. We'll still need the cron of course, to do the actual shifting, but how cool would it be to have one job that checks the categories preferences and does the work without needing several job definitions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 19958] New: Allow the system preference AutoMemberNum to include a combination of numbers and letters when creating a new barcode
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19958 Bug ID: 19958 Summary: Allow the system preference AutoMemberNum to include a combination of numbers and letters when creating a new barcode Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 Currently the system preference "automembernum" only allows for the patron's barcode to default the card number field on the patron addition screen to the next available card number (for example, if the largest currently used card number is 26345000012941, then this field will default to 26345000012942). It would be nice for the library to choose the format of the barcode (for example : system preference autobarcode). Then a library could choose to include letters and numbers to their patron's barcode instead of just numbers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

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