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

[Bug 17113] New: Unable to search multi-domain Active Directory forest due LDAP required base
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17113 Bug ID: 17113 Summary: Unable to search multi-domain Active Directory forest due LDAP required base Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: helpdesk(a)neci.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Auth_with_ldap currently prevents the use of an empty base due to the presence of my $base = $ldap->{base} or die ldapserver_error('base'); An AD Global Catalog search will automatically query all domains in a forest if a blank base is specified, but otherwise limits the search to the domain matching the base. Not being able to specify an empty base makes things difficult if the forest contains disjoint domains that cannot be combined into a single search base. (Uncertain how this interacts with the work on bug 8993, but being able to use the forest wide Global Catalog searches removes a lot of the contortions needed to direct requests to the correct host responsible for a domain.) -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16979] New: Search for barcode containing parentheses fails
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16979 Bug ID: 16979 Summary: Search for barcode containing parentheses fails Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org Searching for a call number containing parentheses, similar to: 1234567890 (text) or 1234(5678)90 fails to return any results, either in the staff interface or OPAC. For the first barcode, leaving off "(text)" will return the expected result, but removing the parentheses from the latter still does not. The issue (and I suspect the solution) seems similar to 15468 and 12405 in that, if I modify the URL to include %22 around the barcode, I get the expected result. To reproduce : 1) Set up an item with a barcode with the form: 1234567890 (text) 2) In the staff interface, perform a barcode search for the exact barcode 3) No results are returned 4) Modify the search URL to include %22 around barcode e.g.: .../cgi-bin/koha/catalogue/search.pl?idx=bc&q=1234567890+(text)&op=and&idx=kw&op=and&idx=kw&sort_by=relevance becomes: cgi-bin/koha/catalogue/search.pl?idx=bc&q=%221234567890+(text)%22&op=and&idx=kw&op=and&idx=kw&sort_by=relevance 5) Press enter 6) The expected result is returned 7) Setup an item with a barcode with the form: 1234(5678)90 8) In the staff interface, perform a barcode search for the exact barcode 9) No results are returned 10) Modify the result URL to include %22 around barcode e.g. .../cgi-bin/koha/catalogue/search.pl?idx=bc&q=1234(5678)90&op=and&idx=kw&op=and&idx=kw&sort_by=relevance becomes: .../cgi-bin/koha/catalogue/search.pl?idx=bc&q=%221234(5678)90%22&op=and&idx=kw&op=and&idx=kw&sort_by=relevance 11) Press enter 12) The expected result is returned -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16930] New: Search returns no results if "and" appears before a colon
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16930 Bug ID: 16930 Summary: Search returns no results if "and" appears before a colon Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org Search returns no results for an exact title search. Steps to duplicate: 1. Create a record with a title like: This is a test title and for testing only : An Example Value 2. Do a title search for the exact title: This is a test title and for testing only : An Example Value 3. No results will be found 4. Change the title to: This is a test title : An Example Value and for testing only 5. Do a title search for the exact title: This is a test title : An Example Value and for testing only 6. The search returns a result. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 16137] New: Simplify patron deletion error handling
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16137 Bug ID: 16137 Summary: Simplify patron deletion error handling Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/members/deletemem.pl OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When deleting a patron, there are some cases handled by deletemem.pl which stop the process and redirect to moremember.pl. Other cases stop the process and display an error in the deletemem.tt template. Is there any reason not to redirect all deletion errors to moremember.pl and eliminate the need for deletemem.tt? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 16827] New: Remove "by" before primary access point.
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16827 Bug ID: 16827 Summary: Remove "by" before primary access point. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: verolencinas(a)yahoo.com.ar QA Contact: testopia(a)bugs.koha-community.org Created attachment 52933 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52933&action=ed… Screenshot of OPAC showing a conference record. After showing the title with the statement of responsability the OPAC shows the primary access point preceded by the word "by". In case of defendants, corporate bodies and conferences it is odd to have this word preceding an authorized access point. This word should be deleted in the OPAC and if there are libraries who want to maintain the "by" practice, it should be possible to add a system preference to do so. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16824] New: No branchcode argument passed to Koha::Calendar->new at /usr/share/koha/lib/C4/Circulation.pm line 3423.
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16824 Bug ID: 16824 Summary: No branchcode argument passed to Koha::Calendar->new at /usr/share/koha/lib/C4/Circulation.pm line 3423. Change sponsored?: --- Product: Koha Version: 3.22 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: himt.library(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 16804] New: Searching can be broken by search terms containing semicolons in XSLT
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16804 Bug ID: 16804 Summary: Searching can be broken by search terms containing semicolons in XSLT Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org As of CGI version 2.64 ( which was a long time again ) Perl's CGI module began supporting the use of the semicolon (;) as a key value pair separator in addition to the ampersand (&) which Koha currently uses. This causes an issue where is search string is truncated at the semicolon. Not only can this cause issues with incorrect searches/results, it can cause malformed CCL which causes Koha to return no search results! Test Plan: 1) Create a record with a 490$a series statement where there is a semicolon at the end 2) Enable OPAC Suppression 3) Search for the record and click the "Series:" link 4) You will get no results This is because the search: se,phr:"Report to the Mississippi Legislature ;" is converted to se,phr:"Report to the Mississippi Legislature When the opac suppression is tacked on, we get malformed CCL: (se,phr="Report to the Mississippi Legislature ) not Suppress=1 This is not an issue if we simply search for se,phr:"Report to the Mississippi Legislature ;" because the search form properly encodes the semicolon. The solution appears to be to make sure all URL elements are properly url encoded and converts all ";" to "%3B". I do notice that in koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slimUtils-MODS31.xsl we have a template url-encode that may prove useful. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 16783] New: MARC 008 Material Type change back to CR
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16783 Bug ID: 16783 Summary: MARC 008 Material Type change back to CR Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: imingchan(a)yahoo.com.au QA Contact: testopia(a)bugs.koha-community.org MARC 008 (Material Type) doesn't stay what has been selected. Creating a lot of cataloguing records for journal citations, so changed Leader > Position 7 to "B - Serial component part". We then changed MARC 008 > Material Type to "BKS - Books" and successfully saved the catalogue record (no problem here). However, when we reopened MARC 008, the Material Type keep changing back to "CR - Continuing Resource" instead of remain as "BKS - Books"! -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 16771] New: Use TT Price plugin to display monetary amounts formatted
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16771 Bug ID: 16771 Summary: Use TT Price plugin to display monetary amounts formatted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Using this bug for noting places where we should use the new Price plugin to show monetary amounts formatted according to the chosen system preference value. koha-tmpl/intranet-tmpl/prog/en/modules/reserve/request.tt ...[% borrowerfirstname %] [% borrowersurname %]</a>: <strong>Patron has outstanding fines: [% amount_outstanding | format('%.2f') %]</strong></li> -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16679] New: Translatability problems in system preferences
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16679 Bug ID: 16679 Summary: Translatability problems in system preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Koha's system preferences are constructed and displayed in a very elegant way in English, but not all languages have the same syntax, and we get a lot of translation issues due to sentence splitting. In some cases, translators can work around such problems, but we will always have odd translations. Odd translations do not look very professional at all, and they can lead to misunderstandings and misconfigurations. Additionally, it is very frustrating and discouraging for translators. IMO, the best way to get rid of such translation problems would be to use whole sentences, followed by the preference's value. Example (taken from Bug 16669): Instead of... [Don't use/Use] CAS for login authentication. ...the following would be much better in terms of translatability: Use CAS for login authentication: [Yes / No] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5