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

[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 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

[Bug 10747] New: PDF template for order printing should be selectable per order
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10747 Bug ID: 10747 Summary: PDF template for order printing should be selectable per order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Currently you have to decide globally in a system preference, which template you want to use for PDF printing of basket groups. It would be nice to have this option available on order level with a global default. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 11944] New: Cleanup Koha UTF-8
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11944 Bug ID: 11944 Summary: Cleanup Koha UTF-8 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org This bug report will try to fix all UTF-8 problems once and forever! see http://wiki.koha-community.org/wiki/Handling_UTF8_in_development for more details about development guidelines for handling UTF-8 in Koha. -- You are receiving this mail because: You are watching all bug changes.

1 361

[Bug 10860] New: In-House Use
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10860 Bug ID: 10860 Summary: In-House Use Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This feature implements the In-House Use feature for Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 123

[Bug 11577] New: [ENH] Automatic renewal feature
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11577 Bug ID: 11577 Summary: [ENH] Automatic renewal feature Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Circulation Assignee: h.meissner.82(a)web.de Reporter: h.meissner.82(a)web.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Our library wants a new “automatic renewal” feature, that enables some patrons to borrow items for a long time, without having to renew manually. So for certain combinations of patron category and item type, renewals will be done by a cronjob. Automatic renewal stops when a hold is placed or when the given number of allowed renewals is exceeded. RFC: http://wiki.koha-community.org/wiki/Automatic_renewal_RFC -- You are receiving this mail because: You are watching all bug changes.

1 166

[Bug 11625] New: Default to logged in library for circ rules and notices & slips
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11625 Bug ID: 11625 Summary: Default to logged in library for circ rules and notices & slips Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It has come to our attention that some librarians will accidentally change default circulation rules and notices be accident, assuming they are working on rules and notices for their library by default. If a librarian is logged in with a set branchcode, we should display that branches rules by default, and require them to choose the "All libraries" sections by hand. -- You are receiving this mail because: You are watching all bug changes.

1 75

[Bug 13542] New: Subscripton is only table to store userid instead of borrowernumber
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13542 Bug ID: 13542 Summary: Subscripton is only table to store userid instead of borrowernumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor 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 a new subscription is created in the serials module, the userid of the staff member is saved to subscripiton.librarian. This makes subscription the only table to store information about the patron not using the borrowernumber, but the userid instead. If you delete the staff member, his/her userid will stay in the subscription forever. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 13642] New: Adding new features for Dublin Core metadata
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13642 Bug ID: 13642 Summary: Adding new features for Dublin Core metadata Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hector.hecaxmmx(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Adding new features for Dublin Core metadata This is an enhancement for Dublin Core metadata. When Koha export a bibliographic record to DC, makes it in XML format. This XML is not well-formed document and do not follows the DC-XML recommendations as should be. This enhancement gives to Koha the ability to download a file in XML or RDF format. A new module (/C4/DublinCoreTransformer.pm) is required for this purpose. This module transform a marc record to Dublin Core following the DC Specifications: DC-XML, Simple DC-RDF, DC-RDF and as agregated OAI-DC. RDF can be exported as multiple formats like: rdfxml, rdfjson, ntriples, turtle, etc. This patch include modification to these files: MODULES: /C4/Record.pm OPAC: /koha-tmpl/opac-tmpl/bootstrap/js/script.js /koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-datail-sidebar.inc /koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc /opac/opac-export.pl CATALOGUE /koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/datail.tt /koha-tmpl/intranet-tmpl/prog/en/includes/cat-toolbar.inc /catalogue/export.pl NOTE: MARC::Crosswalk::DublinCore not support RDA yet. Not uses XSL to convert the data. -- You are receiving this mail because: You are watching all bug changes.

1 211