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

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '23

21 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff --- Comment #102 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- We'd like a third party to do the sign-off. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '23

21 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 Barbara Johnson <barbara.johnson(a)bedfordtx.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #101 from Barbara Johnson <barbara.johnson(a)bedfordtx.gov> --- Thanks to Agustin for rebasing this one so that it could be tested. I noticed that Tomás signed off on this one (thank you!) but the status hadn't been changed so I updated it to signed off. Looking forward to this functionality! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 30483] New: Should issues.borrowernumber and issues.itemnumber be NOT NULL ?
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '23

21 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30483 Bug ID: 30483 Summary: Should issues.borrowernumber and issues.itemnumber be NOT NULL ? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Sync problem between structure and dbrevs. For old prod databases only (that passed the 3.05 dbrevs) Note that I did not expect such a difference in a vital table like issues ! update $DBversion = "3.05.00.009"; $dbh->do("ALTER TABLE issues MODIFY COLUMN borrowernumber int(11) NOT NULL"); $dbh->do("ALTER TABLE issues MODIFY COLUMN itemnumber int(11) NOT NULL"); Current structure allows them to be NULL. I wonder if that is correct. An issue should have a borrower and an item, right? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 30172] New: BackGround jobs failing due to race condition
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30172 Bug ID: 30172 Summary: BackGround jobs failing due to race condition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 We are receiving reports from production of background jobs that show as 'new' in the database that are not being processed. There are no errors or exceptions relating to enqueueing from the broker We do see in the worker-output.log: Can't call method "process" on an undefined value at /usr/share/koha/bin/background_jobs_worker.pl line 80. In Koha/BackGroundJob.pm: 94 sub enqueue { ... 104 $self->_result->result_source->schema->txn_do( 105 sub { 106 $self->set( 107 { 108 status => 'new', ... 114 } 115 )->store; ... 121 try { 122 my $conn = $self->connect; ... 128 $conn->send_with_receipt( { destination => sprintf("/queue/%s-%s", $namespace, $job_type), body => $json_args } ) 129 or Koha::Exceptions::Exception->throw('Job has not been enqueued'); 130 } catch { ... 138 ); ^^End of transaction What appears to be happening is that: 1 - The transaction is begun 2 - Job info is stored internally, but not committed 3 - the job is being sent to Rabbit 4 - Rabbit attempts to process the job, and fails as it cannot find the data in the DB 3 - The transaction completes We are left with jobs sitting at 'new' with no errors and they are never processed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 72

[Bug 11340] Make the 'print summary' a custom slip/notice
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11340 Cheryl <clackman(a)fargolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clackman(a)fargolibrary.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32077] New: 'Close and Export as PDF' doesn't work on basketgroups page
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32077 Bug ID: 32077 Summary: 'Close and Export as PDF' doesn't work on basketgroups page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If you attempt to 'Close and Export as PDF' a basketgroup from the open basketgroups tab of a vendor basketgroup page the action fails and an error is shown in the console. Uncaught ReferenceError: closeandprint is not defined onclick http://mrdev-zebra-staff.koha-ptfs.co.uk/cgi-bin/koha/acqui/basketgroup.pl?… basketgroup.pl:1:1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 31056] New: Unable to 'Close and export as PDF' a basket group
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31056 Bug ID: 31056 Summary: Unable to 'Close and export as PDF' a basket group Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 The button to 'Close and export as PDF' in the basket groups page seems to be broken. To test: 0) Make sure to have budgets, funds, and vendors set up in the acquisitions module 1) Go to Acquisitions 2) Search for a vendor 3) Create a new basket 4) Add materials to the basket 5) Close the basket (do NOT create a basket group at this time) 6) Click on the Basket groups tab on the left 7) Create a new basket group and add the basket (do NOT check the 'close basket group' box) 8) From the open basket groups list, click 'Close and export as PDF' --> Nothing happens In order to export as PDF, you have to edit the basket group, check the 'Close basket group' box, save and then export as PDF. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 33283] New: Curbside pickups - Rogue curbside pickups
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33283 Bug ID: 33283 Summary: Curbside pickups - Rogue curbside pickups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Not sure if this is something that would happen IRL, but I have some rogue curbside pickup appointments in my installation that I can't remove except by going into the database. I think maybe it's the filters in the curbside pickup lists that are a bit too restrictive, removing anything that is not today? Not sure how to replicate this one except make appointments and leave them there... In the patron's account, I have two notifications about curbside pickups https://snipboard.io/whQPBJ.jpg There is nothing in the "To be staged" report https://snipboard.io/GTkiNZ.jpg There is no "Delivered" report except "Delivered today", which is also empty https://snipboard.io/jdF8gW.jpg The patron doesn't currently have any holds, so I can't cancel the holds to cancel the pickups. In the database, for this patron select * from curbside_pickups where borrowernumber = 37 \G; *************************** 1. row *************************** id: 9 borrowernumber: 37 branchcode: CPL scheduled_pickup_datetime: 2023-02-04 13:00:00 staged_datetime: NULL staged_by: NULL arrival_datetime: NULL delivered_datetime: NULL delivered_by: NULL notes: *************************** 2. row *************************** id: 23 borrowernumber: 37 branchcode: CPL scheduled_pickup_datetime: 2023-02-06 13:40:00 staged_datetime: 2023-02-06 11:37:52 staged_by: 51 arrival_datetime: 2023-02-06 11:39:20 delivered_datetime: 2023-02-06 11:39:35 delivered_by: 51 notes: 2 rows in set (0.000 sec) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 26413] New: Reading history management from staff client.
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26413 Bug ID: 26413 Summary: Reading history management from staff client. Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently reading/circulation history tracking is controlled by settings in the Patron Categories with the Default Privacy options. Setting the Default Privacy setting to 'Default' means that keeping a reading history becomes an opt-out where a patron has to turn it off in their patron account from the OPAC. Setting the Default Privacy setting to 'Never' means that keeping a reading history becomes an opt-in where a patron has to turn it on through their patron account. This becomes a problem either way when working with patrons who are unable or unwilling to login to their patron account to select their preferred option. It would be nice to have an option in the patron account details that allows a staff member to flip the switch for the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 33251] New: POST /biblios incorrect response
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33251 Bug ID: 33251 Summary: POST /biblios incorrect response Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com It is now returning `{ id => $biblionumber }` which seems wrong. And it is not setting the Location header as the guidelines require. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2