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

[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 16935] New: launch export_records.pl with deleted_barcodes param fails
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '20

07 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16935 Bug ID: 16935 Summary: launch export_records.pl with deleted_barcodes param fails Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: stephane.delaune(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz when I launch /home/koha/src/misc/export_records.pl with this command line : ~/src/misc/export_records.pl --date=`date +%d/%m/%Y` --deleted_barcodes --filename=/home/koha/test I've got this error message : DBD::mysql::db selectall_arrayref failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 4 [for Statement " ( SELECT DISTINCT barcode FROM deleteditems WHERE deleteditems.biblionumber = ? "] at /home/koha/src/misc/export_records.pl line 189. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 20283] New: Editing a course item for an inactive course affects the item fields directly
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '20

07 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20283 Bug ID: 20283 Summary: Editing a course item for an inactive course affects the item fields directly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When adding an item to course reserves the values in the items and course_items tables are swapped e.g. items.holdingbranch becomes course_items.holdingbranch and vice versa. When a course is marked inactive, the values are swapped back. When editing an inactive course we modify item values directly. This seems to be because we don't check if the course is active or not. When a course is active ti is correct to modify the items, but if inactive we should only modify course_items To recreate: 1 - Find/create an item with existing values for: item type collection code shelving location holding library staff/public note 2 - Add this item to an active course in course reserves, change all the values 3 - Make the course inactive 4 - Edit the course item, changing all the values 5 - Save and note the changes did not populate to the course reserve 6 - View the item, note the item was changed 7 - Edit the course again, note the dropdowns show the course item values, not the new item values I think we have two options: 1 - Check if a course it active when modifiying a course reserve and adjust the correct table 2 - Don't allow editing of items for inactive courses -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 16535] New: Add the date on which the suggestion was managed on Purchase suggestions tab
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '20

31 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16535 Bug ID: 16535 Summary: Add the date on which the suggestion was managed on Purchase suggestions tab Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, It would be helpful if the date on wich the suggestion was managed was added on Purchase suggestions tab on borrower account. There is just who managed the suggestion. This can be as like date on table in suggestion.pl Regards Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 17697] New: Notes Blacklist only blacklists fields on the OPAC main detail view ( not the OPAC MARC display)
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '20

20 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17697 Bug ID: 17697 Summary: Notes Blacklist only blacklists fields on the OPAC main detail view (not the OPAC MARC display) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org To replicate: Add a note to a field in a record (let's say 500) Verify the note shows in both the OPAC Detail and OPAC MARC views Add a blacklist entry to the NotesBlacklist system preference for field 500 Verify the note does not appear on the OPAC detail Verify the note DOES appear on the OPAC MARC detail. Blacklisted notes shouldn't display anywhere in the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 19426] New: Single Branch Exception to a Repeating Holiday Affects Closed Branches
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '20

17 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19426 Bug ID: 19426 Summary: Single Branch Exception to a Repeating Holiday Affects Closed Branches Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: cslone(a)camdencountylibrary.org QA Contact: testopia(a)bugs.koha-community.org Scenario: You have some branches that are open every day of the week, and several that are closed on Sundays all year round. Due to the fact that these Sunday closures do not affect every location, each branch that is closed on Sundays has its own repeating holiday set up. However, if you add an exception for a single branch to this holiday it will affect the due dates for the items being checked out from any of the other branches that are still closed that day. This is despite the fact that the calendar for the closed branches still lists them as being closed. To test: 1.) Set the "useDaysMode" preference to "calculate the due date using the calendar to push the due date to the next open day." 2.) Create a repeating holiday (individually) for two or more branches. 3.) Add an exception to this repeating holiday for one of the branches. 4.) Confirm that the exception is shown only for the intended branch. 5.) Log-in to the branch to which you did not add the calendar exception and checkout an item that should get pushed forward to be due the day after the repeating holiday - For example, you have the repeating holidays on Sunday, are logged-in on a Thursday, and checkout an item that circulates for three days, which should then get pushed from being due on Sunday to Monday 6.) Confirm that the item was made to be due on the repeating holiday for that branch instead of the day after -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 19026] New: System Preferences that include a list of fields is not displayed correctly in Chrome
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '20

11 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19026 Bug ID: 19026 Summary: System Preferences that include a list of fields is not displayed correctly in Chrome Change sponsored?: --- Product: Koha Version: 16.11 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Browser compatibility Assignee: oleonard(a)myacpl.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 65430 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=65430&action=ed… This is how it is displayed in Chrome. Currently in the latest version of Chrome: 60.0.3112.78 the system preference OPACSuggestionMandatoryFields does not show the list of fields in the display. This is also the case in these system preferences : OPACadvsearchmoreoptions, Opacadvsearchoptions, opacexportoptions- there may be more. >From the browser of Firefox, they display correctly. Included screen shots of this behavior. -- You are receiving this mail because: You are watching all bug changes.

1 7