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

[Bug 28527] New: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Bug ID: 28527 Summary: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a transfer is cancelled whilst it is in transit (datesent set, but datearrived not) then we should still return it as in transit. Bug 27993 added a condition to the 'in_transit' boolean which should be reverted. We should also update the get_transfer (and get_transfers) methods to catch such cases and return those still active transfers and deal with them appropriately at check-in. (i.e. invoke the reverse transfer or pick the next transfer from the queue and notify the librarian of what subsequent actions they should take). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 40792] New: Do not fill hold requests when issuing non-holdable items
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40792 Bug ID: 40792 Summary: Do not fill hold requests when issuing non-holdable items Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com It is a regression from bug 38650 that issuing non-holdable items now fills holds. The subroutine C4::Reserves::MoveReserve would previously only do anything if there where a hold that had been filled with the specified item, which mean that the item issued was holdable. But bug 38650 opened up the possibility to fill the borrowers hold even if the issued item is not holdable. I suggest a check that the item issued is holdable if the biblio is reserved by the borrower. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 40275] New: Add Koha::Patrons->find_by_identifier()
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40275 Bug ID: 40275 Summary: Add Koha::Patrons->find_by_identifier() Change sponsored?: --- Product: Koha Version: Main 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 As suggested by Frido in some other context, I file this bug to introduce the mentioned sub. I resurrected the idea after tracking down some warnings in SIP, and identifying bug 36575 introduced them by calling `->find` without passing a primary key. This kind of errors/warns: ``` [2025/06/30 13:03:23] [24253] [ERROR] [undef]@[undef]: DBIx::Class::ResultSource::_minimal_valueset_satisfying_constraint(): Unable to satisfy requested constraint 'primary', missing values for column(s): 'borrowernumber' at /kohadevbox/koha/Koha/Objects.pm line 98 C4::SIP::Trapper::__ANON__ /kohadevbox/koha/C4/SIP/Trapper.pm (70) ``` Instead of solving it locally, I propose to introduce a sane and tested method, and reuse it anywhere this pattern is being used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 28761] New: Item status shows incorrectly on opac-course-details.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28761 Bug ID: 28761 Summary: Item status shows incorrectly on opac-course-details.pl 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: - create a course in course reserves, add an item to it. - confirm your item shows Available for its status on opac-course-details.pl - give your item a notforloan status - reload opac-course-details.pl, confirm its still "available" - give your item a restricted user status - reload opac-course-details.pl, confirm its still "available" - give your item a lost, damaged, or withdrawn status - reload opac-course-details.pl, these statuses *are* reflected Filing a separate bug for the staff client. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 38804] New: erm : JSTOR usage data not harvestable via SUSHI
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38804 Bug ID: 38804 Summary: erm : JSTOR usage data not harvestable via SUSHI Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org 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 Trying to harvest JSTOR usage data via SUSHI returns an error in Koha job : "SUSHI returned: Warning - Report Queued for Processing 1011" This behavior is documented in Counter registry (https://registry.countermetrics.org/platform/335608df-e4d2-46ad-bd89-fb3683…) for JSTOR "The same report cannot be requested more than 5 times per day. JSTOR uses reporting queuing so if data is not yet available, clients will need to re-request the report at a later date." and in JSTOR site : https://support.jstor.org/hc/en-us/articles/360015483214-SUSHI-reports-COUN… "Please wait at least one (1) hour between report requests to allow time for report files to be generated." I suppose other data provider may have the same policy. For Koha to be able to harvest them, it should be necessary to add an option to relaunch the harvesting process after a parametrable delay -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 30533] New: Add exact search option for patrons
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30533 Bug ID: 30533 Summary: Add exact search option for patrons 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A patron search for names like "JOHN JOHNSON" ends up getting parsed something like "WHERE surname like "%JOHN%" OR firstname like "%JOHN%" OR surname like "%JOHNSON%" OR firstname like "%JOHNSON%"" and finds a really unhelpfully large pile of patrons. Bug 17500 suggests implementing Elastic for patron searching, which would be great. In the meantime, we could give a little help for searches like this by giving an exact search option -- so the query would parse more or less the same but without the wildcards. That's also a problematic search for many situations, but would work better here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 33200] New: IndependentBranchesTransfers does not prevent holds from creating transfers
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33200 Bug ID: 33200 Summary: IndependentBranchesTransfers does not prevent holds from creating transfers Change sponsored?: --- Product: Koha Version: unspecified 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 I noticed that when you have IndependentBranches (Yes), IndependentBranchesTransfers (Yes), and canreservefromotherbranches (Don't allow), holds can still trigger transfers. This is probably larger than transfers as holds should not be placed on items from other libraries with IndependentBranches, even if we choose "next available item". IndependentBranches/canreservefromotherbranches should imply "next available item (from this branch)". To reproduce, you must have - IndependentBranches, IndependentBranchesPatronModifications and IndependentBranchesTransfers preferences set to Yes - canreservefromotherbranches must be set to Don't allow - Circulation rules that allow holds and checkouts - Two libraries (I used Midway (A) and Centerville (B)) - A record with two items, one at each library, with barcodes, check out the one from library A - Two non-superlibrarian staff user, one in each library, with at least catalogue and holds permissions, this is what I gave them - circulate (all) - catalogue - delete_borrowers - edit_borrowers - reserveforothers (all) 1. Log in to the staff interface with the non-superlibrarian staff user from library A 2. Go to the record with the two items, click "Place hold" 3. Place a hold for a user, without changing anything (should be for "next available item") 4. Log out and log back in with the non-superlibrarian staff user from library B 5. Check in the item from library B, which should be available --> Hold is confirmed for patron from library A, transfer is created 6. Optionally, you can log out and log back in as staff from library A 7. Go to Circulation > Transfers to receive (should this even be available with IndependentBranchesTransfers turned on?) --> Item from other branch is there -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 31504] New: ElasticSearch No indexing new records after upgrade
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31504 Bug ID: 31504 Summary: ElasticSearch No indexing new records after upgrade Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es After upgrading koha 21.11 to 22.05 ElasticSearch is not able to index new records. At webadmin we can see the warning 'Index 'koha_xxxxxx' needs to be recreated.' Executing 'Reset mapping' button doesn't fix the error... when trying to full reindex with option -d or -r it doesn't work admin@___21:~$ sudo koha-elasticsearch --rebuild -d ___ sudo: unable to resolve host ___21: Name or service not known sudo: unable to resolve host ___21: Name or service not known Use of uninitialized value $reason in concatenation (.) or string at /usr/share/koha/lib/Koha/SearchEngine/Elasticsearch/Indexer.pm line 283. Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_____biblios". Reason was: "". Index needs to be recreated and reindexed' Something went wrong rebuilding indexes for ___ Removing the index directly at ElasticSearch doesn't works * ElasticSearch is not localhost -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 41147] New: Counts in bulkmarcimport.pl are incorrect
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41147 Bug ID: 41147 Summary: Counts in bulkmarcimport.pl are incorrect Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We are incrementing the record_number counter twice for every record -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 32419] New: Show availability in list view in staff interface
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32419 Bug ID: 32419 Summary: Show availability in list view in staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 viewing a list on the OPAC, you can see the item's availability. But in the staff interface, this information is not visible. To test : 1. In the staff interface, add an item to a list 2. View the list --> No availability is visible 3. Go to the OPAC and view the list --> You can see the availability of the item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22