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

[Bug 37924] New: Some UNIMARC subfields of 995 field are indexed in wrong indexes
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37924 Bug ID: 37924 Summary: Some UNIMARC subfields of 995 field are indexed in wrong indexes Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org After https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30373 the meaning of some subfields of 995 field (used for items) have changed. The configuration of Zebra and Elasticsearch must take those changes into account. 6 changes must be made : - 995$3 is indexed with zebra in "withdrawn" index. It should be "restricted" index - it is not indexed in Elasticsearch. It should be indexed in Elasticsearch "restricted" index - 995$8 is indexed in Elasticsearch in "ccode" index. It should be "coded-location-qualifier" index - it is not indexed in Zebra. It should also be indexed in Zebra "coded-location-qualifier" index - 995$a is indexed in "homebranch" index. It should be "acqsource" index - it is not indexed in Elasticsearch. it should also be indexed in Elasticsearch "acqsource" index -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 37717] New: Add ability to batch modify fund used in orders
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37717 Bug ID: 37717 Summary: Add ability to batch modify fund used in orders Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 We need a way to batch modify the fund on existing orders. Our use case is that we have existing orders in our current fiscal year which we know will not fill either due to backorders or because the pub date was pushed into the future. We created a budget for the next fiscal year. So we now have two active budgets and want to start moving orders into the newly created budget so that we can better determine the amount of money we truly have available for the remainder of the current fiscal year. We use a report which includes items that we want to move. It then takes 12 steps to move each order from the current budget into the new budget. This is our process: 1. click on biblionumber for title from report 2. select View record 3. click on the Acquisitions details tab 4. click on the basket name 5. reopen the basket 6. find the order 7. click on the Modify button 8. scroll down the page until you find the fund dropdown 9. click on the fund dropdown 10. select the new fund from the next fiscal year 11. hit the Save button 12. close the basket And then do it all again for the next order. We could probably cut this down by a few steps if we modified our report to include the basket but we would still have to move each order one by one which takes a lot of time. For example this morning, I moved 24 orders to next fiscal year's budget. It took 12 steps to do each one so I performed 288 actions in order to complete this process. A batch operation where the user could select items to be moved into a different budget would be a huge time saver. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35672] New: Update and Run SQL button should save changes even if report fails to run
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35672 Bug ID: 35672 Summary: Update and Run SQL button should save changes even if report fails to run Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 23824 To recreate: - have a report that works, example "SELECT 1+1" - edit your report to have a SQL error, example "SELECT 1 plus 1" - click Update and Run SQL, get an error message due to SQL error - click to edit report again, confirm none of your changes were saved - re-edit your report to contain the SQL error - click Update, confirm your report saves with an error When using Update and Run, we should save the SQL even if it has an error, just as we do with the old Update button. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23824 [Bug 23824] Add a 'Save and run' button to reports -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 38036] New: Warn staff that patron has reached maximum holds
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38036 Bug ID: 38036 Summary: Warn staff that patron has reached maximum holds Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: chanel.wheeler(a)yavapaiaz.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If there is a limit to the number of holds per the circ rule, staff should be alerted with messaging (e.g. Patron has reached maximum 2 holds for account) when placing holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 38004] New: Convert item search result to SQL query
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38004 Bug ID: 38004 Summary: Convert item search result to SQL query Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: laura(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be very cool to be able to convert item search results (including any custom search fields) to an SQL query that could be saved as a new report, perhaps as an output option. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 38034] New: Add ability to process includes in process_tt
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38034 Bug ID: 38034 Summary: Add ability to process includes in process_tt Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 33030 added a generic way to process templates outside of letters. It would be beneficial to also allow processing includes so that we can translate values when processing TT -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33083] New: Handle generic collection of records methods
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33083 Bug ID: 33083 Summary: Handle generic collection of records methods 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: agustinmoyano(a)theke.io CC: tomascohen(a)gmail.com Add a generic way to handle methods for collections of records -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 38029] New: Fix POD for bulkmarcimport.pl --delete --authorities
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38029 Bug ID: 38029 Summary: Fix POD for bulkmarcimport.pl --delete --authorities Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz POD says: =item B<-d, --delete> Delete EVERYTHING related to biblio in koha-DB before import. Tables: biblio, biblioitems, items What happens if you combine this with --authorities? One interpretation could be that nothing will happen. Another could be that you delete all biblios, even if you are importing authorities. The code looks like this: if ($delete) { if ($biblios) { print "Deleting biblios\n"; $dbh->do("DELETE FROM biblio"); $dbh->do("ALTER TABLE biblio AUTO_INCREMENT = 1"); $dbh->do("DELETE FROM biblioitems"); $dbh->do("ALTER TABLE biblioitems AUTO_INCREMENT = 1"); $dbh->do("DELETE FROM items"); $dbh->do("ALTER TABLE items AUTO_INCREMENT = 1"); } else { print "Deleting authorities\n"; $dbh->do("truncate auth_header"); } $dbh->do("truncate zebraqueue"); } So it should do the right thing. The POD should say that --delete --authorities will clean out the auth_header table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 38028] New: Patron name and DOB cleared when guarantor account added that isn't able to be a guarantor
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38028 Bug ID: 38028 Summary: Patron name and DOB cleared when guarantor account added that isn't able to be a guarantor Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: danyonsewell(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you add a Guarantor to a Patron's account and then go and change the patron code of that Guarantor to one that isn't able to be a guarantor and attempt to edit the guarantee patron's account information it will wipe the patron's first, middle and last name along with the DOB of the account. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 30581] New: Items should show on the Holds Queue and Holds to Pull even if they have requested transfers
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '24

29 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30581 Bug ID: 30581 Summary: Items should show on the Holds Queue and Holds to Pull even if they have requested transfers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 23092 In bug 23092 Koha added the idea of a transfer that has been requested but not yet sent. The Holds Queue and and Holds to Pull will not show titles/items that have transfers that are not either complete or cancelled, so staff are not alerted to holds on Available items if those items have requested transfers on them. But if the item is checked in, it will trigger the hold. We should show items in the Holds Queue and Holds to Pull if they have transfers that are requested but not sent. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23092 [Bug 23092] Add 'daterequested' to the transfers table -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19