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

[Bug 5505] New: A cataloger assigned to one library can delete all items
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '11

01 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5505 Summary: A cataloger assigned to one library can delete all items Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: spalding(a)senylrc.org QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 This cataloger has the following permissions catalogue View Catalog (Librarian Interface) borrow Borrow books edit_catalogue Edit catalog (Modify bibliographic/holdings data) edit_items Edit Items fast_cataloging Fast cataloging management Set library management parameters edit_calendar Define days when the library is closed edit_news Write news for the OPAC and staff interfaces inventory Perform inventory (stocktaking) of your catalog label_creator Create printable labels and barcodes from catalog and patron data execute_reports Execute SQL reports While on the normal tab, if they click edit items and get the screen listing items they our limited to edit and deleting their own item. But if they our on the normal tab and click on delete all items they will actually delete all items. -- 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 6346] New: Patron search results should be valigned top
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '11

31 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6346 Bug #: 6346 Summary: Patron search results should be valigned top Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: /cgi-bin/koha/members/member.pl OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 4126 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4126 example When looking at the patron search results if they have a long note you don't see the patron's name because it's valigned center. Can we valign this column to the top to make it easier to see the important info. -- 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 10

[Bug 6611] New: patron barcode removed when editing an attribute
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '11

30 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6611 Bug #: 6611 Summary: patron barcode removed when editing an attribute Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: critical 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 I am hoping that the below is actually a T:T issue: This is a major problem- the patron barcode is deleted when an attribute is edited. This only seems to happen when the attribute is edited by clicking on the 'edit' link below the attribute box on the patron's 'details' page- not when editing it through the edit button at the top. Example- I just created a library card for a student, including entering her barcode and then after saving the record, noticed that I could add her student ID number to the attribute field. I clicked on the edit link below the attribute box, added the ID number and saved the change. When her details page popped back up, there was no longer a barcode. I double-checked this with my own account (Student) and another staff account. We aren't sure if the barcode is the only info that is deleted or if other fields are also deleted. -- 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 11

[Bug 6042] New: SIP : Format dates as should be in Koha
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '11

29 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6042 Bug #: 6042 Summary: SIP : Format dates as should be in Koha Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.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 5

[Bug 6361] New: Packages need support for the 3.4 upgrade
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '11

28 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6361 Bug #: 6361 Summary: Packages need support for the 3.4 upgrade Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: robin(a)catalyst.net.nz 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 12

[Bug 6510] New: "Sort by" in intranet search alters search and number of hits
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '11

26 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6510 Bug #: 6510 Summary: "Sort by" in intranet search alters search and number of hits Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org An example: * Simple search for "jones" in the intranet gives: search.pl?q=jones 55 result(s) found for 'kw,wrdl: jones' in Koha Catalog. Reordering by e.g. "Title (A-Z)" gives: search.pl?x=kw&q=jones&sort_by=title_az 55 result(s) found for 'kw,wrdl: jones' in Koha Catalog. * Advanced search for "jones" in the default field ("Keyword") gives: search.pl?idx=kw&q=jones&idx=kw&idx=kw&sort_by=relevance 55 result(s) found for 'kw,wrdl: jones' in SKSK Catalog. Reordering by "Title (A-Z)" gives: search.pl?x=kw&q=jones&sort_by=title_az 55 result(s) found for 'kw,wrdl: jones' in SKSK Catalog. idx=kw is turned into x=kw, but we still get the same number of results. * Choosing "Author" as the index to search, and then searching for "jones" gives: search.pl?idx=au&q=jones&idx=kw&idx=kw&sort_by=relevance 41 result(s) found for 'au,wrdl: jones' in SKSK Catalog. And here is the biggie, reordering by "Title (A-Z)" gives: search.pl?x=au&q=jones&sort_by=title_az 55 result(s) found for 'kw,wrdl: jones' in SKSK Catalog. Choosing a different sort criteria results in a different number of hits, presumably because idx=au has been turned into x=au. Searching for "jones" as "Author" and choosing to sort by "Title (A-Z)" on the advanced search page does gives the expected result: search.pl?idx=au&q=jones&idx=kw&idx=kw&sort_by=title_az 41 result(s) found for 'au,wrdl: jones' in SKSK Catalog. The same thing seems to hapen no matter what index you choose to limit your search to, and what criteria you choose to sort on. So why does re-sorting turn idx into x? -- 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 11

[Bug 4828] New: Erroneous SIP2 behaviour with non ascii characters
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '11

26 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4828 Summary: Erroneous SIP2 behaviour with non ascii characters Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: colin.campbell(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The underlying bug is as much in the sip2 specification and implementation as in Koha, Symptom text in a sip request or response with a non-ascii character causes "undefined" behaviour in the client. (Usually an error and reset) Cause: The standard specifies that the sip character set is defined by an old dos codepage. I know of no client implementation which adheres to this most use a windows characterset. In Koha we send the text as retrieved from the database (i.e. utf-8) this is ok if the client is utf-8 or data is purely anglophone lacking special characters and diacritics. For some client devices we need a mechanism to protect them from scary non-ascii characters or to present them in a form they can display. In general the suppliers of client devices are a bit reticent about their machines character set limitations. This enhancement will probably be addressed when we have a case who want it fixed. This bug has been reported before but was closed without this specific problem being addressed -- 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 6317] New: CCL search is case sensitive
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '11

25 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6317 Bug #: 6317 Summary: CCL search is case sensitive Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: frederic(a)tamil.fr QAContact: koha-bugs(a)lists.koha-community.org On any search page this search: note=foo doesn't work. But this one works: Notes:foo -- 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 5717] New: Some search results appear as "No Title" when zebraqueue is used instead rebuild_zebra.pl
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '11

24 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5717 Summary: Some search results appear as "No Title" when zebraqueue is used instead rebuild_zebra.pl Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Command-line Utilities AssignedTo: gmcharlt(a)gmail.com ReportedBy: fcapovilla(a)live.ca QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 3099 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3099 Adds the record fixing subroutines from rebuild_zebra.pl in zebraqueue_daemon.pl When using zebraqueue to watch our MARC records, we sometimes encountered results showing "No Title". Those records had no biblionumber because they were not returned correctly by Zebra. We also noticed that the problem was only noticeable after a record was modified, which caused it to be reindexed by zebraqueue. I noticed that zebraqueue wasn't using the fix_leader, fix_biblio_ids, fix_authority_id and fix_unimarc_100 subroutines that can be found in rebuild_zebra.pl . I added and used these subroutines in zebraqueue_daemon.pl so zebraqueue would do the same modifications that rebuild_zebra.pl did on the records sent to Zebra. This change seems to have fixed the problem in my Koha instances, the "No Title" records are now shown correctly in the search results. A patch containing my modifications is attached. -- 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 5148] New: Definition with surname won't work
by bugzilla-daemon＠bugs.koha-community.org 23 Aug '11

23 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5148 Summary: Definition with surname won't work Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: cgi-bin/koha/reports/dictionary.pl?phase=Add New Definition OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Reports AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 2542 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2542 no way to filter on surname I tried to create a report definition filtering on surname but it wouldn't work. I then tried to do firstname and surname and only firstname appeared. Here are the steps: 1. Go to Reports Dictionary and click 'New Definition' 2. Give it a name 3. Choose 'Patrons' as Area 4. Choose 'Surname' as Column 5. See screenshot - there is no field to enter a value for Surname to match on. -- 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