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

[Bug 11354] New: NewItemsDefaultLocation Override in Cataloging
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '14

25 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11354 Bug ID: 11354 Summary: NewItemsDefaultLocation Override in Cataloging Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: library(a)stas.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The value of NewItemsDefaultLocation indiscriminately sets the location of a new item to this value. That is, when adding a new item, no matter what the cataloger sets for 952$c, the record defaults to the preference value, even if 952$c is not null. The matter is trivial, because one can easily just edit the item after the addition, and the edit sticks. It would be nice, however, for the NewItemsDefaultLocation value to only be applied to a new record when 952$c is null. If non-null, the default should not be applied. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 12515] New: Partial receive status not correctly populated on updating from older Koha version
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '14

25 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12515 Bug ID: 12515 Summary: Partial receive status not correctly populated on updating from older Koha version Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 Filing this quickly, before I forget, some more testing needed: I just updated an old database dump to recent Koha in order to do some acquisition testing. The dump was from a version before the aqorders.orderstatus column existed. The database update created the column and set the status for all orders. This seems to work nicely, with the exception of partial orders. After updating, the partially unreceived orders have the status "ordered" instead of "partial". The parent_ordernumber is correctly set to the parent order with the received items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 11111] New: The basket group is not display on the parcel page
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '14

25 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11111 Bug ID: 11111 Summary: The basket group is not display on the parcel page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bug 10724 adds the search by basket group on the parcel page but does not display it the the table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 12505] New: Variable aqorders.listprice from 'Tools' - 'Notices and Slips' Does not work
by bugzilla-daemon＠bugs.koha-community.org 24 Nov '14

24 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12505 Bug ID: 12505 Summary: Variable aqorders.listprice from 'Tools' - 'Notices and Slips' Does not work Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: simith.doliveira(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The variable aqorders.listprice shows aqbooksellers.listprice value instead. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 5304] New: Too many post find queries for items
by bugzilla-daemon＠bugs.koha-community.org 24 Nov '14

24 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5304 Summary: Too many post find queries for items Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: srdjan(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 C4::Items::GetItemsInfo(): When the items resultset is returned from the search, lots of additional queries are requested for each item in order ti get extra data. This makes large resultsets extremely slow to return. Proposed solution: Rewrite items query so it returns all relevant data at once -- 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 31

[Bug 10345] New: Copy number should be incremented when adding multiple items at once
by bugzilla-daemon＠bugs.koha-community.org 24 Nov '14

24 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10345 Bug ID: 10345 Summary: Copy number should be incremented when adding multiple items at once Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de CC: m.de.rooy(a)rijksmuseum.nl When adding multiple items in cataloguing, the copy number is not incremented for the generated additional items. To test: - Add new items to any of your records - Make sure you enter a copy number - Choose "Add multiple copies" - Enter number of items to be generaded - Click Add - Verify copynumber is empty for all generated items except the first -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 8735] New: Expire holds waiting only on days the library is open
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '14

22 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8735 Priority: P5 - low Change sponsored?: --- Bug ID: 8735 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Expire holds waiting only on days the library is open Severity: enhancement Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha There is a problem with expiring reserves. Let us say an items has two holds placed on it, and is set to waiting for the first hold. This hold is then canceled for waiting too long, yet it will remain sitting on the holds shelf until a librarian either returns it to the shelf, or sets it too waiting for the next person in line to get it. During the interim, the item will appear to be available for checkout. This is not a problem most of the time, as the holds expire late at night and the librarians will take care of it in the morning, but over a holiday weekend, it is possible that an item will remain in this state for days at a time. We can fix this situation by adding a system preference to decide of waiting holds should be canceled on holidays, or not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 71

[Bug 11852] New: Scripted processes
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '14

22 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11852 Bug ID: 11852 Summary: Scripted processes 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 Here is a lofty wish... I wish Koha could have the ability to have scripted processes. For example. We don't have holds waiting automatically expire (meaning it wasn't picked up, not to be confused with a patron set expiration on the request), simply for the sake that we don't want available items on the hold shelf unless it has been processed. For us, this means, after 7 days waiting without being picked up, we pull the item, we go into the patron account the item was waiting for and put a message on the account that the item was not picked up. We then cancel the hold and check the item in to trigger the next hold or transfer back to the home library. It would be a dream to be able to create link to a script that would do all of this. For example, we would have a link in the Circulation menu to a script called "Process expired holds". We then scan the item, and the script puts the "Not picked up" message in the patron account, cancels the existing hold for that patron, and checks the item in to trigger the next hold or transfer on that item. I could see this working if there were a way to pass on these tasks to Koha like events. Maybe through URLs. I don't know. But, it would be wonderful in streamlining processes. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 9177] New: Duplicate patron: Prepopulated fields ar cleared when setting cursor
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '14

22 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9177 Bug ID: 9177 Summary: Duplicate patron: Prepopulated fields ar cleared when setting cursor Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 13790 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=13790&action=edit Screenshot Duplicate patron - prepopulated fields cleared How to reproduce: 1) Go to a patron's detail page 2) Click "Duplicate" 3) On the screen, click in one of the prepopulated fields, e.g. Surname or City Result: The field is cleared. Expected: Cursor is set without clearing the field. Is this a bug or is it by design? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 12250] New: Add Kurdish language
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '14

22 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12250 Bug ID: 12250 Summary: Add Kurdish language Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Add Kurdish language -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17