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

[Bug 1807] search () give odd results
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1807 --- Comment #14 from John Andrews <jandrews(a)washoecounty.us> --- Have tried various searches -- links with no parentheses work fine, all links I've found with parentheses return the broken search results. Cache cleared, and double-checked to make sure I copied the full script -- everything *looks* like it should be working correctly, but we still only get parentheses removed in the opac and not the staff client. John -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 1807] search () give odd results
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1807 --- Comment #13 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to John Andrews from comment #12) > We're on 3.16.03.000. > > There are no other scripts in intranetuserjs that should affect details > pages at all so I'm not sure where to even begin looking for a conflict. There may be conditions it is not able to catch. Have you tried other searches? Christopher -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 1807] search () give odd results
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1807 --- Comment #12 from John Andrews <jandrews(a)washoecounty.us> --- We're on 3.16.03.000. There are no other scripts in intranetuserjs that should affect details pages at all so I'm not sure where to even begin looking for a conflict. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 1807] search () give odd results
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1807 --- Comment #11 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to John Andrews from comment #10) > The JS solution is working brilliantly in the OPAC, but there is no change > on the staff side when I include this in intranetuserjs -- any suggestions > on how to make it work there as well? It's working on our end. Perhaps there is a conflicting jQuery? What version of Koha on you on? Christopher -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4402] Date filter in parcels.tt requires db format dates
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4402 --- Comment #29 from Jonathan Druart <jonathan.druart(a)biblibre.com> --- The easier thing to do would be to add a check on all inputs managed by datepicker to validate what the user filled. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 12792] New: C4::Reserves breaks my vim syntax color
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12792 Bug ID: 12792 Summary: C4::Reserves breaks my vim syntax color 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: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org [I am sorry for this...] C4/Reserves.pm is unreadable with my vim configuration. It appears I am the only one having this problem. For an incomprehensible reason, a string constructs with qq/my string/; completely breaks the syntax color for all the rest of the file (~2300l). If I replace it with qq{my string}; all is fine! -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 4402] Date filter in parcels.tt requires db format dates
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4402 --- Comment #28 from Marc Véron <veron(a)veron.ch> --- The crash occurs in Koha/DateUtils.pm DateUtils.pm line 92, sub dt_from_string return DateTime::Format::DateParse->parse_datetime( $date_string, $tz->name() ); Description: Passed a date string returns a DateTime object format and timezone default to the system preferences. If the date string is empty DateTime->now is returned I propose to have a new bug to change the function for testing the validity of the string and return DateTime->now as well if the date string is not valid. Validation could be done e.g. with DateTime::Format::DateManip->parse_datetime ( $datestring ). -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 4402] Date filter in parcels.tt requires db format dates
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4402 --- Comment #27 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I think the datepicker is not the problem here - that's just the way data gets into the field. The date processing in the .pl is what throws the error. It didn't before, because there was no date processing :( -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4402] Date filter in parcels.tt requires db format dates
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4402 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=11448 -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4402] Date filter in parcels.tt requires db format dates
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4402 --- Comment #26 from Marc Véron <veron(a)veron.ch> --- I agree with Jonathan that I am not supposed to give a wrong date. I did it accidentally, and other users will do that for sure :-) Koha should handle it gracefully and not crash with a software error. And I agree with Katrin that we should have a more general solution for fields that involve DatePicker. This would be an other bug. (Keep in mind Bug 11448 /Accessibility) At other places the date is validated by JavaScript, e.g. on memberentry.pl. If I enter a wrong month for date of birth, I get a warning "Invalid month entered in field dateofbirth" The related JavaScript function CheckDate() comes from /intranet-tmpl/prog/en/js/members.js (= local solution) For this bug the question is: Keep DatePicker and have the chance for crashes if a user skips the DatePicker with a wrong date? If yes, I'll sign-off. Or keep it the old way (no DatePicker, no crash) until we have a more general solution? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0