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

[Bug 15412] New: Dropdowns in suspend holds date selector do not function in Firefox
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15412 Bug ID: 15412 Summary: Dropdowns in suspend holds date selector do not function in Firefox 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Place a hold through the opac 2 - View your account->Holds 3 - Click suspend hold 4 - You should be able to select a date using the arrows and calender but the dropdowns do not function. -- You are receiving this mail because: You are watching all bug changes.

1 12

[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 14697] New: Extend and enhance "Claims returned" lost status
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14697 Bug ID: 14697 Summary: Extend and enhance "Claims returned" lost 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: kyle.m.hall(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A group of librarians have been brainstorming about claimed returns in Koha. They think this would be a good list of features for a claims returned system in Koha: * Add a system preference to flag which lost status is "Claims returned". Not setting this pref would disable the feature. * Add ability to mark item as "Claims returned" * Add the ability to mark an item as claims returned from the checkouts table on the checkouts and patron details pages * This functionality would operate in the same way checkins and renewals do. * It may be better to slim down to one column of checkboxes for all three functions ( that is, one at a time with one set of checkboxes ) * The ability mark an item as "Claims returned" from the item details would be disabled when the feature is enabled. All claims returned marking would happen through the checkouts table. * Charge or don't charge for claims returned * Some libraries charge the lost fee on claimed returns, some don't. * Add system preference to ask ‘charge’, ‘don’t charge’, or ‘ask for confirmation’ when marking an item claimed returned * Some libraries want to alerted of repeat offenders. * Add a sys pref to offer an option to block a patron, or alert staff somehow, after a set number of claimed returns. * This will be a running total over the lifetime of the patron, not the current number of outstanding claimed returns. * There will need to be a table that stores basic information about the item on patron’s record so you can track how many times they’ve said ‘i returned that’ * This allows us to track claimed returns even for returned and deleted items * This data will display on a new tab on the patron record ( moremember.pl ) for "claims returned" items * Will store the status so we know if the claim is open or resolved * ex. [title 1] / checked out {date} / claimed {date} / not returned / notes * Remove item from patron's current checkouts on marking "claims returned" ( e.g. current lost behavior ) * Will stop fines from continuing to accrue for said item * show as missing in the opac and claimed returned in the staff client ( e.g. current lost behavior, no change needed ) * Be able to mark item as ‘found’ from claimed tab if item happens to be found ( using standard 'found' behavior Koha already has ) * Offer options of “returned by patron” or “found in library” in a pull down to the side of every item that has been claimed. * next to each claimed item have a ‘notes’ field. Should be in line editable for ease of use * Claimed items should be easily distinguishable on staff side (compared to other types of lost items) on patron check out under ‘Attention’ so alert ‘Patron has claimed returns’ that links to the ‘Claimed’ tab below ( in a similar fashion to the current restrictions system ) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 15446] New: Koha::Object[s]->type should be renamed to _type to avoid conflict with column name
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15446 Bug ID: 15446 Summary: Koha::Object[s]->type should be renamed to _type to avoid conflict with column name Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 13967 In a few case (at least systempreferences and export_format (csv profiles), the type method of Koha::Object and Koha::Objects can be in conflict with the column names. Indeed systempreferences.type exists and so the method will return 'Systempreference' (the name of the module) instead of the value of the row in DB. I have found at least 1 place where it can cause issue: In C4::Context->set_preference: 601 my $syspref = Koha::Config::SysPrefs->find( $var ); 602 my $type = $syspref ? $syspref->type() : undef; 603 604 $value = 0 if ( $type && $type eq 'YesNo' && $value eq '' ); type will always be 'Systempreference' and the YesNo pref will be set to an empty string '' instead of 0. Referenced Bugs: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13967 [Bug 13967] Add package for System preferences -- You are receiving this mail because: You are watching all bug changes.

1 23

[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