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

[Bug 38044] New: Move warning about multiple image sources to be more visible
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38044 Bug ID: 38044 Summary: Move warning about multiple image sources to be more visible 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The warning NOTE: you can only choose one source of cover images from below, otherwise Koha will show the images from all sources selected. appears in the "All" section of System preferences > Enhanced content. This makes it look like it only applies to that section (the two FRBR sysprefs which have nothing to do with cover images), and with translations, the section moves around so it's not always at the top. For example, in French, the section is named "Tous", and appears in last place. Therefore, the warning is not visible unless you scroll all the way down. I wonder if we could move it so that it's above all the sections? Maybe in a blue box like the other messages of the same type? Or maybe repeat it in only the cover images sections (Amazon, local, etc.)? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9181] Add patron messaging preferences to batch patron modification tool
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9181 George Williams (NEKLS) <george(a)nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |george(a)nekls.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29554] New: No itemtype for neworderempty.pl
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29554 Bug ID: 29554 Summary: No itemtype for neworderempty.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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org neworderempty contains: # Get the item types list, but only if item_level_itype is YES. Otherwise, it will be in the item, no need to display it in the biblio my @itemtypes; @itemtypes = Koha::ItemTypes->search unless C4::Context->preference('item-level_itypes'); I would argue that we should always fetch the itemtypes here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[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