June 2011 - Koha-bugs - lists.koha-community.org

[Bug 6197] New: Capitalized or lowercased Turkish characters are not searchable
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6197 Bug #: 6197 Summary: Capitalized or lowercased Turkish characters are not searchable Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: akif-antispam(a)dinc.org QAContact: koha-bugs(a)lists.koha-community.org When searching for Titles or Authors that contain Turkish characters, they are not found if search pattern has the opposed case. For example if the author is "Nefes Zade İbrahim" and the search pattern is "ibrahim" than the result is empty. If the search is "İbrahim" than the record matches and search delivers the good results. The characters that are forcing this problem are "ğĞ, ıI, iİ, şŞ". -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 2

[Bug 5614] New: patron prefs not in categories
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5614 Summary: patron prefs not in categories Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: cgi-bin/koha/admin/preferences.pl?tab=patrons OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 All other preference tabs have categories (unless they only have 1 or 2 prefs). The patrons tab should also be broken into categories for easy navigation. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 2

[Bug 5408] New: Refactor C4::Circulation::GetIssuingRule
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5408 Summary: Refactor C4::Circulation::GetIssuingRule Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: cfouts(a)liblime.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 GetIssuingRule submits a cascade of queries to the database to find its match. This could be optimized and cleaned up by retrieving them all at once. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 12

[Bug 5359] New: Parcel receive improvement
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5359 Summary: Parcel receive improvement Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All URL: http://wiki.koha-community.org/wiki/Parcel_receive_acq _RFC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Deadline: 2011-05-01 * A control will be added if the librarian declares more recieves than what has been ordered. This will be usefull to avoir typing mistakes * We will add fields in the form to let the librarian modify budget on the fly -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 7

[Bug 6418] New: display 590a
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6418 Bug #: 6418 Summary: display 590a Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org >From a partner: "We've added our journal holdings data to multiple 590/a fields. We'd like these to display in both the search results pages and in the individual bib record in the OPAC and the staff client. The information is displaying in the title detail tab but we don't want to have to click to it; we're used to seeing it immediately with the title information. Attache jpg shows Title Details tab with 590/a information, search results example with note where to display 590/a and bib record with note where to display 590/a" Two suggested ways to tackle this: If XSLT: The best way to display the 590a in a community-friendly way is to allow user-uploaded XSLT. This is comparatively simple, as we'd just need to code up the file upload scripting, and then point the XML parser at that XSLT instead of the built in one. It would involved writing XSLT, which is unpleasant, but we would help with that, and a page could be added to the Koha wiki to share completed XSLTs If Normal view: For this method, I'd go with teching up the Keyword to MARC mappings tool and add more supported Keywords. This would again not be 590a-specific, but rather a matter of placing the keyword tokens into the code in the right places, then configuring those keywords to map to the right MARC. "Keyword" is probably not the right term to be using here, so renaming might make things clearer for the continued use of this functionality. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 5

[Bug 6068] New: New feature: capability to blanking subfields in BatchMod
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6068 Bug #: 6068 Summary: New feature: capability to blanking subfields in BatchMod Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: alex.arnaud(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 17

[Bug 4944] New: Create separate noItemTypeImages preferences for OPAC and staff client
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4944 Summary: Create separate noItemTypeImages preferences for OPAC and staff client Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 At the moment the noItemTypeImages preference controls only the staff client. If my patch for Bug 4359 is approved it will affect both the staff client and the OPAC. Neither is ideal: There should be separate preferences for OPAC and staff client. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 2

[Bug 6253] New: Unified Patron Search subroutine
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6253 Bug #: 6253 Summary: Unified Patron Search subroutine Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Patrons AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 1707, 4340, 4945, 5266, 5595, 5730, 5945, 6127, 6217, 5676 Currently Koha uses two patron search routines, Search() and SearchMember(). SearchMember() is used in most places where a patron search is performed, and does not respect Extended Attributes, branchcode/categorycode limits or paging of results. It does, however, return exact matches for cardnumbers quickly, making it very desirable for Circulation. Search() is only used on members/member.pl to do an in-depth search of patrons. It makes use of SQLHelper.pm, which gives us support for Extended Attributes OR branchcode/categorycode limits (can't have both, it seems) and results paging. It's easy to add new fields from the borrowers table to search. Koha should really only have 1 search routine for searching for patrons. This routine should support Extended Attributes, branchcode/categorycode limits and pagination. Exact matches on cardnumber OR unique, searchable Extended Attributes should return immediately, without having to go through the full search routine. It should also be easy to configure which fields in the borrowers table are searchable. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 52

[Bug 5730] New: Patron search, start_with search now searches within a string, not just the start
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5730 Summary: Patron search, start_with search now searches within a string, not just the start Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Blocks: 5575 Estimated Hours: 0.0 Search on start_with does like "% $var%" search (instead of " $var%") Plus a performancement enhancement for C4::SQLHelper -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 4

[Bug 6511] New: Server-side paging of SQL queries
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6511 Bug #: 6511 Summary: Server-side paging of SQL queries Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org A generic server-side paging solution that could be applied to any SQL query we need would be a huge boon for the system. The query could be passed to a "pagify" subroutine, along with the starting and ending values, and the modified query returned. This would have the advantage of forcing sorts to apply BEFORE paging, so things like patron search results would be sorted globally, not just per page. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 1