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

[Bug 11570] New: Upgrade jQueryUI to latest version
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11570 Bug ID: 11570 Summary: Upgrade jQueryUI to latest version Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Koha master currently uses jQueryUI version 1.8.23. We should upgrade to the latest version, currently 1.10.3. This upgrade would not conflict with our version of jQuery. At the very least the upgrade would help with Bug 11042 because of improvements to the default jQueryUI CSS. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 11850] New: Bulkmarcimport does not append in logfile
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11850 Bug ID: 11850 Summary: Bulkmarcimport does not append in logfile Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bulkmarcimport has the -l option, which allows to write to a logfile. It does work, however, its behavior is not what we expect from a logfile. Indeed, bulkmarcimport erases the logfile each time it is executed. The expected behavior imho is to append the logs to the given file. Test plan: 1) use bulkmarcimport several times with the same logfile given with -l. 2) the logfile is erased every time. -> KO Apply the patch, then: 1) use bulkmarcimport several times with the same logfile given with -l. 2) the logs are correctly appended to the logfile. -> OK -- You are receiving this mail because: You are watching all bug changes.

1 19

[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 11993] New: Untranslatable confirm popup in request.tt
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11993 Bug ID: 11993 Summary: Untranslatable confirm popup in request.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr request.tt has the following untranslatable confirm popup: "Are you sure you want to delete this hold?" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 12018] New: add table sorting to patron card batches
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12018 Bug ID: 12018 Summary: add table sorting to patron card batches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label printing Assignee: cnighswonger(a)foundations.edu Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Table sorting should be added to the list of records in the patron card batch. Bug 11946 should be viewed for more details and a screenshot; I opened this bug since the patch that was pushed for 11946 only covered the item label batches part of the original bug. -- You are receiving this mail because: You are watching all bug changes.

1 11

[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

[Bug 11801] New: In transit hold items incorrectly labels as "Waiting to be pulled" on request.pl
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '14

18 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11801 Bug ID: 11801 Summary: In transit hold items incorrectly labels as "Waiting to be pulled" on request.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If an item needs to be transferred to fill a hold, the hold will be listed as 'Waiting to be pulled" while it is in transit. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 11958] New: classification sources help file has typo
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '14

18 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11958 Bug ID: 11958 Summary: classification sources help file has typo Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Documentation Assignee: nengard(a)gmail.com Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It says that the classification is the 942$2 when it's really the 952$2. Patch to follow. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 12000] New: staff users can set hold suspension dates to occur in the past
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '14

18 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12000 Bug ID: 12000 Summary: staff users can set hold suspension dates to occur in the past Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In the hold request management page, the datepicker lets staff users set the hold resumption date in the past. This doesn't seem useful: - if automatic hold un-suspension is enabled, the hold will flip back to unsuspended the next time the cronjob runs - if the user means to suspend a hold indefinitely, the way to do it is to not set a specific resumption date This issue also affects the datepicker for the resumption date on the checkout page. It does NOT affect the datepicker on the patron details page, which lets the staff user only pick dates in the future. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8