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

[Bug 9717] New: localuse recorded for holds/transfers
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '15

17 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9717 Bug ID: 9717 Summary: localuse recorded for holds/transfers Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.8 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If RecordLocalUseOnReturn is set to "Record" then whenever a hold item is returned from another library, it is being recorded as local use. The library scans the item at check in to cancel the "in transit" status and the item is counted as local use. This seems inaccurate to me. This is going to inflate the local use counts so that libraries think that that many more items are being used in-house when in reality the item is being returned from use at another library in the group. I think that RecordLocalUseOnReturn should only record local use when there is no other status, like holds, transfers, etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[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 9822] New: No alert appears on adding an order to a basket if the budget has exceeded
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '15

13 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9822 Bug ID: 9822 Summary: No alert appears on adding an order to a basket if the budget has exceeded 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: jonathan.druart(a)biblibre.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 9810] New: Search limit 'available' does not hide damaged or withdrawn items
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '15

12 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9810 Bug ID: 9810 Summary: Search limit 'available' does not hide damaged or withdrawn items Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 36

[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

[Bug 10633] New: Table suggestions needs some work
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '15

08 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10633 Bug ID: 10633 Summary: Table suggestions needs some work Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The table suggestions is missing FK constraints and cascades to ensure a suggestion is anonymized when the borrower who suggested it gets deleted. The current table definition is: 2077 DROP TABLE IF EXISTS `suggestions`; 2078 CREATE TABLE `suggestions` ( -- purchase suggestions 2079 `suggestionid` int(8) NOT NULL auto_increment, -- unique identifier assigned automatically by Koha 2080 `suggestedby` int(11) NOT NULL default 0, -- borrowernumber for the person making the suggestion, foreign key linking to the borrowers table 2081 `suggesteddate` date NOT NULL default 0, -- date the suggestion was submitted 2082 `managedby` int(11) default NULL, -- borrowernumber for the librarian managing the suggestion, foreign key linking to the borrowers table 2083 `manageddate` date default NULL, -- date the suggestion was updated 2084 acceptedby INT(11) default NULL, -- borrowernumber for the librarian who accepted the suggestion, foreign key linking to the borrowers table 2085 accepteddate date default NULL, -- date the suggestion was marked as accepted 2086 rejectedby INT(11) default NULL, -- borrowernumber for the librarian who rejected the suggestion, foreign key linking to the borrowers table 2087 rejecteddate date default NULL, -- date the suggestion was marked as rejected 2088 `STATUS` varchar(10) NOT NULL default '', -- suggestion status (ASKED, CHECKED, ACCEPTED, or REJECTED) 2089 `note` mediumtext, -- note entered on the suggestion 2090 `author` varchar(80) default NULL, -- author of the suggested item 2091 `title` varchar(255) default NULL, -- title of the suggested item 2092 `copyrightdate` smallint(6) default NULL, -- copyright date of the suggested item 2093 `publishercode` varchar(255) default NULL, -- publisher of the suggested item 2094 `date` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, -- date and time the suggestion was updated 2095 `volumedesc` varchar(255) default NULL, 2096 `publicationyear` smallint(6) default 0, 2097 `place` varchar(255) default NULL, -- publication place of the suggested item 2098 `isbn` varchar(30) default NULL, -- isbn of the suggested item 2099 `mailoverseeing` smallint(1) default 0, 2100 `biblionumber` int(11) default NULL, -- foreign key linking the suggestion to the biblio table after the suggestion has been ordered 2101 `reason` text, -- reason for accepting or rejecting the suggestion 2102 `patronreason` text, -- reason for making the suggestion 2103 budgetid INT(11), -- foreign key linking the suggested budget to the aqbudgets table 2104 branchcode VARCHAR(10) default NULL, -- foreign key linking the suggested branch to the branches table 2105 collectiontitle text default NULL, -- collection name for the suggested item 2106 itemtype VARCHAR(30) default NULL, -- suggested item type 2107 quantity SMALLINT(6) default NULL, -- suggested quantity to be purchased 2108 currency VARCHAR(3) default NULL, -- suggested currency for the suggested price 2109 price DECIMAL(28,6) default NULL, -- suggested price 2110 total DECIMAL(28,6) default NULL, -- suggested total cost (price*quantity updated for currency) 2111 PRIMARY KEY (`suggestionid`), 2112 KEY `suggestedby` (`suggestedby`), 2113 KEY `managedby` (`managedby`) 2114 ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- You are receiving this mail because: You are watching all bug changes.

1 2