July 2016 - Koha-bugs - lists.koha-community.org

[Bug 5456] Create a link to opac-ics.pl
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5456 --- Comment #8 from Magnus Enger <magnus(a)libriotech.no> --- First of all let me say that I am no iCal expert! I created a small test script: --- #!/usr/bin/perl use Modern::Perl; use DateTime::Format::ICal; use Koha::DateUtils; my $datestring = '2016-03-10 23:59:00'; my $dt = dt_from_string( $datestring ); say DateTime::Format::ICal->format_datetime( $dt ); my $dt2 = dt_from_string( $datestring ); $dt2->set_time_zone( C4::Context->tz ); say DateTime::Format::ICal->format_datetime( $dt2 ); my $dt3 = dt_from_string( $datestring ); $dt3->set_time_zone( 'UTC' ); say DateTime::Format::ICal->format_datetime( $dt3 ); --- This gives the following output: TZID=Europe/Oslo:20160310T235900 TZID=Europe/Oslo:20160310T235900 20160310T225900Z I tested the output from Koha in a couple of different validators. When I have a date like TZID=Europe/Oslo:20160310T235900 in the ICS I get errors from the validators: Error: Error was: Error at line 15:[DTSTART] Unparseable date: "TZID=Europe/Oslo:20160810T235900" Cause: Caused by: [DTSTART] Unparseable date: "TZID=Europe/Oslo:20160810T235900" http://severinghaus.org/projects/icv/ Invalid DTSTART value, must be a date or date-time value near line # 11 http://icalendar.org/validator.html When I change the script so all dates look like 20160310T225900Z, I get no errors from the same validators. In addition, Marc has said that Thunderbird accepts this (but not TZID=Europe/Oslo:20160310T235900) *and* interprets the date and time correctly. My pragmatic side tells me this should be good enough. :-) >From https://metacpan.org/pod/DateTime::Format::ICal: "The iCal spec requires that datetimes be formatted either as floating times (no time zone), UTC (with a 'Z' suffix) or with a time zone id at the beginning ('TZID=America/Chicago;...')." The way I read this, "formatting as UTC" is just as good as having a "time zone id at the beginning". -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 14514] LocalHoldsPriority and the HoldsQueue conflict with each other
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14514 --- Comment #18 from Kyle M Hall <kyle(a)bywatersolutions.com> --- (In reply to Liz Rea from comment #15) > *with this patch, the reserve doesn't show up on any hold queue. Without it, > as you noted, it does show up on the wrong priority library's hold queue. Do you have Local Holds Priority enabled? Can you try again with it switched both on and off? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14514] LocalHoldsPriority and the HoldsQueue conflict with each other
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14514 --- Comment #17 from Kyle M Hall <kyle(a)bywatersolutions.com> --- (In reply to Liz Rea from comment #14) > Should we expect that this local hold that has priority for a branch turn up > on the hold queue? Or do we only care about what happens when an item is > checked in? > > My instinct says that a local hold priority item should show up on the hold > queue for the prioritised library/item/borrower > > Example, Patron from springfield has a biblio level reserve for a book that > has a springfield copy, the springfield copy is available, should this turn > up on the hold queue for springfield? > > Currently the reserve doesn't show up on any hold queue. Is that correct > behaviour? How would the library know the reserve exists in this case > without scanning it to trap it? Yes, the hold should show up in the holds queue. That's all this patch is supposed to do is to select the same patron for the holds queue that would be selected if the item in question was not already in the holds queue. The problem right now is the holds queue is choosing the wrong patron. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14514] LocalHoldsPriority and the HoldsQueue conflict with each other
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14514 Barton Chittenden <barton(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #51595|0 |1 is obsolete| | --- Comment #16 from Barton Chittenden <barton(a)bywatersolutions.com> --- Created attachment 53787 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=53787&action=ed… [SIGNED-OFF] Bug 14514 - LocalHoldsPriority and the HoldsQueue conflict with each other It appears that the LocalHoldsPriority feature and the Holds Queue are fundamentally at odds with each other. The problem appears to be that both are attempting to choose the best way to fill holds. When you are using the holds queue and you check in an item that has been selected by the holds queue builder, that part of Koha where the LocalHoldsPriority feature lives doesn't get to see all the holds in order to pick the best one. Instead only the hold selected by the holds queue builder is returned so to the LocalHoldsPriority feature, that is only one hold to pick from! Test Plan: 1) Apply this patch 2) prove t/db_dependent/HoldsQueue.t 3) All tests should pass Signed-off-by: Barton Chittenden barton(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6934] New report Cash Register Statistics
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6934 Héctor Eduardo Castro Avalos <hector.hecaxmmx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 6934] New report Cash Register Statistics
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6934 Héctor Eduardo Castro Avalos <hector.hecaxmmx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #53778|0 |1 is obsolete| | --- Comment #101 from Héctor Eduardo Castro Avalos <hector.hecaxmmx(a)gmail.com> --- Created attachment 53780 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=53780&action=ed… [SIGNED-OFF]Bug6934: fix errors pointed out by the QA script Also fix forbidden patterns in koha-tmpl/intranet-tmpl/prog/en/modules/reports/reports-home.tt Signed-off-by: Hector Castro <hector.hecaxmmx(a)gmail.com> -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 6934] New report Cash Register Statistics
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6934 --- Comment #100 from Héctor Eduardo Castro Avalos <hector.hecaxmmx(a)gmail.com> --- Passing QA-Test Tool I got: FAIL reports/cash_register_stats.pl OK critic OK forbidden patterns OK pod OK spelling 0 FAIL valid Name "Cache::RemovalStrategy::FIELDS" used only once: possible typo Name "Tie::Hash::FIELDS" used only once: possible typo Name "Cache::RemovalStrategy::LRU::FIELDS" used only once: possible typo Use of uninitialized value $_[0] in lc But I think this is a problem caused for bug 11998 and explained for Jonathan in bug 16104 if you test with: $ perl -cw reports/cash_register_stats.pl you obtain: Use of uninitialized value $_[0] in lc at /usr/share/perl5/Cache.pm line 485. Use of uninitialized value $_[0] in lc at /usr/share/perl5/Cache.pm line 485. Use of uninitialized value $_[0] in lc at /usr/share/perl5/Cache.pm line 485. Name "Tie::Hash::FIELDS" used only once: possible typo at /usr/share/perl/5.14/fields.pm line 135. Name "Cache::RemovalStrategy::FIELDS" used only once: possible typo at /usr/share/perl/5.14/fields.pm line 135. Name "Cache::RemovalStrategy::LRU::FIELDS" used only once: possible typo at /usr/share/perl/5.14/fields.pm line 135. reports/cash_register_stats.pl syntax OK But all this errors are from bug 11998 Still FAIL koha-tmpl/intranet-tmpl/prog/en/modules/reports/reports-home.tt FAIL forbidden patterns forbidden pattern: tab char (line 36) forbidden pattern: tab char (line 37) forbidden pattern: tab char (line 35) forbidden pattern: tab char (line 34) forbidden pattern: tab char (line 31) forbidden pattern: tab char (line 33) forbidden pattern: tab char (line 39) forbidden pattern: tab char (line 32) But I will fix it up in the last patch -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 6934] New report Cash Register Statistics
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6934 --- Comment #99 from Bouzid <bouzid.fergani(a)inlibro.com> --- Hi Héctor, ok, thanks. Regards -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 14844] Corrupted storable string. When adding/editing an Item, cookie LastCreatedItem might be corrupted.
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14844 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #42644|0 |1 is obsolete| | --- Comment #4 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- Created attachment 53779 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=53779&action=ed… Bug 14844: Corrupted storable string. When adding/editing an Item, cookie LastCreatedItem might be corrupted. No idea how to replicate this issue but we have been getting several reports about the following error: Software error: Corrupted storable string (binary v2.9) at /usr/lib/perl/5.18/Storable.pm line 417, at /home/koha/kohaclone/cataloguing/additem.pl line 375. TEST PLAN: 1. Add or modify an Item. 2. No observed changes. ?. We don't know what causes this but we know that add/modify Item occasionally crashes due to failure of a cookie thawing. This patch prevents the whole program from dying, because this error is not critical enough to warrant dying. Also there is no centralized mechanism in Koha for showing messages to the user, so there is no easy and convenient way to warn the user that the: 'LastCreatedItem'-cookie or the systempreference 'PrefillItem' is malfunctioning. So we instead just warn to the server logs with the malfunctioning cookie in hopes of nailing down what causes the issues. Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14844] Corrupted storable string. When adding/editing an Item, cookie LastCreatedItem might be corrupted.
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '16

28 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14844 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are watching all bug changes.

1 0