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

[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 11299] New: Add a button that automatically links authority records to a biblio record during edition. (AJAX)
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11299 Bug ID: 11299 Summary: Add a button that automatically links authority records to a biblio record during edition. (AJAX) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: fcapovilla(a)live.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 23146 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=23146&action=edit Add a button to the biblio edition page to automatically add authority links. This patch adds a "Link authorities automatically" button to the addbiblio page. When it's clicked, authority links are automatically added to the current biblio record without a need to save the record. A message is then shown, giving a summary of the linking process and telling the user which fields were updated and which ones were not. If some fields could not be linked, a "create authority" icon is added next to their $9 subfield. If this icon is clicked, a popup appears to let the user create a new authority record for the field. The patch also adds an optional "status" return value to Linker.pm, which can be used by the Linker to return custom status strings to give more informations about the linking process to the user. Sponsored-by: CCSR ( http://www.ccsr.qc.ca ) -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 11879] New: Add a new borrower field : main contact method.
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11879 Bug ID: 11879 Summary: Add a new borrower field : main contact method. 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: fcapovilla(a)live.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 25745 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25745&action=edit Add the "Main contact method" field in borrower informations. This patch adds the "Main Contact Method" field in the borrower modification form. This field is useful for reporting purposes, or to know which contact method to use first when trying to contact a borrower. Test case : * Edit a borrower's informations. The "Main Contact Method" selectbox should appear in the form and its value should be saved correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49

[Bug 14631] New: Change to "Patron" in patroncard toolbar
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14631 Bug ID: 14631 Summary: Change to "Patron" in patroncard toolbar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: indradg(a)gmail.com Reporter: indradg(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The toolbar for "Manage patron card batches" template shows "item(s)" instead of "patron(s)". This patch proposes to fix it. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 13668] New: Creator of an SQL report shoudl be NULL when the staff patron is deleted
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13668 Bug ID: 13668 Summary: Creator of an SQL report shoudl be NULL when the staff patron is deleted 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 When deletig a staff patron his/her reports are still linked to his/her former borrowernumber. It would be better to delete the connection to the creator when the staff patron is deleted. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 6657] New: Making 999 visible in framework duplicates 999 entry and affects index
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6657 Bug #: 6657 Summary: Making 999 visible in framework duplicates 999 entry and affects index Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com The 999 field is usually hidden in the frameworks; the 999$c is where Koha stores the biblionumber for the title. If someone edits the framework to make any field of the 999 visible, then any edit to any field of the MARC record results in a duplicate 999 with the biblionumber repeated. This can cause the record to appear twice in the zebra index, and can also make OPAC suppression not work. I have verified this behavior in current development head and several other versions. To replicate, export a title record and check its 999 field. There should only be one. For example: =999 \\$c219$d219 or <datafield tag="999" ind1=" " ind2=" "> <subfield code="c">219</subfield> <subfield code="d">219</subfield> </datafield> Then edit the framework to make any field of the 999 visible, and edit that same record. Make any change to the title, such as adding a 5xx note. Export the record again and check the 999. There will now be two of them, repeating the biblionumber: =999 \\$c219$d219 =999 \\$c219 or <datafield tag="999" ind1=" " ind2=" "> <subfield code="c">219</subfield> <subfield code="d">219</subfield> </datafield> <datafield tag="999" ind1=" " ind2=" "> <subfield code="c">219</subfield> </datafield> Changing the framework field back to hidden and forcing the MARC record back through zebraqueue does not fix the problem. The only fix we've found is to manually remove the extra 999 at the table level, then rebuild indexes. The first solution for the problem is to not set the 999 field as visible in any framework, but since you can't stop people from being adventurous, we also developed a code safeguard. It has not yet been backported from our current development head to the version in our public git repository; when it is, I'll add a link. In the meantime, here are the details of that commit. If the framework allows the biblionumber (999$c) field to be displayed and edited within the MARC editor, then this results in an additional 999$c value being added to the MARC record. This is because the code already pulled the biblionumber from the biblio table. This patch removes the addition of the extra 999$c field, although this field shouldn't really be editable in the first place. diff --git a/C4/Biblio.pm b/C4/Biblio.pm index 2e28f3f..3f61519 100644 --- a/C4/Biblio.pm +++ b/C4/Biblio.pm @@ -1858,13 +1858,13 @@ sub TransformHtmlToMarc { my $record = MARC::Record->new(); my $i=0; my @fields; + my ( $biblionumbertagfield, $biblionumbertagsubfield ) = + &GetMarcFromKohaField( "biblio.biblionumber", '' ); while ($params->[$i]){ # browse all CGI params my $param = $params->[$i]; my $newfield=0; # if we are on biblionumber, store it in the MARC::Record (it may not be in the edited fields) if ($param eq 'biblionumber') { - my ( $biblionumbertagfield, $biblionumbertagsubfield ) = - &GetMarcFromKohaField( "biblio.biblionumber", '' ); if ($biblionumbertagfield < 10) { $newfield = MARC::Field->new( $biblionumbertagfield, @@ -1903,6 +1903,12 @@ sub TransformHtmlToMarc { } else { while(defined $params->[$j] && $params->[$j] =~ /_code_/){ # browse all it's subfield my $inner_param = $params->[$j]; + my $biblionumbertagsubfield_string = "_code_" . $biblionumbertagsubfield . "_"; + if (($tag eq $biblionumbertagfield) && + ($inner_param =~ /$biblionumbertagsubfield_string/)) { + $j += 2; + next; + } if ($newfield){ -- 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 58