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

[Bug 6137] New: Fix a little bug when userenv is null
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '12

08 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6137 Bug #: 6137 Summary: Fix a little bug when userenv is null Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: julian.maurice(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Coming patch just adds a test which check userenv is not null before using it. -- 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 19

[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 5503] New: comments shouldn't show patron's full name
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '12

02 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5503 Summary: comments shouldn't show patron's full name Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: OPAC Comments AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When leaving comments in the OPAC it shows the patron's full name. This is done without asking the patron if they approve of sharing that info. Either it should show the first name last initial, patron initials, or should give the patrons a choose of what name to show (like on most blogging applications). No matter what we shouldn't show the full name of the patron on the OPAC for all to see without asking them if it's okay. -- 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 29

[Bug 6008] New: Installation might fail it user web doesn't have in its path the database command path
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '12

27 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6008 Bug #: 6008 Summary: Installation might fail it user web doesn't have in its path the database command path Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: Other Status: ASSIGNED Severity: enhancement Priority: P5 Component: Installation and upgrade (web-based installer) AssignedTo: salva(a)masmedios.com ReportedBy: salva(a)masmedios.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com In Installer.pm when is looking for the system command to dump a file into the database it might fail if the web user doesn't have it in its path env variable. E.g.: with OpenBSD 4.8 the web user "www" doesn't have the path to the installed mysql bin: /usr/local/bin/mysql and fails in the web installer. -- 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 7467] New: Printing Transfer Slips that do not have holds
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '12

27 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7467 Bug #: 7467 Summary: Printing Transfer Slips that do not have holds 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: srdjan(a)catalyst.net.nz QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com Work to be done: * Create circ/transfer-slip.pl and circ/transfer-slip.tt similar to hold-transfer-slip * circ/returns.tt: add "Yes and Print Slip" button that will call Dopop('transfer-slip.pl') * Remove inputloop and ri-* variables code from circ/returns, it is not used and is confusing How to test: * When returning an item without holds rhat needs to be transferred to home branch "Yes and Print Slip" button should show * Click athe button and print slip. Meaningful To and From branch, as well as item info should print -- 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 17

[Bug 6752] New: Be stricter with utf-8 output
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '12

27 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6752 Bug #: 6752 Summary: Be stricter with utf-8 output Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: colin.campbell(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org Many IO handles are opened in Koha with the parameter ':utf8' the result is to flag strings output ( or input )as being utf-8 strings. However the it does accept invalid utf8. To validate the output the parameter ':encoding(UTF-8) is required. We should at least be strict with what we output. As the use of :utf8 is flagged by Perl::Critic policies as a violation the QA test 00-percritic.t fails three tests. We should be stricter with output encodings -- 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 21

[Bug 7433] New: french translation add a bad single quote into js function
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '12

27 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7433 Bug #: 7433 Summary: french translation add a bad single quote into js function Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N AssignedTo: frederic(a)tamil.fr ReportedBy: stephane.delaune(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com in staff, the french version of cgi-bin/koha/tools/stage-marc-import.pl have this line into a javascript's function : alert(_('Echec de l'envoi du formulaire : ') + textStatus); (original text : alert(_('Failed to submit form: ') + textStatus);) the single quote isn't escaped -- 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 8

[Bug 5358] New: keep track of cancelled orders
by bugzilla-daemon＠bugs.koha-community.org 22 Feb '12

22 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5358 Summary: keep track of cancelled orders Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All URL: http://wiki.koha-community.org/wiki/Cancelled_orders_a cq_RFC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Deadline: 2011-05-01 We will add a table deletedaqorders that will keep track of all deleted orders. >From a given basket, there will be a link to display deleted orders line -- 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 17