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

[Bug 5905] New: Biblibre, Partial fine payments
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '12

08 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5905 Bug #: 5905 Summary: Biblibre, Partial fine payments Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 5575 -- 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 5728] New: Adding note and manager_id fields to accountlines
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '12

08 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5728 Summary: Adding note and manager_id fields to accountlines Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 * manager_id contains the librarian that created the line * note is a field that can be entered by the 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 14

[Bug 6694] New: Anonymous sessions not kept when casAuthentication is on
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '12

08 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6694 Bug #: 6694 Summary: Anonymous sessions not kept when casAuthentication is on Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: julian.maurice(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org In OPAC, if I am an anonymous user and the system preference casAuthentication is set, each time I reach a new page, the CGISESSID cookie gets a new value, causing the previous session to be destroyed and a new one to be created. This bug comes from an error in checkauth (C4/Auth.pm), where a missing test cause this strange behavior. Also found a similar issue in check_api_auth, which cause C4::Service->init to fail if the syspref is set. For example, I was unable to change a syspref value when casAuthentication was set. Patch will follow. -- 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 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 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