December 2013 - Koha-bugs - lists.koha-community.org

[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 9820] New: Missing space between 100/700 $a and $c (MARC21/XSLT)
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '14

22 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9820 Bug ID: 9820 Summary: Missing space between 100/700 $a and $c (MARC21/XSLT) Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de For names consisting of 100/700 $a and $c there is no space between $a and $c in OPAC MARC21 detail page and result list using XSLT. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 11394] New: "Routing lists" -tab vanishes from patron info bar
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '14

22 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11394 Bug ID: 11394 Summary: "Routing lists" -tab vanishes from patron info bar Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you've looked up a patron, and you have the info on the left side of the screen, with the tabs "Check Out", "Details", "Fines", etc, the "Routing Lists" -tab vanishes, if you go to the "Purchase suggestions" -tab. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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 10700] New: Remove misc/cronjobs/rss
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '14

21 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10700 Bug ID: 10700 Summary: Remove misc/cronjobs/rss Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The RSS cron script hasn't been touched for years, and the associated template files predate our switch to Template Toolkit. Since we now have the ability to make the results of saved SQL reports public, I think we should consider this RSS system dead and remove it. -- You are receiving this mail because: You are watching all bug changes.

1 3

[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 10790] New: adding/editing item types screen mis aligned if noItemTypeImages not showing
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10790 Bug ID: 10790 Summary: adding/editing item types screen mis aligned if noItemTypeImages not showing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 20661 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=20661&action=edit add item type See attached. When you have noItemTypeImages set to "Don't show" everything goes wonky on the add item type screen. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 11393] New: Language menu not show up as name for Thai (th-THA was shown)
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11393 Bug ID: 11393 Summary: Language menu not show up as name for Thai (th-THA was shown) Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pongtawat.c(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr When Thai translation is installed and enabled. The language menu at the bottom of OPAC screen shown up as language code "th-THA". Also, the preference "language" and "opaclanguage" also show up as "(th-THA)". However, if I change the Thai template folder from "opac-tmpl/prog/th-THA" to "opac-tmpl/prog/th", the language menu, as well as the preferences, will display entry for Thai as "ภาษาไทย" which is correct. So, I don't know if there is some value missing (or incorrect) in database for "th-THA" or that the translation template should be "th". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[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

[Bug 10466] New: Lists: 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=10466 Bug ID: 10466 Summary: Lists: 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 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au This is an old bug that has been spotted again. This time, it's been noticed in the Lists/Virtual Shelves... Basically, itemsloo.size produces different results depending on the type of data that is in the itemsloo hash (within the itemsloop array): 1) If "size" has a value, that value will be printed out. 2) If "size" is null/undef, a seemingly random number will print out. 3) If there is no "size" key in the hash, a seemingly random number will print out. (N.B. In fact, this "random" number is the number of keys in the itemsloo hash. "Size" is a virtual method in the template toolkit. http://www.template-toolkit.org/docs/manual/VMethods.html.) -- Currently, elsewhere in Koha (bug 6374 which covers search.pl, addbooks.pl, opac-search.pl), we're checking to see if a "size" key exists, and if not, we're inserting a "size" key with a value of "". In this case, as long as the SQL query includes the size column, there will always be a "size" key (so scenario 3 is irrelevant). We need to check if "size" is "defined", and if it's not (scenario 2 from above), then we change it to a blank (e.g. "") value, so that it just prints out nothing. The fact that "size" does print a value is probably a bug in TT, so I don't think this is the best long-term solution. It would probably make more sense to rename the variable that we're passing to TT, because if TT gets "fixed" so that "size" always operates as a method rather than fetching the value of a hash, we are going to have to do this all over again. -- You are receiving this mail because: You are watching all bug changes.

1 12