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

[Bug 35924] New: The 'checkin slip' button should not be available for patrons whose privacy is set to never
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35924 Bug ID: 35924 Summary: The 'checkin slip' button should not be available for patrons whose privacy is set to never 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a patron anonymizes their checkins, the checkin slip cannot retrieve any info to print the checkin slip. We should not show the button in this scenario -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 36101] New: Deleting an item removes the itemnumber from old_reserves when it should not
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36101 Bug ID: 36101 Summary: Deleting an item removes the itemnumber from old_reserves when it should not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: lmstrand(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Unless there's a good reason for this data loss, the itemnumber should be preserved in old_reserves after deleting an item. To reproduce: 1.1 Create an item level hold or a hold on a biblio with just one item for it 1.2 Cancel the hold 1.3 Check old_reserves, the itemnumber for the reserve is present 1.4 Delete the item linked to the reserve 1.5 Check old_reserves again, the itemnumber is now NULL or: 2.1 Create a hold for a biblio with multiple items 2.2 checkin one of the items linked to the biblio the reserve was made for and confirm the hold 2.3 Cancel the hold 2.3 Check old_reserves, the itemnumber for the reserve is present 2.4 Delete the item linked to the reserve 2.5 Check old_reserves again, the itemnumber is now NULL The constraint that does the deletion from old_reserves-table when an item is deleted: CONSTRAINT `old_reserves_ibfk_3` FOREIGN KEY (`itemnumber`) REFERENCES `items` (`itemnumber`) ON DELETE SET NULL ON UPDATE SET NULL This should be removed. After removal the itemnumber does not get deleted from the old_Reserves table when the item is deleted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 32029] New: Automatic item modifications by age missing biblio table
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32029 Bug ID: 32029 Summary: Automatic item modifications by age missing biblio table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In automatic item modifications by age missing, conditions can be on columns of tables items or biblioitems. Table biblio is missing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 36170] New: Wrong warning in memberentry
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36170 Bug ID: 36170 Summary: Wrong warning in memberentry Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org - warn "Patron creation failed! - $@"; # Maybe we must die instead of just warn $@ is never set here, we need $_ (inside a try-catch) -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 31427] New: Automatic renewal too_many error is confusing in notices
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31427 Bug ID: 31427 Summary: Automatic renewal too_many error is confusing in notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I am not sure if this error, too_many, should be removed or just handled differently. It is confusing for patrons, here is why: Day 1, a patron gets an email telling them an item has been successfully renewed. It is auto renewal 5/5, the item will no longer renew. Day 2: The next a patron receives a new auto renewal message telling them the same item, from yesterday, cannot be renewed. Patrons are confused. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 69

[Bug 36124] New: Port default Article Request notices to Template Toolkit syntax
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36124 Bug ID: 36124 Summary: Port default Article Request notices to Template Toolkit syntax Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: roadmap_24_05 Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Blocks: 15278 There are 6 notices associated with Article Requests, whose default text still uses "hungry alligator" syntax: AR_CANCELED AR_COMPLETED AR_PENDING AR_REQUESTED AR_PROCESSING AR_SLIP The notices are pretty similar to each other, so it might make sense to update them all together. If not we can always split out another bug report. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 [Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30546] New: Initial articles not ignored when sorting by the summary column in the pending_orders table
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30546 Bug ID: 30546 Summary: Initial articles not ignored when sorting by the summary column in the pending_orders table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org Bug 29570 (Unable to sort summary column of pending_orders table on parcel.pl by summary column) added sorting capability back to the summary column for the pending orders table. However, search results do not ignore the articles 'a', 'an' and 'the' when displaying the results. I don't believe it used to be like this and other areas in acquisitions, such as invoices, ignore initial articles when displaying search results. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 29570] New: unable to sort pending_orders table on parcel.pl by summary column
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29570 Bug ID: 29570 Summary: unable to sort pending_orders table on parcel.pl by summary column 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Have a pending order and go to: /cgi-bin/koha/acqui/parcel.pl?invoiceid=X Most of the columns you are able to sort but they summary column you cannot, it has the 'sorting_disabled' class. Librarians with large orders need to be able to sort by Summary. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 35819] New: "No job found" error for BatchUpdateBiblioHoldsQueue (race condition)
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Bug ID: 35819 Summary: "No job found" error for BatchUpdateBiblioHoldsQueue (race condition) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29346 A BatchUpdateBiblioHoldsQueue job is triggered from AddRenewal if RealTimeHoldsQueue is set. It is executed inside a transaction and the worker can receive the job to process before the transaction has been committed (and so before the job exists in the DB). The call stack is: opac-renew: AddRenewal In C4::Circulation::AddRenewal 3234 $schema->txn_do(sub{ 3302 $item_object->store({ log_action => 0, skip_record_index => 1 }); In Koha::Item->store 223 Koha::BackgroundJob::BatchUpdateBiblioHoldsQueue->new->enqueue( 224 { 225 biblio_ids => [ $self->biblionumber ] 226 } 227 ) unless $params->{skip_holds_queue} or !C4::Context->preference('RealTimeHoldsQueue'); To recreate: Turn on RealTimeHoldsQueue Check an item in to a patron At the OPAC, renew the checkout => Job 109 not found, or has wrong status main:: /kohadevbox/koha/misc/workers/background_jobs_worker.pl Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29346 [Bug 29346] Real-time holds queue update -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 68

[Bug 36076] New: paycollect.tt is missing permission checks for manual credit and invoice
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36076 Bug ID: 36076 Summary: paycollect.tt is missing permission checks for manual credit and invoice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In members/pay.tt one can see permission checks for manual credit and invoice : CAN_user_updatecharges_manual_invoice CAN_user_updatecharges_manual_credit This is missing from members/paycollect.tt. HTML is also missing classes manualcredit and manualinvoice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13