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

[Bug 5552] New: circ dates in the past
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '14

10 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5552 Summary: circ dates in the past Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: /cgi-bin/koha/circ/circulation.pl OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation 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 Estimated Hours: 0.0 Created attachment 2918 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2918 error box with due date When you choose a due date in the past a box appears asking you to confirm the date. This box should have a calendar icon and a date format tip like all other date boxes in Koha to prevent big mistakes. -- 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 5847] New: Manage Staged MARC Records stuck at 0% if isbn matching rule selected.
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '14

10 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5847 Bug #: 5847 Summary: Manage Staged MARC Records stuck at 0% if isbn matching rule selected. Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: critical Priority: P1 Component: MARC Bibliographic record staging/import AssignedTo: gmcharlt(a)gmail.com ReportedBy: kmkale(a)anantcorp.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com If we try to use ISBN match rule while importing a staged batch, the Manage Staged MARC Records gets stuck at 0%. I can see a www-data owned background job running but the browser is stuck at 0% and no entries in the db. Tried leaving it overnight with no progress. Tried with firefox and chrome. Same MARC file is imported fine without using the ISBN match rule. The same marc records file imports fine with bulkmarcimport.pl utility even with the -isbn option. Sadly the bulkmarcimport.pl lacks the option to still add items even while ignoring a biblio if a isbn match is found. See attached screenshot for rules used during this import. -- 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 7441] New: search results showing wrong branch?
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '14

03 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7441 Bug #: 7441 Summary: search results showing wrong branch? Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: ian.walls(a)bywatersolutions.com When you search in the OPAC it shows you the HOME branch on the location in XSLT (see here: http://screencast.com/t/m870Mr8Wm) but if you click through to the detail page it shows you the CURRENT BRANCH in the holdings table which is very confusing to patrons. I don't know what's the right solution - home or holding branch, but they should be the same in both places for the patron's sake. If you do the same search in the staff client you see the right branch info on the search results and on the detail page. Nicole -- 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 83

[Bug 7518] New: searches with quotation marks don't work
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '14

02 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7518 Bug #: 7518 Summary: searches with quotation marks don't work Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: melia(a)bywatersolutions.com QAContact: koha.sekjal(a)gmail.com A search term without quotation marks returns the expected results. The same search term with quotation marks returns no results. I expected Koha to ignore the quotation marks and return results anyway... -- 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 56

[Bug 7058] New: GetMemberDetails must die!
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '14

25 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7058 Bug #: 7058 Summary: GetMemberDetails must die! Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org The GetMemberDetails subroutine is insanely inefficient, and is used throughout Koha's code. In many cases, GetMember is more than sufficient (please see my rant on bug 5179). This report shall serve as the meta-report for all attempts to eliminate unnecessary calls get GetMemberDetails. Please file separate bug reports for specific instances, and list them as "blocking" this report. -- 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 5179] New: GetMember and GetMemberDetails should be combined
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '14

25 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5179 Summary: GetMember and GetMemberDetails should be combined Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 In Members.pm, GetMember and GetMemberDetails do almost the same thing. This common behaviour should be combined so that changes to this kind of thing don't have to happen in multiple places. Aiming for 3.4. -- 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 7572] New: Add Clubs & Services Feature
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '14

23 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7572 Bug #: 7572 Summary: Add Clubs & Services Feature Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: kyle.m.hall(a)gmail.com QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com Add the clubs and services feature to Koha. This feature has been in production at the Crawford County Federated Library system for a number of years now. This features adds the ability to create clubs and services which patrons may be enrolled in. It is particularly useful for tracking summer reading programs, book clubs and other such clubs. It includes 2 built-in service archetypes: Bestsellers Club : Batch generate a holds list which shuffles the holds queue when new items matching a given title or author are catalogued. New Items Weekly Mailing Lists : Create custom mailing lists to alert subscribers to new items in your library. -- 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 58

[Bug 6617] New: table of contents not printing right if entered right
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '14

22 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6617 Bug #: 6617 Summary: table of contents not printing right if entered right Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 4682 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4682 table of contents in 505$a If you're entering the table of contents in a series of $t and $r subfields (in the 505) then it doesn't print the table of contents to the OPAC or staff client right. A formatted table of contents looks like this (505$a): What is a mashup? / Darlene Fichter -- Behind the scenes : some technical details on mashups / Bonaria Biancu -- Making your data available to be mashed up / Ross Singer -- Mashing up with librarian knowledge / Thomas Brevik A slash after the title and before the author and a double dash in between the chapters. See the screenshots to see what I mean. The / should probably be entered by the cataloger, but the double dash should be entered by the template and the contents should show with XSLT turned on even if it's not in the $a only. -- 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 48

[Bug 6918] New: can't place holds on 'on order' items with AllowOnShelfHolds off
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6918 Bug #: 6918 Summary: can't place holds on 'on order' items with AllowOnShelfHolds off Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation 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 don't think this was always the case (but I might be wrong). If AllowOnShelfHolds is set to 'don't allow' then patrons cannot place holds on items that are marked 'on order' (not for loan=-1). Technically items on order are not on the shelf and should be allowed to be placed on hold. This may require a preference for people to say whether they want to allow holds on 'on order' items and/or what the not for loan value is for 'on order' since there is nothing stopping the user from changing the value from -1 to something else. The easy fix is just to make the system allow holds on items with -1 for notforloan like I think it was before. -- 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 6374] New: Use "size" as names/hash keys leads to an unexpected results when using Template::Toolkit (name of a virtual method there)
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6374 Bug #: 6374 Summary: Use "size" as names/hash keys leads to an unexpected results when using Template::Toolkit (name of a virtual method there) Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: januszop(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org In many places the name "size" is used as hash key when the hash is passed to the template system for display. So, for example, since "size" is used as a name of a column of bibioitems table, it appears (or not, depending on if it was defined or not) in elements of SEARCH_RESULTS (in catalogue/search.pl or opac-search.pl) and is passed to the template results.tt/opac-results.tt. Then, in [opac-]results.tt a test is being done: [% IF ( SEARCH_RESULT.size ) %] Now: if "size" was defined, everything is OK and the size will be displayed (e.g. 21 cm), BUT if it was not defined, then a "random" number appears. This is because "size" is one of the virtual methods defined in Template::Toolkit for every data type (cf. http://search.cpan.org/~abw/Template-Toolkit-2.22/lib/Template/Manual/VMeth…) So, if "size" was defined by Koha, it will overload the method, but if it was not, then 1) XXX.size exists anyway, 2) the virtual method size() is called -- and it returns the number of elements in the hash or loop etc., depending on what is referred. The number of suspicious similar spots is ca. 20: git grep "IF.*\.size" called in koha-tmpl The issue does not seem to me to be straightforward to resolve, so I am not proposing any patch at the time. Since it seems that in most of the cases it rooted in biblioitems.size column, maybe it would be the simplest to rename that column to 'format' (and make appropriate changes in the code)? Any other ideas? -- 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 27