October 2013 - Koha-bugs - lists.koha-community.org

[Bug 10412] New: The ability to update Acquisitions with credit notes, with the option to link to an existing invoice
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10412 Bug ID: 10412 Summary: The ability to update Acquisitions with credit notes, with the option to link to an existing invoice Classification: Unclassified 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: amitddng135(a)gmail.com The ability to update Acquisitions with credit notes, with the option to link to an existing invoice -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[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 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 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 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 9805] New: Lost items are un-lost if returned, but not if renewed.
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 Bug ID: 9805 Summary: Lost items are un-lost if returned, but not if renewed. Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If an item has a lost status, that status is removed when the item is returned. However, it is not removed if the item is renewed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 5501] New: why is there a 'do not notify' option?
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5501 Summary: why is there a 'do not notify' option? Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 When looking at the enhanced messages for patrons there is a 'do not notify' option - which is basically the same as not checking any messaging choices - so why do we need that option at all? I recommend removing it since it's confusing. -- 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 16

[Bug 7710] New: multiple holds per title
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7710 Priority: P5 - low Change sponsored?: --- Bug ID: 7710 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: multiple holds per title QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha Users shall be able to place holds on multiple items attached to a single biblio, subject to two circulation policies (configurable on the branch/item type/patron category level). One policy shall indicate the number of holds that can be placed on items with different enumchron values (different volumes), while another shall indicate the number of holds that can be placed on items with the same enumchron field (different copies). This will allow libraries to allow patrons to place holds on multiple volumes of a title, up to a reasonable limit, while limiting or preventing multiple holds on 'equivalent' copies. -- You are receiving this mail because: You are watching all bug changes.

1 135

[Bug 8809] New: Cascading Holds
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8809 Priority: P5 - low Change sponsored?: --- Bug ID: 8809 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Cascading Holds Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Hold requests Depends on: 7710 Product: Koha It would be nice once we have the ability to place holds on multiple items attached to one title if the patron could define which item them want first. So if they place holds all of the items attached to a TV series on DVD for example. They want to be able to say I want Disc 1 before Disc 2 and so on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1