September 2012 - Koha-bugs - lists.koha-community.org

[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

[Bug 6532] New: way to move items in batches
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 Bug #: 6532 Summary: way to move items in batches Classification: Unclassified 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: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com It would be nice if we could use the batch item modification to move a batch of items to another bib record. -- 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

[Bug 5613] New: search by 'on order'
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '14

02 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5613 Summary: search by 'on order' Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Would be great if there was a way to search for on order items (I know we can do this with CCL, I'm saying having it on the advanced search for patrons to see). -- 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 5961] New: Acquistions: New feature to create a bunch of orders from a staged file
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '14

31 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5961 Bug #: 5961 Summary: Acquistions: New feature to create a bunch of orders from a staged file Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org Blocks: 5580 (MT #4007) Filling a basket from the reservoir creating a form order to import all records from a staged file -- 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 16

[Bug 7933] New: Fields in marc display not the same
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '14

30 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7933 Priority: P5 - low Change sponsored?: --- Bug ID: 7933 Assignee: oleonard(a)myacpl.org Summary: Fields in marc display not the same QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com URL: /cgi-bin/koha/opac-MARCdetail.pl?biblionumber=22543 Hardware: All Status: NEW Version: master Component: OPAC Product: Koha Created attachment 9045 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9045&action=edit labeled marc with no 090 If you click to view the marc display of a record in the OPAC it doesn't show all of your fields. If you click 'view plain' you do see all the fields. If it's MARC view you should see all the filled in fields on both views, just with a slightly different view. For example see the attached images - the 090 is there on view plain, but not on the labeled view. -- You are receiving this mail because: You are watching all bug changes.

1 42

[Bug 6739] New: expired patrons not blocked from opac actions
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '14

29 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6739 Bug #: 6739 Summary: expired patrons not blocked from opac actions Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com A patron with an expired card can still renew books and place holds via the opac. Since the staff can't do these thing without renewing the patron's card shouldn't the patron be blocked in the OPAC as well? Also, there should be some kind of note to the patron that the account has expired and they need to see a librarian. -- 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 169

[Bug 8270] New: Software error: Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2919
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '14

29 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8270 Priority: P5 - low Change sponsored?: --- Bug ID: 8270 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Software error: Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2919 Severity: enhancement Classification: Unclassified OS: Linux Reporter: therrsonne02(a)yahoo.com Hardware: PC Status: NEW Version: rel_3_8 Component: Circulation Product: Koha Created attachment 10359 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10359&action=edit Software error at line 2919 When we are trying to checkout/checkin an item an error prompts like this "Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2919. I have this in my url address: "192...:8080/cgi-bin/koha/reserved/renewscript.pl" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 8837] New: Dewey cn_sort inaccurate
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8837 Priority: P5 - low Change sponsored?: --- Bug ID: 8837 CC: m.de.rooy(a)rijksmuseum.nl Assignee: gmcharlt(a)gmail.com Summary: Dewey cn_sort inaccurate Severity: normal Classification: Unclassified OS: All Reporter: joy(a)bywatersolutions.com Hardware: All Status: NEW Version: rel_3_8 Component: Cataloging Product: Koha The items.cn_sort value created by the Dewey.pm does not create accurate sorting (cn_sort) values. Example 1: Three similar callnumbers do not sort the same way . Suggested fix is to replace / with spaces. (note: if any token[$i] consists of only one space when sort routine progresses it should be disregarded/removed) +--------------------------+--------------------------------+ | itemcallnumber | cn_sort | +--------------------------+--------------------------------+ | 971/P23w/v.1-2/pt.8 | 971P23WV_000000000000000_12PT_ | | 971.01/P23w/v.1-2/pt.6-7 | 971_000000000000000_01P23WV_12 | | 971.01/P23w/v.1-2/pt.7 | 971_01P23WV_12PT_7000000000000 | +--------------------------+--------------------------------+ That would improve the cn_sort values: Manually replaced '/' with spaces in items.itemcallnumber to illustrate that process. +--------------------------+--------------------------------+ | itemcallnumber | cn_sort | +--------------------------+--------------------------------+ | 971.01 P23w v.1-2 pt.6-7 | 971_010000000000000_P23W_V_12_ | | 971.01 P23w v.1-2 pt.7 | 971_010000000000000_P23W_V_12_ | | 971 P23w v.1-2 pt.8 | 971_P23W_V_12_PT_8000000000000 | +--------------------------+--------------------------------+ However, the sort routine will adjust the second 'token' it finds that is all digit. In the above case it is in the last callnumber (the 8) which is padded. A better option would be to only adjust the only adjust the second 'token' if it is the second token. Further if there are two token and the second token is not $token[2] then pad the first token with _zeros An ideal result would be: +--------------------------+--------------------------------+ | itemcallnumber | cn_sort | +--------------------------+--------------------------------+ | 971 P23w v.1-2 pt.8 | 971_000000000000000_P23W_V_12_ | | 971.01 P23w v.1-2 pt.6-7 | 971_010000000000000_P23W_V_12_ | | 971.01 P23w v.1-2 pt.7 | 971_010000000000000_P23W_V_12_ | +--------------------------+--------------------------------+ note: 30 character limit does chop the rest of the cn_sort. Without an update to the database, this will be 'collateral damage'. -- You are receiving this mail because: You are watching all bug changes.

1 14