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

[Bug 30799] New: Add REST API route to update biblio metadata
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30799 Bug ID: 30799 Summary: Add REST API route to update biblio metadata Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: REST API Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com CC: tomascohen(a)gmail.com Blocks: 17371 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17371 [Bug 17371] Add routes for biblios [OMNIBUS] -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 28201] New: Add API routes to update and create biblio record
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28201 Bug ID: 28201 Summary: Add API routes to update and create biblio record Change sponsored?: --- Product: Koha Version: master Hardware: All URL: https://wiki.koha-community.org/wiki/Biblios_endpoint_ RFC OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi CC: tomascohen(a)gmail.com Blocks: 17371 We need PUT and POST API routes to modify and create biblio records. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17371 [Bug 17371] Add routes for biblios [OMNIBUS] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 27211] New: Shelving locations for holds
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27211 Bug ID: 27211 Summary: Shelving locations for holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Every library handles holds differently, but one thing remains the same through most, if not all...when a hold is triggered, it waits somewhere in the building. Some libraries might have more than one shelving location. One issue that has always been a problem for libraries that have automatically expired holds, or any library that has a cancelled hold. Unless someone is going through each of the holds on the hold shelf daily, how do you find the item? If you look up an held item that has automatically expired (guessing on this, as we don't do this), or an item that is cancelled, the item shows the regular shelving location and that it is AVAILABLE. This is of no help to staff or the patron. One solution might be to use the CART feature, and update the temporary location to reflect a given shelving location for holds. There are a few issues for using this feature: 1) the CART location reverts back to the permanent shelving location after X amount of days. This would have to be overridden to stick until the item is actually not being held and is checked in, and then go through the regular CART routine, if any. 2) When triggering a hold, the hold would have to know which shelving location is being used. We could either define a default location that could be changed to a select few locations (maybe a HOLDLOC table?), so the default could be used without extra steps, OR even further, a default shelving location defined for each desk (I know the desk feature is part of an upcoming Koha upgrade). If staff don't want the public to know that the item is on a public hold pickup shelf, the OPAC description could simply read "See staff for assistance". Thoughts? Is this doable? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 17480] New: UpdateNotForLoanStatusOnCheckin preference requires space after colon
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17480 Bug ID: 17480 Summary: UpdateNotForLoanStatusOnCheckin preference requires space after colon Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 11629 YAML requires that there be a space after a colon, so the UpdateNotForLoanStatusOnCheckin preference does too: -1:0 will not work -1:<space>0 will work We should either handle this gracefully for the user (preferable, since this preference will only use numeric values), or update the preference's description to highlight the requirement. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11629 [Bug 11629] Add ability to update not for loan status on checkin -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 21700] New: Additional Patron information on purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '23

21 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21700 Bug ID: 21700 Summary: Additional Patron information on purchase suggestions Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org A library has suggested that it would be helpful to view the card type of the patron when managing purchase suggestions. For instance, if an item is not going to be purchased, the library would attempt to ILL the item, but since not all patron categories are eligible for ILLs, knowing the patron category from the beginning of the review process would be helpful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[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 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 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