January 2013 - Koha-bugs - lists.koha-community.org

[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 29 Oct '14

29 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

[Bug 9352] New: Zebra indexes useless subfields in UNIMARC 7XX
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '14

25 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9352 Bug ID: 9352 Summary: Zebra indexes useless subfields in UNIMARC 7XX Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: mathieu.saby(a)univ-rennes2.fr Zebra indexes all subfields of UNIMARC 7XX fields in author index, including $9, $3, $4 (function code), $f (dates of authors), $c (additions other than dates), $p (address). It causes Koha to give too much results. For example, if an author is born in 1984 and is a teacher, searching "1984" or "teacher" in simple search will return all work by this author if these pieces of informations are in 7XX field. This is not how most ILS work, and it should be corrected. -- You are receiving this mail because: You are watching all bug changes.

1 74

[Bug 8778] New: Add "Phrase" Searching to OPAC Search
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '14

23 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8778 Priority: P5 - low Change sponsored?: --- Bug ID: 8778 Assignee: oleonard(a)myacpl.org Summary: Add "Phrase" Searching to OPAC Search Severity: enhancement Classification: Unclassified OS: All Reporter: dcook(a)prosentient.com.au Hardware: All Status: NEW Version: master Component: OPAC Product: Koha Add "Keyword phrase", "Title phrase", and "Notes/Comments" to drop-down menu in masthead.inc, which populates top search box in OPAC. Also, edit opac-search.pl so that the correct index appears in the drop-down menu following a search (which doesn't seem possible using JQuery) Finally, add "Keyword phrase" to OPAC Advanced Search, and move "Title phrase" and "Notes/Comments" so that they appear on the default advanced search screen rather than after clicking "More Options". -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 9368] New: specific behavior of yr and acqdate indexes
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '14

22 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9368 Bug ID: 9368 Summary: specific behavior of yr and acqdate indexes Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: fridolyn.somers(a)biblibre.com When searching on date of publication or date of acquisition index from advanced search, there are several bugs : - The search is performed on no index, using only search therm. - The next or previous pages lead to an empty result page. This comes from specific behavior in C4/Search.pm. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 7362] New: Allow searching by item number as a fallback
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '14

21 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7362 Bug #: 7362 Summary: Allow searching by item number as a fallback Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: ian.walls(a)bywatersolutions.com CC: gmcharlt(a)gmail.com If a library has many items not barcoded, then it'd be good to be able to have them do circulation using the item number. This development will allow using the item number as a fallback if no barcode match was found. To do: * Add a syspref that enables falling back to the item number * When a search is done in the circ interface, and a matching barcode is not found, and the syspref is on: ** Attempt to load an item with a matching item ID and present that. * Update the template to note that it was searching by item number as well, for error messages. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 15

[Bug 8732] New: Add a systempreference to allow users to choose to display an icon based on the marc control fields, or based on the koha biblio level itemtype
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '14

17 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8732 Priority: P5 - low Change sponsored?: --- Bug ID: 8732 Assignee: oleonard(a)myacpl.org Summary: Add a systempreference to allow users to choose to display an icon based on the marc control fields, or based on the koha biblio level itemtype Severity: enhancement Classification: Unclassified OS: All Reporter: chris(a)bigballofwax.co.nz Hardware: All Status: NEW Version: master Component: OPAC Product: Koha Often the icon that is generated in XSLT using the MARC control fields is inaccurate or inadequate. This systempreference would allow libraries to use the itemtype icon they have chosen for the biblio level itemtype (942 in MARC21) This is sponsored by 6 New Zealand Libraries -- You are receiving this mail because: You are watching all bug changes.

1 27