September 2012 - Koha-bugs - lists.koha-community.org

[Bug 8618] New: Z3950 is not processing CCL Queries
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '15

23 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8618 Priority: P5 - low Change sponsored?: --- Bug ID: 8618 CC: m.de.rooy(a)rijksmuseum.nl Assignee: gmcharlt(a)gmail.com Summary: Z3950 is not processing CCL Queries Severity: major Classification: Unclassified OS: All Reporter: dcook(a)prosentient.com.au Hardware: All Status: NEW Version: master Component: Z39.50 / SRU / OpenSearch Servers Product: Koha When you click "Z3950 search" in the intranet search results, the title field in the Z3950 search formis preloaded with the CCL for the query that you executed in Koha. However, when you try searching, you will always get no results back. If you take out the CCL, and just type in your query (like "heart") into the title field, you will get results. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 6138] New: Show local help and isbd punctuation automatically when we are cataloguing
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '15

23 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6138 Bug #: 6138 Summary: Show local help and isbd punctuation automatically when we are cataloguing Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: juan.sieira(a)xercode.es QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Created attachment 3828 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3828 proposed patch Show local help and isbd punctuation automatically when we are cataloguing. In administration->MARC Bibliographic framework->Marc Structure->Subfields->Edit subfields there are two new fields, punctuacion and help. We have to fill those fields with some help and the isbd punctuation to a determinate subfield. Those values will appear when we are cataloguing. Our libraries requested this change because they need help in the cataloguing process to follow its their procedures manual. If you dont want to execute updatedatabase.pl, simply execute this statement in you database ALTER TABLE `marc_subfield_structure` ADD `punctuation` VARCHAR( 5 ) NULL , ADD `help` VARCHAR( 255 ) NULL; -- 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 8096] New: card number twice on patron search
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '15

19 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8096 Priority: P5 - low Change sponsored?: --- Bug ID: 8096 Assignee: oleonard(a)myacpl.org Summary: card number twice on patron search Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Templates Product: Koha Created attachment 9597 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9597&action=edit card number twice Why is the card number showing twice on the patron search results? We really only need it once - either in it's own column or in parens. Twice is confusing. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 5632] New: SIP improvements = Date formatting & debarrement management
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '15

18 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5632 Summary: SIP improvements = Date formatting & debarrement management Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: PATCH-Sent Component: SIP2 AssignedTo: paul.poulain(a)biblibre.com ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 * the dates should be printed in human-readable format, not in timestamp * The patron debarment can now have a date (new feature of BibLibre circ improvements). We have to deal with this date on the SIP messages -- 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 11

[Bug 8446] New: Shibboleth authentication patch
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '15

16 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8446 Priority: P5 - low Change sponsored?: --- Bug ID: 8446 CC: dpavlin(a)rot13.org Assignee: gmcharlt(a)gmail.com Summary: Shibboleth authentication patch Severity: enhancement Classification: Unclassified OS: All Reporter: francart(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Authentication Product: Koha Created attachment 10841 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10841&action=edit Shibboleth patch for Auth.pm on Koha 3.8 I wrote rudimentary Shibboleth login support for Koha. It's quite specific to our university and Koha setup, but should be easy to modify. I hope someone finds it useful. The attached patch can be applied to lib/C4/Auth.pm of Koha 3.8.2 -- You are receiving this mail because: You are watching all bug changes.

1 179

[Bug 8337] New: System preferences for longoverdue cron
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '15

15 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8337 Priority: P5 - low Change sponsored?: --- Bug ID: 8337 Assignee: gmcharlt(a)gmail.com Summary: System preferences for longoverdue cron Severity: enhancement Classification: Unclassified OS: All Reporter: pelletiermaxime(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Command-line Utilities Product: Koha Patch to follow that adds 3 new system preferences to control the parameters for the longoverdue script. New prefs are DefaultLongOverdueChargeValue, DefaultLongOverdueLostValue and DefaultLongOverdueDays. These preferences are used when you call the longoverdue.pl script without their parameters. -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 7556] New: Use "preventDoubleFormSubmit()" more in the OPAC and Intranet to prevent duplicate data
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7556 Bug #: 7556 Summary: Use "preventDoubleFormSubmit()" more in the OPAC and Intranet to prevent duplicate data Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: wizzyrea(a)gmail.com QAContact: koha.sekjal(a)gmail.com Depends on: 6496 When 6496 is pushed, we will have a new jquery function: preventDoubleFormSubmit(). When used thusly: $('#form-id').preventDoubleFormSubmit(); It will prevent a submitted form from being submitted a second (or third, or fourth, or fifth) time. We should probably use this on most submission forms in the OPAC. As Paul states on 6496 - "we can teach librarians not to double click, but not patrons." The function exists in both the OPAC and Intranet, and so it can be used anywhere a double (or rapid) click would resubmit a form. I think we should try to use it more. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 6832] New: Validation of total > budget in neworderempty
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '15

13 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6832 Bug #: 6832 Summary: Validation of total > budget in neworderempty Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: pelletiermaxime(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 5264 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5264 [PATCH] Fix multiple bugs and refactor the code to fix the alert of the total exceeding the budget in neworderempty The javascript function totalExceedsBudget never returns anything. Refactored it to use jQuery for the ajax stuff and to make it work. Only 1 line changed in a tmpl, so should be easy to adapt for 3.4. Steps to reproduce : Create a new order in a basket. Set a total higher than the total of the selected budget. You will see an ajax request, but no error. This patch fixes the return, make it work for ie6 by using jQuery and prints correctly the total of the budget in the error. -- 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 23

[Bug 5592] New: circ rule cloning can be dangerous
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '15

08 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5592 Summary: circ rule cloning can be dangerous Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 The clone circ rules widget on the circ rules page unconditionally deletes the target library's existing rules and replaces them with copies of the rules from the source library. Consequently, if the clone rule button is accidentally clicked, a lot of configuration work can be destroyed in an instant. To avoid this: * there should *always* be a required confirmation step, whether the clone-rules.pl script is accessed directly or via the smart-rules.pl page * even better, a backup copy of the previous version of the target library's rules could be made The library who ran into this bug had tried cloning the rules form a different library because they thought that would be a way to copy over that library's rules and add them to the rules that the target library had previously entered -- that kind of cloning-via-merge feature also seems like a good idea, in fact. -- 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 4

[Bug 7817] New: Items Permanent location (shelving location) is set to NULL when item is edited
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '15

08 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Priority: P5 - low Change sponsored?: --- Bug ID: 7817 Assignee: gmcharlt(a)gmail.com Summary: Items Permanent location (shelving location) is set to NULL when item is edited QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: joy(a)bywatersolutions.com Hardware: All Status: NEW Version: rel_3_6 Component: Cataloging Product: Koha When an item is edited, the field items.permanent_location is set to NULL. This causes significant problems when a library is utilizing the CART and PROC system preferences to assign CART and PROC shelving locations. If items.permanent_location is NULL then there is no way to restore the original shelving location for these items. This results in significant data loss for libraries. -- You are receiving this mail because: You are watching all bug changes.

1 53