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

[Bug 3966] receiving items should allow for entering barcode
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '12

07 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3966 Srdjan Jankovic <srdjan(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff --- Comment #18 from Srdjan Jankovic <srdjan(a)catalyst.net.nz> --- Patch applied for me. Can we please have another go? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 6650] New: no holds message is not always clear
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '12

07 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6650 Bug #: 6650 Summary: no holds message is not always clear Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Circulation AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Problem: On the staff side of Koha, if we try to place a hold on a Reference or Reserve book, Koha properly denies the request with an odd message: Cannot place hold, patron has too many holds. It’s the correct action, but strange. Is this one of those built in messages? Not very informative certainly confusing. Explanation of solution: What Koha's doing, under the hood, is checking the CanBookBeReserved subroutine, which is a simple boolean 'Yes/No' answer. It's a boolean OR of all the CanItemBeReserved answers for all the items of that title. In the case of a title with a single reference copy, which allows 0 holds on it, the answer is 'no, this item cannot be reserved'. The problem is that Koha is then setting the "maxreserves" flag, because the patron's current number of reserves on such items (which is 0) is greater than or equal to the max allowed (also 0). In any other context, this would make sense: if you were allowed only 4 holds, say, on a Book, and you wanted to place your 5th, you'd get the messaging saying you had too many already. I suppose the confusion really comes in when the global "maxreserves" system preference is also consulted, and sets the same flag. So, you've got an unlimited maxreserves, but you're still getting the message because 0 >= 0. The solution, I believe, is to use a separate message for the CanBookBeReserved check than for the overall maxreserves check. This could be something like "Cannot Place Hold: <patron> cannot place any more holds on this item type". Still not perfect for the Reference use-case, but better. -- 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 5364] New: Limit the number of author displayed on OPAC
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '12

06 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5364 Summary: Limit the number of author displayed on OPAC Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: spalding(a)senylrc.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 2728 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2728 PDF of what the page looks like Some bib have a very long list of authors that take up most of the screen and push the useful data much lower on the screen. Would like authors to be handle like items where there is a cap of 50 items. Maybe authors should be limited to 10. http://koha.senylrc.org/cgi-bin/koha/opac-detail.pl?biblionumber=25353 -- 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 5062] New: Acq terminology: list price, ordering price, vendor price, RRP
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '12

06 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5062 Summary: Acq terminology: list price, ordering price, vendor price, RRP Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 In acquisitions there are different terms used for the same thing in the database. The vendor form uses 'ordering price' and 'list price', the new order form uses 'vendor price'. I wrote a patch to change 'ordering price' to 'list price' in the new vendor form, because this term was used in all other places in this template. (bug 5059) Now I found 'vendor price' in the new order form. The basket view uses 'RRP' (see screenshot) The PDF print layout 'pdfformat::layout3pages' uses 'RRT GST Inc.' as column heading. Comments from discussion on IRC: (15:21:47) slef: I'm looking at ODLIS (15:23:41) slef: It says in "list price"'s definition "Synonymous with published price and retail price" but I suspect this might be a subtle difference between "list price" and "retail price" (15:08:27) nengard: i think vendor price might be the safest option (15:08:37) nengard: that says to me the price the vendor is charging (15:08:48) nengard: or the price the vendor has listed on their site or in their catalog I'm not a native speaker, so not sure which term to choose. But I think reducing the used terms to one would make things (translation, documentation, trainign) a lot easier! -- 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 6

[Bug 3069] Koha Z39.50 client process discussion
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '12

06 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3069 Gaetan Boisson <gaetan.boisson(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gaetan.boisson(a)biblibre.com --- Comment #4 from Gaetan Boisson <gaetan.boisson(a)biblibre.com> --- I am reviving this bug. The problem is still there in master as of today from what i have seen. We still get 20 results from a z39.50 search, with no control over this limit. There is no way to clean the reservoir from the biblio which have been imported through z39.50, like there is a way to do it for biblios imported via the import tools. It does seem like the search on author is still not possible, but i'm not 100% positive about it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4078] Display active currency symbol on currency output and input
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '12

06 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4078 --- Comment #6 from Marc Véron <veron(a)veron.ch> --- Hi Katrin, I expect that GetCurrency() would be used in a context like proposed by Paul Poluain in Comment 3, i.e. it would be the template that does the formatting. GetCurency() returns an aray resulting form a select * statement, you simply could use $active_currency->{format} along with the existing $active_currency->{currency} The same with the result of GetCurrencies() (but it seems that it is currently only used to get the rates). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4078] Display active currency symbol on currency output and input
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '12

06 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4078 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de --- Comment #5 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Marc, I agree with 1) and 2) - not sure I get 3). I would really like to see a new TT plugin doing the formatting on template level. Then we could start stepping through the code and making it show correctly everywhere. Do we need to distinguish between active currency and other currency display? I think later is only needed in acquisitions. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4078] Display active currency symbol on currency output and input
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '12

06 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4078 --- Comment #4 from Marc Véron <veron(a)veron.ch> --- I propose to expand this functionality to the formatting of currency values as well. Up to now, formatting is handled via the preference "CurrencyFormat". User can choose between 360,000.00 (US) and 360 000,00 (FR). The preference is evaluated in a hard coded way in several .pl and .pm files as acqui-home.pl aqbudgetperiods.pl layout2pages.pm aqplan.pl aqbudgetperiods.pl layout3pages.pm layout2pages.pm (maybe more) The code reads: ---Snip--- my $cur_format = C4::Context->preference("CurrencyFormat"); my $num; if ( $cur_format eq 'US' ) { $num = new Number::Format( 'int_curr_symbol' => '', 'mon_thousands_sep' => ',', 'mon_decimal_point' => '.' ); } elsif ( $cur_format eq 'FR' ) { $num = new Number::Format( 'decimal_fill' => '2', 'decimal_point' => ',', 'int_curr_symbol' => '', 'mon_thousands_sep' => ' ', 'thousands_sep' => ' ', 'mon_decimal_point' => ',' ); } ---Snip--- To make things more configurable I propose to do the following: 1) Expand table currency (http://schema.koha-community.org/tables/currency.html) with an additional column "format" This column could be pre-filled by system_preferences.sql, and it should be editable (/admin/currency.pl). Maybe some input validation is necessary to get well formed strings. 2) Remove preference "CurrencyFormat" (not longer used) 3) The sub GetCurrency()(located in Budgets.pm) will return the currency format string along with the currency symbol. No chnges needed (Select *....) Use GetCurrency()->{format} in sub filter and format the number as appropriate. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7649] New: remove kw,wrdl from search history
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '12

06 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7649 Priority: P5 - low Change sponsored?: --- Bug ID: 7649 Assignee: gmcharlt(a)gmail.com Summary: remove kw,wrdl from search history QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Searching Product: Koha The kw,wrdl label was removed from the search results page, but it's still on the search history. The reason it was removed was that it was confusing to patrons, so either the label should be removed from the search history or it should be relabeled as just kw or something less confusing. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4078] Display active currency symbol on currency output and input
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '12

05 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4078 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veron(a)veron.ch -- You are receiving this mail because: You are watching all bug changes.

1 0