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

[Bug 14399] New: Remove "missingitem" code from inventory.pl
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '15

17 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14399 Bug ID: 14399 Summary: Remove "missingitem" code from inventory.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, there are two different states (described as "problems") in the code of inventory.pl. One is for "missingitem" and the other is for "not_scanned". After much whingeing and discussion, I decided that these are basically the same state, although they're obtained in slightly different ways: 1) "not_scanned" is determined by comparing the scanned barcodes against the inventory list. 2) "missingitem" is determined by comparing the inventory's "datelastseen" against the inventory list's items' "datelastseen". The first one seems logical. It's "not_scanned" if it wasn't scanned. However, the second one is strange. It's not even in relation to the actual task of taking inventory. This state also isn't determined "after" running the inventory, which might almost make sense. No, it's right after creating an inventory list. On top of this weirdness, the code also has an unintentional bug. Observe the following block of code: # If "compare barcodes list to results" has been checked, we want to alert for missing items if ( $compareinv2barcd ) { # set "missing" flags for all items with a datelastseen (dls) before the choosen datelastseen (cdls) my $dls = output_pref( { dt => dt_from_string( $datelastseen ), dateformat => 'iso' } ); foreach my $item ( @$inventorylist ) { my $cdls = output_pref( { dt => dt_from_string( $_->{datelastseen} ), dateformat => 'iso' } ); if ( $cdls lt $dls ) { $item->{problem} = 'missingitem'; # We have to push a copy of the item, not the reference push @items_with_problems, { %$item }; } } } Firstly, contrary to the comment, "dls" is actually the inventory's "datelastseen", while "cdls" is the "datelastseen" of the item. Annoying? Yes, but not super important. The important thing here is "my $cdls = output_pref( { dt => dt_from_string( $_->{datelastseen} ),". It turns out that when you use "foreach my $item ( @$inventorylist )" instead of "foreach ( @$inventorylist )", "$_" will actually be null and not the element from the list! So "dt_from_string" seems to create a DateTime object with today's date. So $cdls will always have a date of today. The only way to get "missingitem" to appear is if your "Inventory date:" (not to be mistaken with "Set inventory date to:" inventory date is in the future. Which... would be weird to do... but it's possible. And because this only happens when you're comparing the uploaded barcodes against the inventory list... and because missingitem is done on the inventory list... everything is going to be marked missing in your inventory report! -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 12631] New: Inventory: fix "wrong place" and "item not scanned" statuses
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '15

17 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12631 Bug ID: 12631 Summary: Inventory: fix "wrong place" and "item not scanned" statuses Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org What's wrong: ------------- The current behavior in the inventory tool for item statuses is wrong on two points: 1) "item not scanned" status: when calling GetItemsForInventory, datelastseen should be used when "compare barcodes list to result" is checked. Otherwise, when loading multiple barcodes files for the same inventory, many items will be marked as "item not scanned" when loading the last barcode file ("compare barcodes list to result" checked) even though they were scanned. 2) "wrong place" status: when searching for wrongly placed items, we should only check for the location (callnumbers, location and branch). To fix this, A new call to GetItemsForInventory has been made with location filters only. Otherwise, any item with a different itemtype for instance will be marked as wrong place even if the location is correct. Test plan: ---------- Providing a strict and precise test plan is quite hard, as it is strongly dependant of your database, but you can check as follow: "item not scanned" status: 1) Split a barcode file in two. 2) Load the first barcode file without checking "compare barcodes list to result". 3) Load the second barcode file with "compare barcodes list to result" checked. 4) Check in the csv report that you have a lot of scanned items with the "item not scanned" status. Then apply the patch, do the same, and check that the false "item not scanned" statuses are gone. "wrong place" status: 1) Load a barcode file with barcode matching an item that has a correct location, but a different itemtype than what you're looking for. 2) Check in the results that this item will be marked as "change item status" and "wrong place". Then apply the patch, do the same, and check that the only status for this item is "change item status", which is correct. Remarks: -------- I'm expecting concerns about the fact that GetItemsForInventory is now called twice instead of once, but keep in mind that inventory is a quite rare operation. Also, I did not manage to find a more efficient way to fix this wrong behavior, suggestions welcome. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 11067] New: In serial home instead of 'Advanced search' on sx column it is better 'Filters on search results'
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '15

17 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11067 Bug ID: 11067 Summary: In serial home instead of 'Advanced search' on sx column it is better 'Filters on search results' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: z.tajoli(a)cineca.it QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Created attachment 22025 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=22025&action=edit image of serial home In serial home (cgi-bin/koha/serials/serials-home.pl) there is a link 'Advanced search' on the sx column, over 'Claims' and 'Check expiration'. But it doens't do a search on zebra or on mysql. It is a js filter that works only on results of a previous search. To use it you need: -- Do a search with one ot the two instrument on the top -- Open the box and insert a filter on results. So I suggesto to change the string from 'Advanced search' to 'Filters on search results'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 2389] overdue_notices.pl needs a test mode
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '15

16 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2389 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de --- Comment #5 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Barton Chittenden from comment #3) > Additional side effect: when run with -t (trigger notices) and -n (no > email), no emails are sent, the list of emails rendered is limited to the > set that are triggered, but the triggers themselves are not re-set; the next > time that overdue_notices.pl is run with the -t option, any notices > triggered on the original run are *not* emailed. > > This was definitely unexpected behavior. I don't think that this behaviour is possible - the triggers are just calculations on the due date, there is nothing to be reset in the database? I am afraid escalating this from enh to bug won't make it move faster, unless someone spends time to implement and test this. There is a similar bug about a test mode for notices - bug 8000 - waiting for sign-off. But it won't stop it from debarring I think. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2389] overdue_notices.pl needs a test mode
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '15

16 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2389 Barton Chittenden <barton(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal CC| |barton(a)bywatersolutions.com --- Comment #4 from Barton Chittenden <barton(a)bywatersolutions.com> --- I've escalated the status on this -- this causes real pain during the trouble-shooting of overdue notices, and it's been languishing for years. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14396] New: library groups are allowed to have same codes as branches
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '15

16 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14396 Bug ID: 14396 Summary: library groups are allowed to have same codes as branches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a library group has the same code as a branch then when you search the library you get group results. The system should prevent you from creating a group with the same code as a library. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14334] New: DBI fighting DBIx over Autocommit in tests
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '15

16 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14334 Bug ID: 14334 Summary: DBI fighting DBIx over Autocommit in tests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: mtompset(a)hotmail.com QA Contact: gmcharlt(a)gmail.com As per an email on the KohaDev list, tcohen pointed out the problem. gmcharlt pointed out a solution here: http://paste.lisp.org/display/149194 --- BEGIN PASTE --- diff --git a/t/db_dependent/Letters.t b/t/db_dependent/Letters.t index f53e75b..8599c3f 100644 --- a/t/db_dependent/Letters.t +++ b/t/db_dependent/Letters.t @@ -45,11 +45,15 @@ use t::lib::Mocks; use Koha::DateUtils qw( dt_from_string output_pref ); use Koha::Acquisition::Order; use Koha::Acquisition::Bookseller; +use Koha::Database; my $dbh = C4::Context->dbh; +my $database = Koha::Database->new(); +my $schema = $database->schema(); +$schema->storage->txn_begin(); + # Start transaction -$dbh->{AutoCommit} = 0; $dbh->{RaiseError} = 1; $dbh->do(q|DELETE FROM letter|); @@ -341,4 +345,4 @@ is($err, 1, "Successfully sent claim"); is($mail{'To'}, 'testemail(a)mydomain.com', "mailto correct in sent claim"); is($mail{'Message'}, 'my vendor|John Smith|Ordernumber ' . $ordernumber . ' (Silence in the library) (1 ordered)', 'Claim notice text constructed successfully'); -$dbh->rollback; +$schema->storage->txn_rollback(); --- END PASTE --- And I have volunteered to do it. -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 9394] New: Use reserve_id where possible
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '15

16 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9394 Bug ID: 9394 Summary: Use reserve_id where possible Classification: Unclassified 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 CC: gmcharlt(a)gmail.com This patch switches from using a combination of biblionumber/borrowernumber to using reserve_id where possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 74

[Bug 8835] New: Two indexes on biblioitems.issn
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '15

16 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8835 Priority: P5 - low Change sponsored?: --- Bug ID: 8835 Assignee: gmcharlt(a)gmail.com Summary: Two indexes on biblioitems.issn Severity: minor Classification: Unclassified OS: All Reporter: fridolyn.somers(a)biblibre.com Hardware: All Status: NEW Version: master Component: Database Product: Koha In update database script : 3.01.00.006 adds an index called 'issn' on biblioitems.issn. 3.01.00.093 also adds an index on biblioitems.issn, called 'issn_idx'. In kohastructure, only 'issn' index exists for biblioitems. So udpate 3.01.00.093 is useless. Can it be removed ? -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 3206] OAI repositry deleted record support
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '15

16 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3206 Jonathan Druart <jonathan.druart(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff --- Comment #18 from Jonathan Druart <jonathan.druart(a)biblibre.com> --- I would like to get a signoff on the second patch. -- You are receiving this mail because: You are watching all bug changes.

1 0