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

[Bug 37021] New: REST API: Holds endpoint handles item_id as string in GET call
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '25

19 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37021 Bug ID: 37021 Summary: REST API: Holds endpoint handles item_id as string in GET call Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi CC: tomascohen(a)gmail.com When one makes a GET call to holds endpoint and hold has item attached to it, item_id is handled as string not integer as it should. To reproduce: 1. Make sure you have hold waiting in your database. 1. Call endpoint api/v1/holds/?q=[{"me.status":"W"}]. 2. Note that holds item_id is displayed as item_id: "12345". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 37032] New: REST API: Unable to call item info via holds endpoint
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '25

19 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37032 Bug ID: 37032 Summary: REST API: Unable to call item info via holds endpoint Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi CC: tomascohen(a)gmail.com I'm trying to fetch items barcode via holds endpoint with no luck. If I've understood correctly, this should be possible by adding item as embed in /api/v1/swagger/paths/holds.yaml and then adding it to enum option in kohaTable function. However this only leads to following error: >Something went wrong when loading the table. >400: Bad Request. >Not in enum list: cancellation_requested, biblio, pickup_library, item. Documentation for endpoint shows that endpoint should produce item object and Koha::Hold does have relation to item. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 33018] New: debian package tidy-up
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '25

19 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33018 Bug ID: 33018 Summary: debian package tidy-up Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com this bug aims to track a tidy-up of debian package files -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43

[Bug 29898] New: Overdues.pm line 663, Use of uninitialized value in string eq
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '25

18 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29898 Bug ID: 29898 Summary: Overdues.pm line 663, Use of uninitialized value in string eq Change sponsored?: --- Product: Koha Version: 20.11 Hardware: PC OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: elias.dehler(a)thulb.uni-jena.de QA Contact: testopia(a)bugs.koha-community.org After migrating 37 instances from v19.11 to v20.11.13 the /etc/cron.daily/koha-common logs the following on 7 instances: "Use of uninitialized value in string eq at /usr/share/koha/lib/C4/Overdues.pm line 663." We've checked the settings across the instances and the database. We can't find the root of this warning/error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 36202] New: Article requests: a SCAN request has no pickup location
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '25

17 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36202 Bug ID: 36202 Summary: Article requests: a SCAN request has no pickup location Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A scan is mailed via a notice to the user. So no need to pickup. The field article_requests.branchcode should better contain the branchcode of the item holding branch (if at least an item has been selected or forced by circ rule). The default selection on circ/article-requests goes via that branchcode. You will only see the requests for current branch as 'pickup location'. What to show, actually depends on the workflow. Is the book scanned locally or should it be transferred to the pickup location for scanning there or even elsewhere? Bit related to bug 20973 btw. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 24976] New: Guided report - "Save" button on last step is misleading
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '25

17 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24976 Bug ID: 24976 Summary: Guided report - "Save" button on last step is misleading Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Keywords: Academy Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org "Save" button on last step does not save (!) It should be renamed "Next" instead https://snipboard.io/gXntf8.jpg Next step has a "Save report" button that actually saves. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 34860] New: New framework plugin for ISBN/ISSN
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '25

16 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34860 Bug ID: 34860 Summary: New framework plugin for ISBN/ISSN 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Something similar as on bug 34817. But obstacle currently is REST API not supporting ccl search on index. So in its current form it should need a svc script to do the index search. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 25127] New: Fines with an amountoutstanding of 0 can be created due to maxFine but cannot be forgiven
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '25

16 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25127 Bug ID: 25127 Summary: Fines with an amountoutstanding of 0 can be created due to maxFine but cannot be forgiven Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Set maxFine to 7.50 2 - Manually create some overdues for a patron in the amounts of: 6.99, .1, .1, .1, .1, .1, .01 (create a manual debits then 'UPDATE accountlines SET debit_type_code = "OVERDUE";' 3 - Set fines for an item type to .1 4 - Checkout an item of that type to patron and backdate so it is overdue 5 - Run fines.pl 6 - Check the DB, they have a new fine of "0" 7 - Checkin the item, checking 'forgive fines' option 8 - ISE "Debit amount passed is not positive" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 31968] New: Problems with MARC staging/import
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '25

16 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31968 Bug ID: 31968 Summary: Problems with MARC staging/import Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I'm having various problems with importing staged MARC records on 22.05.05. One example: I have staged a file and click on "Import this batch to the catalogue". The progress bar jumps to 31% but then it stops and goes no further. In the background there are lots of calls to /cgi-bin/koha/tools/background-job-progress.pl?jobID=<id>, but the last one gives a 500 error. This is when the progress bar stops. The job is actually finished after a while, but the interface never updates. I think these are the relevant errors in the logs: ==> /var/log/koha/koha/intranet-access.log <== ... a.b.c.d - - [25/Oct/2022:10:46:39 +0200] "GET /cgi-bin/koha/tools/background-job-progress.pl?jobID=<id> HTTP/1.1" 200 57 a.b.c.d - - [25/Oct/2022:10:46:40 +0200] "GET /cgi-bin/koha/tools/background-job-progress.pl?jobID=<id> HTTP/1.1" 200 57 a.b.c.d - - [25/Oct/2022:10:46:40 +0200] "GET /cgi-bin/koha/tools/background-job-progress.pl?jobID=<id> HTTP/1.1" 200 57 ==> /var/log/koha/koha/intranet-error.log <== [2022/10/25 10:47:50] [WARN] binmode() on closed filehandle _GEN_70 at /usr/share/koha/lib/C4/Templates.pm line 126. CGI::Compile::ROOT::usr_share_koha_intranet_cgi_2dbin_tools_manage_2dmarc_2dimport_2epl::__ANON__ /usr/share/koha/intranet/cgi-bin/tools/manage-marc-import.pl (331) [2022/10/25 10:47:50] [WARN] print() on closed filehandle _GEN_70 at /usr/share/koha/lib/C4/Output.pm line 285. CGI::Compile::ROOT::usr_share_koha_intranet_cgi_2dbin_tools_manage_2dmarc_2dimport_2epl::__ANON__ /usr/share/koha/intranet/cgi-bin/tools/manage-marc-import.pl (331) ==> /var/log/koha/koha/plack-intranet-error.log <== [2022/10/25 10:47:50] [WARN] seek() on closed filehandle _GEN_70 at /usr/share/perl5/CGI/Emulate/PSGI.pm line 34. ==> /var/log/koha/koha/intranet-access.log <== a.b.c.d - - [25/Oct/2022:10:46:41 +0200] "GET /cgi-bin/koha/tools/background-job-progress.pl?jobID=<id> HTTP/1.1" 500 118732 The only related bug I can find is Bug 15032, which mentions "binmode() on closed filehandle" way back in 2015. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 36955] New: Extend data providers in eUsage for different SUSHI credentials in multi branch systems
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '25

15 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36955 Bug ID: 36955 Summary: Extend data providers in eUsage for different SUSHI credentials in multi branch systems Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com In a multi branch system you might have different SUSHI credentials for harvesting COUNTER reports for the different libraries. In our case we have three branches and each branch has separate API-Keys / Customer-IDs and so on ... The data providers should be extended to have a field for the library (dropdown with branches) database table: erm_usage_data_providers -- You are receiving this mail because: You are watching all bug changes.

1 6