March 2014 - Koha-bugs - lists.koha-community.org

[Bug 9190] New: Problem with holds - allow place a hold without all items checked out
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '16

15 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9190 Bug ID: 9190 Summary: Problem with holds - allow place a hold without all items checked out Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: vfernandes(a)keep.pt CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The objective is only to allow a patron to place a hold only when all items are checked out. The hold will be placed in the next item available. If there isn't any checked out items I can't place a hold, which is fine If all items are checked out I can place a hold, which is fine If 1 items of X items are checked out I can place a hold, which isn't what I pretend System preferences: - OPACItemHolds = don't allow - AllowOnShelfHolds = don't allow -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 8964] New: AllowHoldsOnDamagedItems and AllowOnShelfHolds don't work with Professional category type
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '16

15 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8964 Priority: P5 - low Change sponsored?: --- Bug ID: 8964 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: AllowHoldsOnDamagedItems and AllowOnShelfHolds don't work with Professional category type Severity: minor Classification: Unclassified OS: All Reporter: laurence.lefaucheur(a)biblibre.com Hardware: All Status: NEW Version: rel_3_8 Component: Hold requests Product: Koha For patron categories of Professional category type : if issuingrules allow reservation whatever the values of AllowHoldsOnDamagedItems and AllowOnShelfHolds are, damaged items or on shelf items are not available for hold for the patron : one cannot select them in staff to put an hold on them For all other category types, the problem does not exist -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 11602] New: Fix localcover display
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '16

15 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11602 Bug ID: 11602 Summary: Fix localcover display Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: vanoudt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I'm busy playing around with updating to the nice new bootstrap theme. We use google jackets most of the time, but have some localcovers stored too. I want to style the localcover imgs the same as any other bookmark. Ideally, they need a thumbnail class. But the 1px image that is returned causes (potentially, at least in my case) things like empty borders. Could the Locacovers.js function be modified to a) include a class of thumbnail for the image b) not insert the image when it is 1px in size. The following function would do that... /** * Search all: * <div title="biblionumber" id="isbn" class="openlibrary-thumbnail"></div> * or * <div title="biblionumber" id="isbn" class="openlibrary-thumbnail-preview"></div> * and run a search with all collected isbns to Open Library Book Search. * The result is asynchronously returned by OpenLibrary and catched by * olCallBack(). */ GetCoverFromBibnumber: function(uselink) { $("div[id^=local-thumbnail],span[id^=local-thumbnail]").each(function(i) { var mydiv = this; var message = document.createElement("span"); $(message).attr("class","no-image"); $(message).html(NO_LOCAL_JACKET); $(mydiv).append(message); var img = $("<img />").attr('src', '/cgi-bin/koha/opac-image.pl?thumbnail=1&biblionumber=' + $(mydiv).attr("class")) .load(function () { this.setAttribute("class", "thumbnail"); if (!this.complete || typeof this.naturalWidth == "undefined" || this.naturalWidth == 0) { //IE HACK try { $(mydiv).append(img); $(mydiv).children('.no-image').remove(); } catch(err){ }; } else if (this.width > 1) { // don't show the silly 1px "no image" img if (uselink) { var a = $("<a />").attr('href', '/cgi-bin/koha/opac-imageviewer.pl?biblionumber=' + $(mydiv).attr("class")); $(a).append(img); $(mydiv).empty().append(a); } else { $(mydiv).empty().append(img); } $(mydiv).children('.no-image').remove(); } }) }); } -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 6624] New: Allow Koha to use the new read API from OpenLibrary
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6624 Bug #: 6624 Summary: Allow Koha to use the new read API from OpenLibrary Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org http://openlibrary.org/dev/docs/api/read -- 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 14

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