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

[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 42025] New: Error handling in tools/upload is broken
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42025 Bug ID: 42025 Summary: Error handling in tools/upload is broken Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 13618 On the following commit we add the html filter to msg: commit dcd1f5d48c758aee17b6c6f069c6146b42efe117 Date: Fri Jan 23 13:18:54 2015 +0100 Bug 13618: Add html filters to all the variables - ShowAlerts( [% msg %] ); + ShowAlerts( [% msg | html %] ); msg is supposed to be a JSON encoded string: tools/upload.pl 118 my $msg = 119 $delete ? JSON::to_json( { $fn => { code => ALERT_DELETED } } ) 120 : $id ? JSON::to_json( { $fn || $id, { code => ERR_NOT_DELETED } } ) 121 : ''; So we could use To.json in the template and remove the to_json from the controller. BUT... There are a couple places in the controller where we send back what we send: 38 my $msg = $input->param('msg'); 76 msg => $msg, Which would lead to XSS if we remove the filtering. This script receives msg in parameter when sent from SubmitMe 462 function SubmitMe(op, id, msg ) { 465 $("#submitter #msg").val( msg ); coming from: 398 function cbUpload( status, fileid, err ) { 399 $('#fileToUpload').prop('disabled', false); 400 if( status=='done' ) { 401 var e = err? JSON.stringify(err): ''; 402 SubmitMe( 'search', fileid, e ); Coming from 364 function StartUpload() { 387 xhr= AjaxUpload( $('#fileToUpload'), $('#fileuploadprogress'), xtra, cbUpload ); Which does...: koha-tmpl/intranet-tmpl/prog/js/file-upload.js 1 function AjaxUpload(input, progressbar, xtra, callback) { 10 var url = "/cgi-bin/koha/tools/upload-file.pl?" + xtra; 19 xhr.onload = function (e) { 20 var data = JSON.parse(xhr.responseText); 21 if (data.status == "done") { 22 progressbar.val(100); 23 progressbar.next(".fileuploadpercent").text("100"); 24 } 25 callback(data.status, data.fileid, data.errors); 26 }; tools/upload-file.pl 55 send_reply( 'failed', undef, $upload ? $upload->err : undef ); 63 sub send_reply { # response will be sent back as JSON 64 my ( $upload_status, $data, $error ) = @_; 65 my $reply = CGI->new(""); 66 print $reply->header( -type => 'text/html', -charset => 'UTF-8' ); 67 print JSON::encode_json( 68 { 69 status => $upload_status, 70 fileid => $data, 71 errors => $error, 72 } 73 ); Koha/Uploader.pm 154 sub err { 155 my ($self) = @_; 156 my $err; 157 foreach my $f ( keys %{ $self->{files} } ) { 158 my $e = $self->{files}->{$f}->{errcode}; 159 $err->{$f}->{code} = $e if $e; 160 } 161 return $err; 162 } All this is VERY messy... Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13618 [Bug 13618] Add additional template filter methods and a filter presence test to Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 13618] Add additional template filter methods and a filter presence test to Koha
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13618 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42025 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42025 [Bug 42025] Error handling in tools/upload is broken -- You are receiving this mail because: You are watching all bug changes.

1 0

[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

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '26

08 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #324 from David Cook <dcook(a)prosentient.com.au> --- @Lari do you want to do a test of these latest patches and then I can mark SO and Jonathan can look at QA? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '26

08 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #323 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Jonathan Druart from comment #321) > Yep, see the last patch ("Add test_valuebuilder_popup.tt to the exception > list"), it's how we add exception to Koha::Devel::Files. Ahhhh that's cool. Awesome! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8937] Translation process removes CDATA in RSS XML
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '26

08 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8937 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42022] New: Add custom patron message broken if notice has library limitation
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '26

08 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42022 Bug ID: 42022 Summary: Add custom patron message broken if notice has library limitation Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com To reproduce: 1. Go to Tools -> Notices and slips 2. Create a new notice, choose 'Patrons (custom message)' from the modules dropdown 3. Change the Library to Centerville and fill in an email notice, then hit Save 4. Go to your patron account and ensure you have a primary email address saved for the patron 5. Go to the Notices tab 6. Click the Add message button in the navbar 7. Change 'Add a message for:' to Email 8. Change 'Patron notice:' to your new custom message template and Save 9. The page should refresh and you'll see that the notice was NOT generated --> BUG The plack-intranet-error.log will also complain that it couldn't find the notice for that transport type, but this is due to the library limitation. If you create another custom message for All libraries, this can be generated and sent as normal. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1