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

[Bug 22606] New: Memcached Issues after Upgrade
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '20

08 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22606 Bug ID: 22606 Summary: Memcached Issues after Upgrade Change sponsored?: --- Product: Koha Version: 18.11 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: mehmet.akgul(a)mirakil.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- After either upgrading to or directly installing Koha ver. 18.xx anytime I try to install a language pack, I get the following error: Connection to the memcached servers '_MEMCACHED_SERVERS_' failed. Are the unix socket permissions set properly? Is the host reachable? If you ignore this warning, you will face performance issues. Use of uninitialized value $pref_name in concatenation (.) or string at /usr/share/koha/misc/translator/LangInstaller.pm line 197. Use of uninitialized value $pref_name in concatenation (.) or string at /usr/share/koha/misc/translator/LangInstaller.pm line 239. On my /etc/apache2/sites-enabled/koha.conf I have set the following lines to opac and intranet, and on the about page it says memcached is running SetEnv MEMCACHED_SERVERS "127.0.0.1:11211" SetEnv MEMCACHED_NAMESPACE "koha" SetEnv MEMCACHED_SERVERS "127.0.0.1:11211" SetEnv MEMCACHED_NAMESPACE "koha-yonetim" I also can not use most of management module and opac module after the upgrade, like borrowing. Below is one such issue. Template process failed: undef error - DBIx::Class::Storage::DBI::_dbh_execute(): Table 'koha_koha.club_enrollments' doesn't exist at /usr/share/koha/lib/Koha/Objects.pm line 269 I had none of these issues in the previous versions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 25124] New: MARC visibility settings not obeyed on OPAC result lists
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '20

06 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25124 Bug ID: 25124 Summary: MARC visibility settings not obeyed on OPAC result lists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org It looks like the visibility settings configured in the MARC frameworks are not obeyed on the OPAC result lists. To test: - Hide some fields/subfields in your frameworks that show up in the result list - Example: 100$a, 245$c - Search in the OPAC - Verify that the information still shows -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 23942] New: After upgrading koha from version 16.5 to 18.11 itemtype, itype and other list boxes corresponding to authorised values attached to frameworks fail to show the selected values upon editing the bib and item records
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '20

05 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23942 Bug ID: 23942 Summary: After upgrading koha from version 16.5 to 18.11 itemtype, itype and other list boxes corresponding to authorised values attached to frameworks fail to show the selected values upon editing the bib and item records Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: rajujogi.t(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 94934 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=94934&action=ed… Item editor does not show the previous values for the list boxes I have upgraded Koha from version 16.5 to 18.11. After that when I edit the biblio record the itemtype list box (942$c) does not show the previous value. In the same way when the item records edited the list boxes corresponding to the authorised values LOST, DAMAGED, LOC, NOT_FOR_LOAN, RESTRICTED and itype (itemtypes) the previous values are not shown in the editor. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 23690] New: During checkout, window hangs with a pop up "Loading...you may continue scanning." This message, whilst confounding, impedes staff from accessing other aspects of the patron record. Our work around has been to advise staff to print check-out slip.
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '20

05 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23690 Bug ID: 23690 Summary: During checkout, window hangs with a pop up "Loading...you may continue scanning." This message, whilst confounding, impedes staff from accessing other aspects of the patron record. Our work around has been to advise staff to print check-out slip. Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: julie.kent(a)huntsvillelibrary.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 93208 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=93208&action=ed… screen shot of pop-up message "Loading...you can continue scanning." This message, whilst confounding, impedes staff from accessing other aspects of the patron record. Our work-around has been to advise staff to print check-out slip. Patrons with email do received an confirmation of checked out items. However, if this is a system preference that can be removed without compromising the integrity of the patron record nor check out process, I would like to know and to know how to change the system preference. Please, help! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 25309] New: Unable to create patrons
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '20

04 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25309 Bug ID: 25309 Summary: Unable to create patrons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 103889 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=103889&action=e… Sandbox Error Trace Log On master, it is not possible to create patrons. You get an error Can't call method "extended_attributes" on an undefined value at /kohadevbox/koha/members/memberentry.pl line 560 This happens whether you populate the delivered extended attribute (SHOW_BCODE) or not. I have reproduced this on my own dev server, and on the Sandboxes. I've attached the error trace log from the sandboxes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 17854] New: Print Slip and Close button
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '20

04 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17854 Bug ID: 17854 Summary: Print Slip and Close button 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Would like to see an enhancement on the clear screen (X) button on patron records. It would be great if it were replaced with a button with preference settings that would have the following options: Close Print Slip and Close Print Quick Slip and Close It would also be great if it could have a side action arrow giving you access to the other options that are not defaulted. This feature would help with staff closing accounts (clearing screen) when done, and making slip printing stand out a little better. It would also be a streamlined workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 25311] New: Better error handling when creating a patron
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '20

03 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25311 Bug ID: 25311 Summary: Better error handling when creating a patron Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org When a new patron is created from the staff interface, the error is not correctly handled and the real cause of the issue is hidden in the logs. -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 24510] New: When Placing a Hold, cursor doesn't focus on Patron Name
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '20

03 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24510 Bug ID: 24510 Summary: When Placing a Hold, cursor doesn't focus on Patron Name Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To reproduce: 1. Go to Biblio Record 2. Place Hold (request.pl) - either the Hold above the Bib or the Hold on the left, it does the same thing. 3. Note that the cursor does not go to Patron Name (for whom to place the hold for), it goes to the Top Search bar under Checkout. In 19.05, the cursor does go to the Patron Name during this process and that makes sense from a workflow standpoint. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 24390] New: Add Item Total to Rotating collections (addItems.tt)
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '20

03 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24390 Bug ID: 24390 Summary: Add Item Total to Rotating collections (addItems.tt) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some librarians would find it handy if they could see the total number of items in each rotating collection. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 22381] New: Wording on Calendar-related system preferences not standardized
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '20

03 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22381 Bug ID: 22381 Summary: Wording on Calendar-related system preferences not standardized Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 Target Milestone: --- We've got four very similar system preferences with very different wording, which fosters confusion. ExcludeHolidaysFromMaxPickUpDelay is worded is "(Allow/Don't Allow) Closed days to be taken into account in reserves max pickup delay." OverdueNoticeCalendar is worded as "(Use Calendar/Ignore Calendar) when working out the period for overdue notices." useDaysMode is "Calculate the due date using (the calendar to skip days the library is closed/the calendar to push the due date to the next open day/circulation rules only)" finesCalendar is "Calculate fines based on days overdue (directly/not including days the library is closed." Standardizing wording across these four would make them all clearer as a group. If nothing else, I'd love to see the word "calendar" included somewhere in ExcludeHolidaysFromMaxPickUpDelay so it comes up in an easy search with the others. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40