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

[Bug 20576] New: t/db_dependent/Koha_SearchEngine_Elasticsearch_Search.t fails if Elasticsearch is configured but not running
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '20

19 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20576 Bug ID: 20576 Summary: t/db_dependent/Koha_SearchEngine_Elasticsearch_Search. t fails if Elasticsearch is configured but not running Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org Similar to bug 18738, except with Koha_SearchEngine_Elasticsearch_Search.t -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 19046] New: IntranetCatalogSearchPulldown doesn' t retain last selection
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '20

19 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19046 Bug ID: 19046 Summary: IntranetCatalogSearchPulldown doesn't retain last selection Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client 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 On the OPAC if you have the pulldown enabled and perform a 'Title' search, this selection carries over. On the staff client the default is always 'Keyword' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 15770] New: Number::Format issues with large numbers
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '20

18 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15770 Bug ID: 15770 Summary: Number::Format issues with large numbers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In my database I have some large numbers in some database columns (categories.enrolmentfee for instance), because of TestBuilder I think. In that case, this cause admin/categories.pl to die with the following error message: Template process failed: undef error - round() overflow. Try smaller precision or use Math::BigFloat at /home/koha/src/Koha/Number/Price.pm line 44 This shouldn't happen in real life, but as Koha allows to enter such big numbers, this should probably be fixed. Steps to reproduce: 1. Go to Admin » Categories 2. Click on "New category" button 3. Fill in the required field and set enrolment fee to a big number like 123456789012345 (15 digits seem to be the minimum to reproduce the bug) 4. Save 5. Boom! -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 20154] New: stay in the open tab when going into edit mode
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '20

17 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20154 Bug ID: 20154 Summary: stay in the open tab when going into edit mode Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, When we consult an authority in the authorities module, it would be nice too stay in the tab that are actually open when we switch to edit mode. Currently when you consult an authority notice and you open a tab (for exemple the tab 2) if you switch to the edit mode we will automaticaly arrive at the record in edit mode but with tab "0" open. Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 18947] New: Active Directory LDAP authentication broken
by bugzilla-daemon＠bugs.koha-community.org 15 Aug '20

15 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18947 Bug ID: 18947 Summary: Active Directory LDAP authentication broken Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: helpdesk(a)neci.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Commit 68c365ea8ab536a85d92d3769b0bbaa0e1691116 introduced the following line in Auth_with_ldap.pm: $ldap->{anonymous_bind} = 1 unless $ldapname && $ldappassword; There is no comment in the code or the Git commit log as to why. This change silently overrides the settings in koha-conf.xml and causes a previously functional setup with LDAP authentication against Active Directory to fail unless koha-conf.xml defines values for <user> and <pass>. As user and pass are only used if auth_by_bind and anonymous_bind are both false, their values should not come into play in the other cases. Prior to this change, KOHA would bind against AD with the user supplied credentials, as expected. With the change, KOHA attempts an anonymous bind and then tries to search for the supplied user name. As there was no valid bind in place, AD rejects the attempt. Workaround: enter some value for <user> and <pass> in the ldapserver configuration block. These do not have to be real credentials as KOHA will not attempt to use them now that auth_by_bind has priority again. Note: there is an apparent duplicate attempt to do the same further down, by setting $config{anonymous} to ($ldapname and $ldappassword) ? 0 : 1, although that key is not used anywhere in Auth_by_ldap.pm -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 19780] New: Actual price is not updated after it has been amended post receiving an order
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '20

14 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19780 Bug ID: 19780 Summary: Actual price is not updated after it has been amended post receiving an order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The steps to replicate this bug are as follows: 1. Create an order and set the actual price to 9.00 2. Receieve the order changing the actual price value to 10.00. This is to represent the librarian accidentally entering in a different actual price value at receival. 3. Modify the actual value by clicking on the order line. The order page will appear and notice the actual price of 10.00 is displayed. Change this actual price value to 9.00 and save. 4.View invoices and notice that the actual price displayed for the order is still 10.00 (set in step 2) when it should be 9.00 -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 21231] New: BlockReturnofLostItems does not prevent lost items being found
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '20

14 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21231 Bug ID: 21231 Summary: BlockReturnofLostItems does not prevent lost items being found Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com When the syspref BlockReturnOfLostItems is set to Block, the item is blocked from being returned, but is still considered found -- it's set to lost=0 and a refund is applied to the patron (if circ rules allow). The item can then be checked in a second time and returned as it is no longer lost. To test: - set an item to lost - set BlockReturnOfLostItems to Block - check the lost item in - Koha says item cannot be returned but also item was lost, is now found - check the item in again -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 24610] New: Let user switch between 'Pay' and 'Write off' mode
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '20

13 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24610 Bug ID: 24610 Summary: Let user switch between 'Pay' and 'Write off' mode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In patron's accounting section, under 'Make a payment' tab, you have the choice between 'Pay' and 'Write off'. It takes you to another form, but once there you cannot change mode. You have to click on Cancel, re-select the lines you had selected (if you made a selection) and click on the right button. This bug will add a way to switch between 'Pay' and 'Write off' mode -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 22987] New: Add biblioimages.timestamp
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '20

13 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22987 Bug ID: 22987 Summary: Add biblioimages.timestamp Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- It might be interesting to be able to see when an image was last updated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 24474] New: Lost items that are checked out are always returned
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '20

10 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24474 Bug ID: 24474 Summary: Lost items that are checked out are always returned Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This was a bug introduced by Bug 22982. "Hey all, this patch is causing problems for some of our libraries because it's been assumed that lost items with no attached charge should automatically be returned. This is not always the desired behaviour - we have one case where the library wants to keep lost items on a patron's record, and another case where a checked out lost item will be renewed, but the amount outstanding is zero, so the item gets returned. These are edge cases, but the assumptions in this patch do not consider them, and are causing problems. Is there a workaround? Or perhaps a better way of doing this patch that can allow for the cases of 'renewing a lost item' or 'wanting to keep a lost item on the checkouts record'? A solution that avoids doing circulation actions in the accounts modules as this patch does would be ideal." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 99