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

[Bug 3191] New: Bug in NonZebra search functions SimpleSearch() and NZOrder()
by bugzilla-daemon＠liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3191 Summary: Bug in NonZebra search functions SimpleSearch() and NZOrder() Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: jmf(a)liblime.com ReportedBy: abcendzone(a)yahoo.com Estimated Hours: 0.0 Bug 1) The NonZebra SimpleSearch() function in C4::Search.pm has the following two inputs: - $offset: is the offset when displaying e.g. page 2 of the search results - $max_results: is the maximal number of results per page Bug: These two input parameters are NOT passed on to the NZorder() funtion on line 223 when using nonzebra search: Instead of: my $result = NZorder( NZanalyse($query) )->{'biblioserver'}; this line should pass $offset and $max_results like this: my $result = NZorder( NZanalyse($query),,$max_results,$offset )->{'biblioserver'}; Bug 2) The NonZebra NZOrder() function is supposed to order the search results and return ($results_per_page) entries starting from ($offset). The code that is supposed to do this (starting at around line 2059 in Search.pm) looks like this: # for ( # my $counter = $offset ; # $counter <= $offset + $results_per_page ; # $counter++ # ) # { # $result_hash->{'RECORDS'}[$counter] = # GetMarcBiblio( $result_hash->{'RECORDS'}[$counter] )->as_usmarc; # #if $result_hash->{'RECORDS'}[$counter]; # } # my $finalresult = (); # $result_hash->{'hits'} = $numbers; # $finalresult->{'biblioserver'} = $result_hash; # return $finalresult; But this code actually returns an array of size ($numbers), which is the TOTAL number of search results and within this array, it ONLY populates the entries from ($offset) up to ($offset + $results_per_page). So, 1. the array is way too big, 2. t has mostly empty elements 3. it returns one results too much, because from ($offset) up to ($offset+ $results_per_page) are a total of ($results_per_page+1) elements What is SHOULD do is return an array of size ($results_per_page), containing exactly ($results_per_page) search results from ($offset) up to ($offset + $results_per_page - 1). The correct code would be something like this: my $finalresult = (); #create output array $finalresult->{'biblioserver'}->{'hits'} = $numbers; #save total number of search results $numbers=0; #reset counter for ( my $counter = $offset ; $counter < $offset + $results_per_page ; #changed <= to < to return correct number of elements $counter++ ) { $finalresult->{'biblioserver'}->{'RECORDS'}[$numbers++] = GetMarcBiblio( $result_hash->{'RECORDS'}[$counter] )->as_usmarc; #populate the array from 0 to ($results_per_page-1) with the search results from ($offset) to ($offset+$results_per_page-1) } return $finalresult; The buggy code is used TWICE in NZOrder() in Search.pm, so it has to be replaced starting from line 2059 and starting from line 2113. Best regards... -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 1

[Bug 3194] New: setting "hidelostitems" to ON no longer prevent a bib from displaying in OPAC if all items are lost
by bugzilla-daemon＠liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3194 Summary: setting "hidelostitems" to ON no longer prevent a bib from displaying in OPAC if all items are lost Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: beverly.church(a)liblime.com Estimated Hours: 0.0 There also seems to be a change in the way "hidelostitems" preference works. In the past, setting this preference to "ON" prevented bibliographic records from appearing in search results if all the bib's attached items had "lost" values greater than 0. These records are now appearing in the search results. If you go to the detail window, you get the message "No physical items for this record". -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 5

[Bug 3164] New: OPAC-placed holds broken in SingleBranchMode
by bugzilla-daemon＠liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3164 Summary: OPAC-placed holds broken in SingleBranchMode Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: major Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: rch(a)liblime.com CC: sedwards(a)alloycomputing.com Estimated Hours: 0.0 Patrons cannot place holds on titles if SingleBranchMode is ON because the template does not supply the branchcode to opac-reserve.pl. The script returns the error 'bad_data', which displays as "ERROR: Internal error: incomplete hold request." Offending code is around line 196 of opac/opac-reserve.pl, but would be fixed by just keeping the branchcode as a param in the tmpl even if singlebranchmode is on. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 12

[Bug 3150] New: Verbiage of any email sent from Koha should be editable from web interface
by bugzilla-daemon＠liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3150 Summary: Verbiage of any email sent from Koha should be editable from web interface Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 This is currently uneven in application. Holds notifications are editable through the web interface, but cart/list/shelf/suggestion response emails are governed by templates. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 2

[Bug 3146] New: Yui CSS files always imported /en/ directory instead of actual language
by bugzilla-daemon＠liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3146 Summary: Yui CSS files always imported /en/ directory instead of actual language Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P5 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: abcendzone(a)yahoo.com Estimated Hours: 0.0 The "reset-fonts-grids.css" and "skin.css" files are imported in "/koha/opac/htdocs/opac-tmpl/prog/$LANG/css/opac.css" via @import url("../../en/lib/yui/reset-fonts-grids.css"); @import url("../../en/lib/yui/skin.css"); for ALL languages, instead of the correct $LANG directory. E.g. for a german installation where opaclanguage=de-DE, it should be @import url("../../de-DE/lib/yui/reset-fonts-grids.css"); @import url("../../de-DE/lib/yui/skin.css"); As these files are identical for all languages but are installed in each language directory, one could either remove the duplicate files from the language directories or actually use them from there. Right now they are installed for each language but imported just from the /en/ directory. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 1

[Bug 3111] New: Opac lists all ITYPES as same, when database lists different. Other OPAC issues.
by bugzilla-daemon＠liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3111 Summary: Opac lists all ITYPES as same, when database lists different. Other OPAC issues. Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: darrellulm(a)smfpl.org Estimated Hours: 0.0 The opac details page lists all ITYPES as same when database shows different. Intranet is correct. The opac seach results page is not updated for 'avail' and 'checked-out' Intranet appears correct. Example (there are several REF items here - opac does not show) http://opac.smfpl.org/cgi-bin/koha/opac-detail.pl?biblionumber=54825 There is one ref item here. Details pages does not show http://opac.smfpl.org/cgi-bin/koha/opac-detail.pl?biblionumber=85095 OPAC shows items (w/ copynumber present) as checked out no matter what. http://opac.smfpl.org/cgi-bin/koha/opac-search.pl?q=simpsons The details page is not an indexing issue. The incorrect ITYPEs are displayed. It seems to grab the first one can use that for all entries as if the indiv. item types are not being accounted for. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 1

[Bug 3294] New: inventory tool
by bugzilla-daemon＠liblime.com 12 May '10

12 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3294 Summary: inventory tool Product: Koha Version: rel_3_0 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P5 Component: Tools AssignedTo: galen.charlton(a)liblime.com ReportedBy: kohnk(a)arcadia.edu Estimated Hours: 0.0 Change sponsored?: --- The inventory tool is putting LC call numbers in order number-by-number instead of in the LC order. For example: The call numbers were BF1028, BF1029, BF103. The computer put them in this order by looking at the B, then the F, then the 1, etc. LC would order them BF103, BF1028, BF1029, looking at the numbers as one hundred three and one thousand twenty-eight. We can't use the tool unless the order matches what is on the shelf. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 7

[Bug 3203] New: Some Letters template variables are not available to certain notice types
by bugzilla-daemon＠liblime.com 12 May '10

12 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3203 Summary: Some Letters template variables are not available to certain notice types Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Notices AssignedTo: henridamien(a)koha-fr.org ReportedBy: rch(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- digest type notices do not know what library they belong to, yet the interface allows the user to add branches.branchname. I assume it would make sense to add this as the patron's registration branch. advance_notices types do not parse items.content. digest types know the special variable <<count>> though it's not listed in the variable list. Ultimately, we define message_attributes but we hard-code special meanings in certain letter_codes. Only variables available to a given letter type should be listed in the interface. Minimally, advance_notices should probably handle items.content and parse the 'branches' variables. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 12

[Bug 3419] New: Downloaded saved reports do not contain all records
by bugzilla-daemon＠liblime.com 11 May '10

11 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3419 Summary: Downloaded saved reports do not contain all records Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Reports AssignedTo: galen.charlton(a)liblime.com ReportedBy: beverly.church(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- If you run the following query as a saved report and download the results, the file does not contain all the records which you viewed in Koha: SELECT borrowers.surname, borrowers.firstname, borrowers.address, borrowers.city, borrowers.zipcode FROM borrowers ORDER BY borrowers.surname asc In Koha you can see all patrons from A to Z. The downloaded file only contains patron records up to the letter D. The database has 71,755 patron records. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 9

[Bug 3134] New: Ability to selelct multiple reports to delete at once
by bugzilla-daemon＠liblime.com 05 May '10

05 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3134 Summary: Ability to selelct multiple reports to delete at once Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Reports AssignedTo: galen.charlton(a)liblime.com ReportedBy: nicole.engard(a)liblime.com CC: chris(a)bigballofwax.co.nz, oleonard(a)myacpl.org Estimated Hours: 0.0 It would be nice if there were check boxes next to reports so you can select this month's reports and delete them when you run next month's ... that way you don't end up with 100s of reports. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 2