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

[Bug 9805] New: Lost items are un-lost if returned, but not if renewed.
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 Bug ID: 9805 Summary: Lost items are un-lost if returned, but not if renewed. Classification: Unclassified 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: kyle(a)bywatersolutions.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If an item has a lost status, that status is removed when the item is returned. However, it is not removed if the item is renewed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 5501] New: why is there a 'do not notify' option?
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5501 Summary: why is there a 'do not notify' option? Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 When looking at the enhanced messages for patrons there is a 'do not notify' option - which is basically the same as not checking any messaging choices - so why do we need that option at all? I recommend removing it since it's confusing. -- 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 16

[Bug 7710] New: multiple holds per title
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7710 Priority: P5 - low Change sponsored?: --- Bug ID: 7710 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: multiple holds per title QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha Users shall be able to place holds on multiple items attached to a single biblio, subject to two circulation policies (configurable on the branch/item type/patron category level). One policy shall indicate the number of holds that can be placed on items with different enumchron values (different volumes), while another shall indicate the number of holds that can be placed on items with the same enumchron field (different copies). This will allow libraries to allow patrons to place holds on multiple volumes of a title, up to a reasonable limit, while limiting or preventing multiple holds on 'equivalent' copies. -- You are receiving this mail because: You are watching all bug changes.

1 135

[Bug 14137] New: Allow ExpireReservesMaxPickUpDelayCharge to be used without ExpireReservesMaxPickUpDelay
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14137 Bug ID: 14137 Summary: Allow ExpireReservesMaxPickUpDelayCharge to be used without ExpireReservesMaxPickUpDelay Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some libraries would like to be able to use ExpireReservesMaxPickUpDelayCharge without ExpireReservesMaxPickUpDelay. ExpireReservesMaxPickUpDelay automatically cancels the holds but some librarians would prefer to cancel the holds manually but still have the patron's charged the fee for allowing a waiting hold to become expired and canceled. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 14405] New: Add datatable to fines table in OPAC patron account
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14405 Bug ID: 14405 Summary: Add datatable to fines table in OPAC patron account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org It would be nice if we could sort and search the fines table on the fines tab in the patron's OPAC account. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 11622] New: Add ability to pay fees and fines from OPAC via PayPal
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11622 Bug ID: 11622 Summary: Add ability to pay fees and fines from OPAC via PayPal Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Many libraries wish to add the ability to pay fees and fines from the OPAC using PayPal. -- You are receiving this mail because: You are watching all bug changes.

1 96

[Bug 8809] New: Cascading Holds
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8809 Priority: P5 - low Change sponsored?: --- Bug ID: 8809 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Cascading Holds Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Hold requests Depends on: 7710 Product: Koha It would be nice once we have the ability to place holds on multiple items attached to one title if the patron could define which item them want first. So if they place holds all of the items attached to a TV series on DVD for example. They want to be able to say I want Disc 1 before Disc 2 and so on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 7065] New: reserves table needs a primary key
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7065 Bug #: 7065 Summary: reserves table needs a primary key Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org Blocks: 5609 The reserves (and old_reserves) tables desperately need a primary key. reservernumber should be used for consistency sake. This will allow the possibility of multiple holds per biblio/patron combination, and a host of other improvements. This is included in bug 5872, but needs to be broken out into it's own enhancement for independent review. One cavaet: the values must be unique across the union of reserves and old_reserves. While this is easy enough to achieve in a new installation, adding the values into an existing install gets trickier. -- 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 50

[Bug 12152] New: Holds to pull report should show library and itype description instead of their codes
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12152 Bug ID: 12152 Summary: Holds to pull report should show library and itype description instead of their codes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The holds to pull report shows the library code and itype codes instead of the descriptions. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 14390] New: On renewal, the last fine is not marked as accounttype 'F' when item is checked in.
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14390 Bug ID: 14390 Summary: On renewal, the last fine is not marked as accounttype 'F' when item is checked in. Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: normal 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 When an item with a fine is renewed, the old fine is closed (i.e. accounttype is set to 'F'). A new fine is created, with an updated description. The new find is not closed when the item is checked back in. select date, amount, description, accounttype, amountoutstanding, lastincrement, timestamp from accountlines where itemnumber = 35540 and borrowernumber = 24990\G *************************** 1. row *************************** date: 2015-05-05 amount: 0.500000 description: O'Connor's annotated criminal codes plus. 05/04/2015 11:59 PM accounttype: F amountoutstanding: 0.500000 lastincrement: 0.500000 timestamp: 2015-06-08 12:42:27 *************************** 2. row *************************** date: 2015-06-08 amount: 4.500000 description: O'Connor's annotated criminal codes plus. 05/26/2015 11:59 PM accounttype: FU amountoutstanding: 4.500000 lastincrement: 0.500000 timestamp: 2015-06-08 02:02:40 2 rows in set (0.00 sec) Looking in old_issues, you can see that the item was renewed, and that date_due does match the second description... only the first accountlines entry is marked woth accounttype 'F' on return, however. select date_due, returndate, lastreneweddate, renewals, timestamp, issuedate from old_issues where itemnumber = 35540 and borrowernumber = 24990\G *************************** 1. row *************************** date_due: 2015-05-26 23:59:00 returndate: 2015-06-08 12:42:27 lastreneweddate: 2015-05-05 00:00:00 renewals: 1 timestamp: 2015-06-08 12:42:27 issuedate: 2015-04-13 09:23:20 To replicate: 1) check out an item 2) let the item go overdue and start accruing fines 3) renew the item 4) let the item go overdue again. Note that a second accountlines entry has been added 5) return the item. Note that the new fine is set with accounttype 'FU'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30