July 2017 - Koha-bugs - lists.koha-community.org

[Bug 18794] New: OAI/Server.t fails on slow servers
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '18

13 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18794 Bug ID: 18794 Summary: OAI/Server.t fails on slow servers Change sponsored?: --- Product: Koha Version: 17.05 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 Depends on: 14939 https://jenkins.koha-community.org/job/Koha_Master_D8/198/consoleFull # Failed test 'ListMetadataFormats' # at t/db_dependent/OAI/Server.t line 150. # Structures begin differing at: # $got->{responseDate} = '2017-06-12T14:31:51Z' # $expected->{responseDate} = '2017-06-12T14:31:50Z' # PARAM:--- # verb: ListMetadataFormats # EXPECTED:--- # ListMetadataFormats: # metadataFormat: # - metadataNamespace: http://www.openarchives.org/OAI/2.0/oai_dc/ # metadataPrefix: oai_dc # schema: http://www.openarchives.org/OAI/2.0/oai_dc.xsd # - metadataNamespace: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim # metadataPrefix: marc21 # schema: http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd # - metadataNamespace: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim # metadataPrefix: marcxml # schema: http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd # request: http://localhost # responseDate: 2017-06-12T14:31:50Z # xmlns: http://www.openarchives.org/OAI/2.0/ # xmlns:xsi: http://www.w3.org/2001/XMLSchema-instance # xsi:schemaLocation: http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd # RESPONSE:--- # ListMetadataFormats: # metadataFormat: # - metadataNamespace: http://www.openarchives.org/OAI/2.0/oai_dc/ # metadataPrefix: oai_dc # schema: http://www.openarchives.org/OAI/2.0/oai_dc.xsd # - metadataNamespace: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim # metadataPrefix: marc21 # schema: http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd # - metadataNamespace: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim # metadataPrefix: marcxml # schema: http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd # request: http://localhost # responseDate: 2017-06-12T14:31:51Z # xmlns: http://www.openarchives.org/OAI/2.0/ # xmlns:xsi: http://www.w3.org/2001/XMLSchema-instance # xsi:schemaLocation: http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd # Looks like you failed 1 test of 28. [14:32:04] t/db_dependent/OAI/Server.t ............................... Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14939 [Bug 14939] OAI Server classes must be modularized -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 18988] New: OPAC password not going by autoemailprimaryaddress preference
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '18

12 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18988 Bug ID: 18988 Summary: OPAC password not going by autoemailprimaryaddress preference Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: tejoskumar(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The way OPAC password recovery is working with koha 16.05 as understood by me is below: 1. We need to enter userid(Loginid) 2. Enter email - any email associated with the patron in the borrower table 3. Verifying email associated with userid(Loginid) in all email fields of that patron 4. The mail is being sent to the particular mailid entered in password recovery form(if it is matching) As per the setting in patron preferences, iam understanding that, if the mailid associated with userid is verified and matching, then the mail trigger should be based on the autoemailprimaryaddress preference and not the mailid entered in the password recovery form. Password recovery form is not going by the patron preference setting though other notices are using that preference. I think this should be rectified. Please correct me if iam understanding this incorrectly. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 18056] New: Self registration generates error 500, and log file shows : End of script output before headers: opac-memberentry.pl
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '18

12 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18056 Bug ID: 18056 Summary: Self registration generates error 500, and log file shows: End of script output before headers: opac-memberentry.pl Change sponsored?: --- Product: Koha Version: 16.11 Hardware: Other OS: Linux Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: Harold.Cuellar(a)Hotmail.com QA Contact: testopia(a)bugs.koha-community.org On OPAC, self-registration is enabled. You get into opac-memberentry.pl at clicking Register here: link. You put mandatory fields info, and click send button. After few seconds, error 500 appears. into /var/log/koha/biblioteca/opac-error.log an entry is created: [Sun Feb 05 02:30:51.134666 2017] [cgi:error] [pid 6831] [client 192.168.1.123:57296] End of script output before headers: opac-memberentry.pl, referer: http://biblioteca/cgi-bin/koha/opac-memberentry.pl. No mor info is given. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 18775] New: The "Password Reset" notice should use the patron' s homebranch's email as "from" address
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '18

12 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18775 Bug ID: 18775 Summary: The "Password Reset" notice should use the patron's homebranch's email as "from" address Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: techservspec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The password reset notice currently uses the email address stored in the KohaAdminEmailAddress system preference as the "from" address. This can be confusing to patrons (or even make them suspicious) since it may not be the same address (or even the same domain) as the rest of their email notices. This enhancement would use the "from" address set for the patron's home branch and only use the Koha Admin Email Address as a fallback if there is not an address set for the home branch. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 17031] New: Use delimeter system preference for Overdues report download
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '18

09 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17031 Bug ID: 17031 Summary: Use delimeter system preference for Overdues report download Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The delimiter system preference should be used to choose the separator to be used for the data exported from circulation > overdues (overdue.pl). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 18477] New: AR_PENDING notice does not populate values from article_requests table.
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '18

08 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18477 Bug ID: 18477 Summary: AR_PENDING notice does not populate values from article_requests table. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The default AR_PENDING letter does not print populate <<article_requests.*>> fields. To replicate: 1) Enable article requests ( syspref: ArticleRequests => Enable, Circ and fine rules ALL/ALL (or a given category/itemtype): Article requests => Yes ) 2) Search for a title, click in to catalog detail, click 'Request Article' button. 3) Select Patron 4) Fill out request information 5) Click 'Pplace request' 6) Go to notices in patron record, inspect 'Article Request Received' notice. You should see the request information from step 4, but it doesn't display. Examples below: AR_PENDING =================================== <<borrowers.firstname>> <<borrowers.surname>> (<<borrowers.cardnumber>>) We have received your request for an article from <<biblio.title>>. Article requested: Title: <<article_requests.title>> Author: <<article_requests.author>> Volume: <<article_requests.volume>> Issue: <<article_requests.issue>> Date: <<article_requests.date>> Pages: <<article_requests.pages>> Chapters: <<article_requests.chapters>> Notes: <<article_requests.patron_notes>> =================================== Displays as =================================== Barton Chittenden (barton) We have received your request for an article from Bws test record 2 (). Article requested: Title: Author: Volume: Issue: Date: Pages: Chapters: Notes: Thank you! =================================== The 'processing' and 'completed' notices work work, here's the output from 'Article Request Completed' =================================== Barton Chittenden (barton) We are have completed your request for an article from Bws test record 2 (). Article requested: Title: TEST TEST TEST Author: asdfsadf Volume: foo Issue: bar Date: baz Pages: 123234 Chapters: 9 Notes: Raaaaaagh! You may pick your article up at Midway. Thank you! =================================== -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 18919] New: "Transaction Branch" select field broken in Cash register statistics
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '18

07 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18919 Bug ID: 18919 Summary: "Transaction Branch" select field broken in Cash register statistics Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org To reproduce: domain/cgi-bin/koha/reports/cash_register_stats.pl transaction branch all => you can see every cashing any branch => you can see every or no cashing (I don't know exactly on what it depends) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 17883] New: Manage Patron Lists Permission incorrectly displaying hidden columns
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '18

07 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17883 Bug ID: 17883 Summary: Manage Patron Lists Permission incorrectly displaying hidden columns Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Users who do NOT have the permission “Manage Patron Lists” are able to see and edit columns in a patron search result list which have been set to “hidden” by default. This should not be the case. To reproduce: 1. Go to > Administration > Column Settings > Patrons 2. In member (id = memberresultst) set “library” to “hidden by default” and “cannot be toggled”. 3. Log in as user with permission “manage patron lists”. Perform patron search – “library” column is hidden and cannot be toggled. 4. Log in as user without permission “manage patron lists”. Perform same patron search – “library” column is visible and can be toggled. - written by my dear colleague Claire, thanks :-) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 18836] New: Patron login is erroring out after failing to find table
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '18

06 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18836 Bug ID: 18836 Summary: Patron login is erroring out after failing to find table Change sponsored?: --- Product: Koha Version: 17.05 Hardware: Macintosh OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: CJSH(a)CJSHayward.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com (Checked the Wiki, tried chat, and searched bugs before reporting.) I tried to log in as a user and got: Software error: Template process failed: undef error - DBIx::Class::Storage::DBI::_dbh_execute(): Table 'koha_library.club_enrollments' doesn't exist at /usr/share/koha/lib/Koha/Objects.pm line 260 For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error. The VirtualHost below is the only one listening on its special port: Listen 7026 # OPAC <VirtualHost *:7026> <IfVersion >= 2.4> Define instance "library" </IfVersion> Include /etc/koha/apache-shared.conf # Include /etc/koha/apache-shared-disable.conf # Include /etc/koha/apache-shared-opac-plack.conf Include /etc/koha/apache-shared-opac.conf ServerName library.myDNSname.org SetEnv KOHA_CONF "/etc/koha/sites/library/koha-conf.xml" AssignUserID library-koha library-koha ErrorLog /var/log/koha/library/opac-error.log # TransferLog /var/log/koha/library/opac-access.log # RewriteLog /var/log/koha/library/opac-rewrite.log </VirtualHost> What can I do to either create missing tables like koha_libary.club_enrollments, or mark them as not needed for the patron screen to do its work? Thanks, C.J.S. Hayward https://CJSHayward.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 17860] New: MARC records will stage, but Manage for import shows ' no data in table'
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '18

06 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17860 Bug ID: 17860 Summary: MARC records will stage, but Manage for import shows 'no data in table' Change sponsored?: --- Product: Koha Version: 16.11 Hardware: PC OS: Linux Status: NEW Severity: major Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcharlt(a)gmail.com Reporter: gale(a)rabbat.net QA Contact: testopia(a)bugs.koha-community.org I have no difficulty staging bibliographic or authority records, but using management, yields 'no data in table'. Have tried the files on demo systems and they work. Don't understand what the trouble is. Have deleted and reinstalled Koha, have dumped mysql data and recreated database. -- You are receiving this mail because: You are watching all bug changes.

1 12