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

[Bug 36036] New: Fix location field in addorderiso2709.pl
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36036 Bug ID: 36036 Summary: Fix location field in addorderiso2709.pl 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: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The loc field in MarcItemFieldsToOrder is not being transmitted through to the form in addorderiso2709.pl as it is being renamed to location in the script. To replicate Test plan: 1) In system preferences, click Search and then select the Acquisitions option from the left hand menu 2) Paste the following into MarcFieldsToOrder price: 975$p quantity: 975$q budget_code: 975$h 3) Paste the following into MarcItemFieldsToOrder homebranch: 949$a holdingbranch: 949$b itype: 949$y nonpublic_note: 949$x public_note: 949$z loc: 949$c ccode: 949$8 notforloan: 949$7 uri: 949$u copyno: 949$t price: 949$g replacementprice: 949$v itemcallnumber: 949$o quantity: 949$k budget_code: 949$l Now save the sysprefs 4) Navigate to acquisitions and go into a basket 5) Click Add to basket and select “From a new file” 6) Download the file attached to this bug 7) Import the file and when the job is complete click “Add staged files to basket” 8) Click the checkbox next to the record to display the items 9) Inspect the value for the "loc" field - the value of "AV" from the file has not been selected -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 35026] New: Refactor addorderiso2709.pl to use object methods
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35026 Bug ID: 35026 Summary: Refactor addorderiso2709.pl to use object methods 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: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org As part of the process to be added in bug 34355, the addorderiso2709.pl script should be refactored to make use of object methods that can then be re-used in a cron script for bug 34355 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 141

[Bug 36035] New: Wrong text colour in addorderiso2709.pl
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36035 Bug ID: 36035 Summary: Wrong text colour in addorderiso2709.pl 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: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org It looks like the datatables upgrade in bug 34913 has broken the css in addorderiso2709.pl. The values are no longer displaying in the form and there is a blue highlighted outline around the form -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 36139] New: Bug 35518 follow-up: fix AutoSwitchPatron
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36139 Bug ID: 36139 Summary: Bug 35518 follow-up: fix AutoSwitchPatron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.hafen(a)washk12.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 35518 moved some code blocks to after the call to get_user_and_template() so that userenv would be populated before it was needed. This caused a couple variables to be set before the AutoSwitchPatron block could prevent them from being set. Which broke AutoSwitchPatron functionality. This clears two variable so that AuthSwitchPatron works again. Test plan: 1. Ensure AutoSwitchPatron is turned on. 2. Select the card number of two patron accounts. 3. Find the first patron in circulation. 4. Enter the second patron's card number in the item barcode field to switch patrons. 5. Observe the error about item barcode not existing, and the patron did not switch. 6. Apply patch and restart services. 7. Enter the second patron's card number in the item barcode field again. 8. Observe that the patron was switched with no error about an invalid barcode. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 35518] New: Call to C4::Context->userenv happens before it's gets populated breaks code logic
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35518 Bug ID: 35518 Summary: Call to C4::Context->userenv happens before it's gets populated breaks code logic Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, nugged(a)gmail.com Depends on: 17798 We getting results from `C4::Context->userenv` on line 72: my $userenv = C4::Context->userenv; but `C4::Context->userenv` gets populated only far below in `get_template_and_user` call, line 142, this means that everything that we getting further from `$userenv` is empty. And more, because autovivification occurs for the `$userenv` at line 73: my $branch = $userenv->{'branch'} // ''; that does not cause any visible errors, but it causes malfunctions at places where $branch, $desk_id is used, and also where $userenv is accessed, at line 153: if (!C4::Auth::haspermission( $userenv->{id} , { circulate => 'force_checkout' } ) ). To check that we have undef and it gets autovivificated, let's add some dumps into code when we open any borrower, e.g. /cgi-bin/koha/circ/circulation.pl?borrowernumber=19, Let's dump $userenv before and after `$branch = $userenv->{'branch'} // '';` line: 72 my $userenv = C4::Context->userenv; 73 use Data::Dumper; 74 warn __LINE__, ' ', Dumper($userenv); 75 my $branch = $userenv->{'branch'} // ''; 76 warn __LINE__, ' ', Dumper($userenv); this gives in server logs: 74 $VAR1 = undef; 76 $VAR1 = {}; and also to check when `C4::Context->userenv` gets its real values, let's dump before and after the `get_template_and_user()` call at line 142 (line 145 if to continue above dumps code): 145 warn __LINE__, ' ', Dumper([C4::Context->userenv]); 146 my ( $template, $loggedinuser, $cookie ) = get_template_and_user ( ... 153 ); 154 warn __LINE__, ' ', Dumper([C4::Context->userenv]); this gives in server logs: 145 $VAR1 = []; 154 $VAR1 = [ { ... 'id' => 'admin', ... } ]; what depicts the whole bug. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17798 [Bug 17798] Checking out an item on hold for another patron prints a slip but does not update hold -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 38164] New: Translation process in stable releases is broken
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38164 Bug ID: 38164 Summary: Translation process in stable releases is broken Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: RM_priority Severity: blocker Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com, mtj(a)kohaaloha.com, tomascohen(a)gmail.com As discussed on bug 37303 we do now require yarn for running the translation scripts because of po2json. We need to fix this urgently as it means that production installations updating (and with security releases they should) can no longer install and update languages. We already had several reports in Mattermost and on the mailing list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[Bug 37183] New: Serials batch edit changes the expiration date to TODAY
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37183 Bug ID: 37183 Summary: Serials batch edit changes the expiration date to TODAY Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org Severity = Critical as data loss is imminent due to this bug Serials: 1) Add a new serial, visit: /cgi-bin/koha/serials/subscription-add.pl 2) Put a biblionumber in the 'record' field, i.e. '112'. Press 'next' and click 'ok' on the alert box 3) Fill all the required fields and click 'test prediction' 4) Fill the Subscription end date (= Expirations Date) 5) Click 'save subscription'. 6) Repeat steps 1-5 to create a second serial. Batch edit: 1) Visit serials and hit the 'Search' button: /cgi-bin/koha/serials/serials-home.pl 2) Click the 2 checkboxes for the 2 serials we created previously and click the new link that pops up 'edit selected serials'. 3) Click 'Save' without changing anything. 4) Go back to either of the serials, notice the value for expiration Date is changed to TODAY (Date of the batch edit). Visit: /cgi-bin/koha/serials/subscription-detail.pl?subscriptionid=1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 36832] New: Adding authority records is broken
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36832 Bug ID: 36832 Summary: Adding authority records is broken Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Keywords: RM_priority Severity: blocker Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org We get a 404 after opening a blank authority record and using Z39.50 to try to import a record and after manually filling out the form and submitting. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 38495] New: Cannot cancel background job (CSRF)
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38495 Bug ID: 38495 Summary: Cannot cancel background job (CSRF) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The operation to cancel a job needs to be cud-cancel and we need to submit as post -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 38056] New: Search term after deleting an authority shouldn't be URI encoded
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38056 Bug ID: 38056 Summary: Search term after deleting an authority shouldn't be URI encoded Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: MARC Authority data support Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 34478 Prior to the CSRF protection, deleting an authority record from search results built up a URL for a GET, and used the uri TT filter on the value param, which is where the search term you used to find the record gets passed to the script for reloading afterward. That was fine (though the use of the html filter on the other params was a bit sketchy, given that they were being stuffed into a URL, not displayed as HTML), but when https://git.koha-community.org/Koha-community/Koha/commit/62d9f73e9e3bfe7fb… switched from a GET to a form that POSTs, it retained the same escaping, so now we have a URI encoded value being put into a form input, passed over to the script which certainly isn't expecting that, and then stuffed back into the search box and searched for literally: if you do an authority search for "professional computing" and delete one of the results, the page that loads after the deletion is a search for "professional%20computing" Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 [Bug 34478] Full CSRF protection -- You are receiving this mail because: You are watching all bug changes.

1 15