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

[Bug 4402] Date filter in parcels.tt requires db format dates
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '15

12 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4402 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #10 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm, the new patch does cause some weird side effects. When I access the bookseller parcels page via 'receive shipment' the old shipments/open invoices don't show up. I think it's the same problem I've run into trying to avoid using C4::Dates, Koha::DateUtils date_to_string returns not only the date and it will also return "now" if no date is given: 2015-01-12T07:13:11 And that won't work in the SQL. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 13541] New: Cannot log in
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '15

11 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13541 Bug ID: 13541 Summary: Cannot log in Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: andersonhemmat(a)comcast.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hello, since the first of the year we have not been able to login to our account. It is an old version of Koha. It says "invalid login" but I am certain we are entering our existing login. Please help. I cannot find any other way to contact Koha. Thank you. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 13550] New: Automatic processing status
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '15

09 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13550 Bug ID: 13550 Summary: Automatic processing status Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be great if Koha had the ability to flag items based on criteria for automatic processing. For example, lets say you have a collection that rotates libraries. It would be great to have some way to flag that collection, and when criteria is met, and the item is checked in, it is put into a predetermined processing status and handed off rather than going back out on the shelves. Perhaps new items have a short loan period, and after a certain length of time in the collection, it needs to be changed. It could be flagged to either automatically change to a new loan period, or if it needs to be handled for processing (labels and such), it could be flagged for processing. Perhaps you have items that need to be reset, or batteries to be replaced, either every time it comes in or on a set interval. It could be flagged for processing. It would also be beneficial to have reports on flagged items past due, for items that have not necessarily circed. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 12362] New: Branch transfer records orphaned on cancelled holds
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '15

09 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12362 Bug ID: 12362 Summary: Branch transfer records orphaned on cancelled holds Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When a hold is cancelled for an item that has a branch transfer, the branch transfer is not deleted. This causes items to display as 'in transit', even though there is no open hold. This is very confusing to the library and to patrons, and there is often no obvious way to resolve this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 13546] New: Branch transfer records orphaned when an item is withdrawn
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '15

09 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13546 Bug ID: 13546 Summary: Branch transfer records orphaned when an item is withdrawn 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: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It is possible to withdraw an item that has an outstanding branch transfer, leaving an uncompleted branch transfer record. To reproduce: 1) Check in an item whose home branch is not the current branch 2) Confirm the transfer 3) Set the item to 'withdrawn' 4) Check the branch transfers table -- the branch transfer will still exist, even though the item is withdrawn (i.e. not in circulation). See Also: 12362 Branch transfer records orphaned on cancelled holds -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11463] New: GetItem must use item-level_itypes syspref
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '15

09 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11463 Bug ID: 11463 Summary: GetItem must use item-level_itypes syspref 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: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In GetItem, the key itype comes from items.itype and if not defined from biblioitems.itemtype. This code should be based on item-level_itypes syspref. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[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

[Bug 10631] New: Table alert should have a FK on borrowernumber and entries be deleted with the referenced borrower
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '15

08 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10631 Bug ID: 10631 Summary: Table alert should have a FK on borrowernumber and entries be deleted with the referenced borrower 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 alert is currently used to store information about email subscriptons for new serial issues. The current table defnition is: 2682 DROP TABLE IF EXISTS `alert`; 2683 CREATE TABLE `alert` ( 2684 `alertid` int(11) NOT NULL auto_increment, 2685 `borrowernumber` int(11) NOT NULL default 0, 2686 `type` varchar(10) NOT NULL default '', 2687 `externalid` varchar(20) NOT NULL default '', 2688 PRIMARY KEY (`alertid`), 2689 KEY `borrowernumber` (`borrowernumber`), 2690 KEY `type` (`type`,`externalid`) 2691 ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 2692 As I see it borrowernumber should be a FK and we are missing some cascades to make sure the table is cleaned up when a borrower is deleted. -- You are receiving this mail because: You are watching all bug changes.

1 2