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

[Bug 14816] New: Item search returns no results with multiple values selected for one field
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14816 Bug ID: 14816 Summary: Item search returns no results with multiple values selected for one field Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle.m.hall(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If you select multiple values from the pulldown for a give field ( e.g. home library ), the search will never return results. I believe this issue is due to the fact that the query is using IN but is treating the entire list of values for the IN as a single string to be quoted, instead of a list of comma separated string to be quoted individually. 'str' => '(homebranch IN (?))' 'args' => 'CPL,FFL,FPL,FRL,IPT,LPL,MPL,MY,PVL,RPL,SPL,TPL,UPL' -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 15103] New: Import Borrowers Performance Improvement
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15103 Bug ID: 15103 Summary: Import Borrowers Performance Improvement Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cnorthcott.work(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Blocks: 7923 Import Borrowers has a long run/load time to import batch of borrowers. I have attempted to improve the runtime of the import borrowers tool and my enhancement reduces the time to import by an average of 22%. I discovered the extended runtime was mostly due to the intentionally expensive password hashing algorithm used by Koha which is largely unavoidable, but I was able to save some time by switching calls to DBIx::Class::ResultSet to reduce the import of 5000 patrons from 242.2 seconds to 187.8 seconds, saving almost a whole extra minute (54.4 seconds) of database calls. Referenced Bugs: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7923 [Bug 7923] Performance omnibus -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 5334] New: add explicit foreign key constraints
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5334 Summary: add explicit foreign key constraints Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Database AssignedTo: gmcharlt(a)gmail.com ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 There are many tables that lack explicit foreign key relationships to parent tables. For example: * serial (biblionumber, subscriptionid) * subscription (biblionumber) * subscriptionhistory (biblionumber, subscriptionid) * suggestions (suggestedby, managedby, rejectedby) * branch_transfer_limits (toBranch, fromBranch) and many, many others. Explicit foreign keys should be added for several reasons: * to promote better data integrity and to expose cases where the application code makes unwarranted assumptions about the database structure * to allow cascading updates and deletes in some cases * to make it easier for external reporting tools to correctly identify relationships between tables * to make use of an ORM more effective There are some arguments against this: * a complete set of FKs may decrease database speed (on the other hand, the Koha schema already uses a bunch of FKs) There are some implementation details to consider: * the database creation scripts may need some reordering * in some cases, a database update to add an FK may require dealing with rows that do not meet the new constraint. -- 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 12

[Bug 13518] New: Table borrower_modifications is missing FK and not deleted with the patron
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13518 Bug ID: 13518 Summary: Table borrower_modifications is missing FK and not deleted with the patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The table borrower_modifications has no FK constraint on the borrowernumber and will remain untouched when the patron is deleted. If the borrowernumber doesn't exist in the database, the modification entry is no longer visible in Koha. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 13667] New: Provide script to regularly clean deletedpatrons table
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13667 Bug ID: 13667 Summary: Provide script to regularly clean deletedpatrons table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Currently when a patron record is deleted in Koha the information in the table borrowers is moved to the table deletedborrowers. But Koha currently provides no way to clean up the table deletedborrowers regularly. The data is kept forever or has to be deleted via SQL. We should provide a script that checks for a timestamp (see bug 8926) and deletes data older than x days. It might also be desirable to offer an option to never save data into the deletedborrowers table. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 13515] New: Table messages is missing FK constraints and is never cleaned up
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13515 Bug ID: 13515 Summary: Table messages is missing FK constraints and is never cleaned up Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The table messages is used to store notes to the patron (visible in OPAC) and internal notes for circulation. There is no FK on the borrowernumber, so the data in this table is never cleaned up, not even on deleting the patron. There is also no FK on the branchcode, although the comments state otherwise. 2723 -- Table structure for table `messages` 2724 -- 2725 DROP TABLE IF EXISTS `messages`; 2726 CREATE TABLE `messages` ( -- circulation messages left via the patron's check out screen 2727 `message_id` int(11) NOT NULL auto_increment, -- unique identifier assigned by Koha 2728 `borrowernumber` int(11) NOT NULL, -- foreign key linking this message to the borrowers table 2729 `branchcode` varchar(10) default NULL, -- foreign key linking the message to the branches table 2730 `message_type` varchar(1) NOT NULL, -- whether the message is for the librarians (L) or the patron (B) 2731 `message` text NOT NULL, -- the text of the message 2732 `message_date` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, -- the date and time the message was written 2733 PRIMARY KEY (`message_id`) 2734 ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 13533] New: Table suggestions is missing FK constraints / borrowernumbers are kept on deletion of patron
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13533 Bug ID: 13533 Summary: Table suggestions is missing FK constraints / borrowernumbers are kept on deletion of patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The suggestions table never clears the borrowernumbers referenced in - suggestedby - managedby - acceptedby - rejectedby suggestedby is usually a patron not a staff user, I think on deletion of the patron it would make sense to set it to NULL. Maybe also for the other 3? There is also no FK on - budgetid - branchcode -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 13535] New: Table alert is missing FK and not deleted with the patron
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13535 Bug ID: 13535 Summary: Table alert is missing FK and not deleted with the patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The table alert contains subscriptions for email notifications for new serial issues. There is no FK on the borrowernumber and no other permission I can see to clean the table once the patron has been deleted. 2806 DROP TABLE IF EXISTS `alert`; 2807 CREATE TABLE `alert` ( 2808 `alertid` int(11) NOT NULL auto_increment, 2809 `borrowernumber` int(11) NOT NULL default 0, 2810 `type` varchar(10) NOT NULL default '', 2811 `externalid` varchar(20) NOT NULL default '', 2812 PRIMARY KEY (`alertid`), 2813 KEY `borrowernumber` (`borrowernumber`), 2814 KEY `type` (`type`,`externalid`) 2815 ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 8897] New: Optional GnuPG encryption of outgoing emails
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8897 Priority: P5 - low Change sponsored?: --- Bug ID: 8897 Assignee: mirko(a)abunchofthings.net Summary: Optional GnuPG encryption of outgoing emails Severity: enhancement Classification: Unclassified OS: All Reporter: mirko(a)abunchofthings.net Hardware: All Status: NEW Version: rel_3_12 Component: Notices Product: Koha Koha should have an option to encrypt outgoing emails with GnuPG. -- You are receiving this mail because: You are watching all bug changes.

1 52

[Bug 15535] New: can't call method "default-privacy" on an undefined value /usr/share/koha/lib/c4/members.pm line 753
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15535 Bug ID: 15535 Summary: can't call method "default-privacy" on an undefined value /usr/share/koha/lib/c4/members.pm line 753 Change sponsored?: --- Product: Koha Version: 3.22 Hardware: PC OS: Linux Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: irfan.mirza(a)uettaxila.edu.pk QA Contact: testopia(a)bugs.koha-community.org When I try to create a patron from opac. A message appears (can't call method "default-privacy" on an undefind value /usr/share/koha/lib/c4/members.pm line 753) on submitting the form after filling it. -- You are receiving this mail because: You are watching all bug changes.

1 4