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

[Bug 22038] New: When exporting account table to excel, decimal is lost
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '22

08 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22038 Bug ID: 22038 Summary: When exporting account table to excel, decimal is lost Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When you want to export a patron's account lines in Excel, the decimals are lost. So instead of having a fine of 3,75, the Excel file says the fine is 375. Note that I opened the Excel file in LibreOffice Calc. I'm not sure if that affects anything. Although I also opened the file in vim and got the same result: <c r="D2" s="63"><v>375</v></c><c r="E2" s="63"><v>375</v></c> To reproduce: 1) Find a patron with small fines (my patron had 3,75) or create some manual charges 2) In the patrons file, go to the Fines tab and then the Account tab 3) At the top of the account table, click on Excel 4) Open the file 5) Notice the fines are now multiplied by 100 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 23330] New: deleteditemsstocknumberidx should not be a unique index
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '22

07 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23330 Bug ID: 23330 Summary: deleteditemsstocknumberidx should not be a unique index 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, deleteditemsstocknumberidx is a unique index, which means that an item will fail to delete if its "Inventory number" already exists in the deleteditems table. Its counterpart itemsstocknumberidx was renamed to itemstocknumberidx in version 3.03.00.042 (dating from April/May 2011) and made non-unique. I've worked on Koha since early 2012 and only today have I had someone stung by this problem. They've been storing "Copy number" in "Inventory number" for some reason, and it's caught them out. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 20421] New: Inform staff that patron does have the title checked out during placing hold
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '22

06 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20421 Bug ID: 20421 Summary: Inform staff that patron does have the title checked out during placing hold 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: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 22344] New: Limits cannot contain parentheses
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '22

05 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22344 Bug ID: 22344 Summary: Limits cannot contain parentheses Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au Target Milestone: --- I've noticed an authorised value of category LOC can't have parentheses in it. If it does, the search silently fails... I'm guessing it doesn't even make it from the ZOOM library in Koha over the connection to Zebra. I'm going to explore in a moment, but people have noticed this and kind of worked around it with #5693 and #7031. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 23457] New: Placing holds on multiple items in a bib record
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '22

05 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23457 Bug ID: 23457 Summary: Placing holds on multiple items in a bib record 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I am not finding a straight forward way to place multiple items in a bib record on hold at once, if there is a way at all. We have multiple items in the same record that we reserve for various reasons. However, we have to place them on hold, one at a time. If the system allows you to place multiple holds on items in a record, there should be a way to place them all at once. Some way to select, either with check boxes or the cart, and place them on hold. This method should also include a way to set individual notes for each hold, or set one note and duplicate to the rest. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 15750] New: Koha offline circulation Firefox addon does not prompt to clear old entries
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '22

04 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15750 Bug ID: 15750 Summary: Koha offline circulation Firefox addon does not prompt to clear old entries Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: contribs.koha-community.org Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: fridolin.somers(a)biblibre.com, koha-bugs(a)lists.koha-community.org, testopia(a)bugs.koha-community.org If this description is up to date: https://lists.katipo.co.nz/public/koha/2012-May/032825.html ...when I open the KOCT for the first time in a browser session (?) I should be prompted to clear old transactions. I don't find this to be the case. I get no prompt. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. You are on the CC list for the bug.

1 1

[Bug 17841] New: Can't use indexname "acqdate, st-date-normalized" in keyword search
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '22

01 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17841 Bug ID: 17841 Summary: Can't use indexname "acqdate,st-date-normalized" in keyword search Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org It is possible to search for acquisition date from the advanced search in staff. But if you try to use the index name for an 'expert search' in the keyword search field, no results will come up. Example: Advanced search > acquisition date: 2016-12* (or whatever works for you) This should give correct results. Enter acqdate,st-date-normalized: 2016-12* into the keyword search - no results will appear. Something seems to be missing in order to make it possible to construct the same search manually. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 18846] New: Fund list on 'aquisitions statistics' page shows wrong values
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '22

30 Mar '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18846 Bug ID: 18846 Summary: Fund list on 'aquisitions statistics' page shows wrong values 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org To test: - Create a budget with some funds - Duplicate the budget - You should now have 2 budgets with the same fund codes and descriptions for each - Check the fund list on the reports > aquisitions statistics page - Verify the list looks correct - you should see all funds once - Alter the description of one of your funds and save - Check the fund list again after reloading the page: The changed fund will appear "doubled up" with the same (old or new) description -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 23081] New: Item search : Filter for Items with Zero Checkouts Returns No Results
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '22

30 Mar '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23081 Bug ID: 23081 Summary: Item search : Filter for Items with Zero Checkouts Returns No Results Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When conducting an item search, if I set the checkout count to = 0, I get "No data available in table" (and there are most definitely items without any checkouts). If I conduct a search that returns results (without filtering by checkout count), and then enter 0 into the box on the search results screen, I get results with 10 checkouts. I expected to get the items with 0 checkouts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 22993] New: Messaging preferences not set for patrons imported through API
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '22

28 Mar '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22993 Bug ID: 22993 Summary: Messaging preferences not set for patrons imported through API Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hans.palsson(a)hkr.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- It appears that from 18.11.03 (maybe earlier), patrons that are created/imported through the API does not get messaging preferences set as specified in the system preferences ("Default messaging preferences for this patron category"). This should work in the same way that messaging preferences are set for patrons created in the GUI. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30