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

[Bug 8685] Inventory tool fails in timeout with large CB files
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8685 --- Comment #23 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Thx for testing and sharing your results! Glad that the situation seems to have improved! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8685] Inventory tool fails in timeout with large CB files
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8685 --- Comment #22 from emjhet(a)pa.net --- (In reply to Katrin Fischer from comment #21) > > I think noone was able to retest this yet. If you have a test system > available to you, you could create a report in order to get a long list of > barcodes and test with that. That could help to verify if the bug still > exists. I am using Koha 17.11.06. I ran a test batch through the inventory module. It had 3747 items in it and it did not time out! It may be because the results are coming back differently. Instead of getting results that list each barcode and the fact that the item's status was updated, only the "problem" items were listed (things that were checked out, missing, etc.) And it actually used the date that I told it to (which it did one time I ran an inventory and another time it did not.) So this may not be a problem any longer. I do not have another library location that I can run a fake inventory on at this time to see if a larger file would run successfully. Please do note that we do not have the fastest internet here, so those with better connections may be able to run larger files. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9921] Make it possible to force 001 = biblionumber
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #62 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I understand, just trying to prevent you from doing something that might break stuff (because people have gone there before). I can't tell you why for Koha 999c was chosen in the beginning, but it's one of the things that will need quite a bit of thinking if we wanted to change it now. I think here are patches around to make a plugin to set 001 individually. I am using a variation of the stocknumberAV plugin in one of our libraries to create numbers, but you have to trigger it and it doesn't move the number to 035 as they only do original cataloguing. A catalouging plugin might be a route to explore. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9921] Make it possible to force 001 = biblionumber
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #61 from emjhet(a)pa.net --- (In reply to Katrin Fischer from comment #60) > The biblionumber is not a sequentially created number of the application, > but it's the primary key assigned by the database. That's why it will only > be set after saving a record for the first time - before it doesn't exist. > I understand the purpose of the biblionumber. It is what MARC says the field 001 is for. I am trying to understand why Koha chose to use the 999$c for this information instead of the 001, and the implications this decision has on our library. Although it is not good cataloging practice, Koha recommends importing a "close" record if you can not find a matching record in your Z39.50 search. Then simply alter the record as needed. This has happened at the library where I work. However, the 001 field was not changed. Often these records were imported from our state union catalog. Because Koha does not create a unique 001, these records would be for different items but have the same 001, and our holdings would likely be attached to the wrong record. Thus we could receive requests for items that we do not, in fact, own. Thus this matter is not merely academic for us. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10198] Add the ability to import and export authorized values
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10198 George Williams (NEKLS) <george(a)nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |george(a)nekls.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14570] Make it possible to add multiple guarantors to a record
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14570 --- Comment #109 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 77078 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=77078&action=ed… Bug 14570: Update schema files [Do Not Push] -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14570] Make it possible to add multiple guarantors to a record
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14570 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77067|0 |1 is obsolete| | Attachment #77068|0 |1 is obsolete| | Attachment #77069|0 |1 is obsolete| | Attachment #77070|0 |1 is obsolete| | Attachment #77071|0 |1 is obsolete| | Attachment #77072|0 |1 is obsolete| | Attachment #77073|0 |1 is obsolete| | Attachment #77074|0 |1 is obsolete| | Attachment #77075|0 |1 is obsolete| | Attachment #77076|0 |1 is obsolete| | --- Comment #108 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 77077 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=77077&action=ed… Bug 14570: Make it possible to add multiple guarantors to a record This patch adds the ability to set an unlimited number of guarantors for a given patron. As before, each guarantor may be linked to another Koha patron, and all the behavior that applies to a given guarantor remains the same. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Find some patrons with guarantors, verify the still have their guarantor 4) Test adding and removing guarantors on a patron record, both Koha users and not 5) Verify the "Add child" button works 6) Verify NoIssuesChargeGuarantees still works 7) Verify tools/cleanborrowers.pl will not delete a guarantor 8) Verify the guarantors are displayed on moremember.pl 9) Verify the guarantor is removed by members/update-child.pl 10) Verify the guarantor is removed by misc/cronjobs/j2a.pl 11) Verify import patrons converts guarantor_id, relationship, contactfirstname, and contactsurname into a guarantor 12) prove t/Patron.t 13) prove t/db_dependent/Circulation.t 14) prove t/db_dependent/Circulation/NoIssuesChargeGuarantees.t 15) prove t/db_dependent/Items.t 16) prove t/db_dependent/Koha/Patrons.t 17) prove t/db_dependent/Members.t 18) prove t/db_dependent/Patron/Relationships.t Signed-off-by: Kim Peine <kmpeine(a)gmail.com> Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20259] New: Shorter JS and CSS rewrite rule
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20259 Bug ID: 20259 Summary: Shorter JS and CSS rewrite rule Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bug 20187 has changed the JS and CSS rewrite rules to : RewriteRule ^(.*)_[0-9][0-9]\.[0-9][0-9][0-9][0-9][0-9][0-9][0-9].js$ $1.js [L] RewriteRule ^(.*)_[0-9][0-9]\.[0-9][0-9][0-9][0-9][0-9][0-9][0-9].css$ $1.css [L] This can be written more short with one rule and [0-9]{N}. And the dot in extension needs to be escaped : \.js \.css -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 8326] Allow patron attributes to be made repeatable after initial creation
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8326 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |20443 CC| |jonathan.druart(a)bugs.koha-c | |ommunity.org --- Comment #1 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- If bug 20443 is integrated rapidly I will have a look at fixing this bug. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20443 [Bug 20443] Move C4::Members::Attributes to Koha namespace -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 20325] New: C4::Accounts::purge_zero_balance_fees does not check account_offsets.
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20325 Bug ID: 20325 Summary: C4::Accounts::purge_zero_balance_fees does not check account_offsets. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org purge_zero_balance_fees is used in cleanup_database.pl to determine which fees can be cleaned up. It uses a simple SQL query to determine which rows in accountlines need to be removed: 463 my $sth = $dbh->prepare( 464 q{ 465 DELETE FROM accountlines 466 WHERE date < date_sub(curdate(), INTERVAL ? DAY) 467 AND ( amountoutstanding = 0 or amountoutstanding IS NULL ); 468 } The function comes with the following warning: 451 B<Warning:> Because fines and payments are not linked in accountlines, it is 452 possible for a fine to be deleted without the accompanying payment, 453 or vise versa. This won't affect the account balance, but might be 454 confusing to staff. This was a reasonable solution prior to the addition of account_offsets in 17.11. The problem now is that rows in accountlines which are linked as credits in accountlines will *always* have amountoutstanding marked as 0. These are linked to debits via account_offsets. purge_zero_balance_fees will delete credits and leave rows in account_offsets which link to deleted credits. Sites using the --fees option cleanup_database.pl which upgrade to 17.11 may have all of their credits removed without warning. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24